管理FusionAuth中的电子邮件模板

Question

我们正在将FusionAuth集成到我们的3个SaaS应用程序的用户帐户/配置文件系统中。我们将建立大约5个角色，每个这样的用户的入职过程是不同的。

一个新的用户注册可以是全新的，可以是存在的，但是是一个新的角色，或者是重新激活一个帐户。因此，粗略地说，我们可能需要建立3x5x2(新用户和返回用户)电子邮件的帐户验证，然后相同数量的欢迎电子邮件。每封电子邮件都将有特定的教学文本、电子邮件主题和链接。

在FusionAuth UI中复制电子邮件模板的能力是有用的，但显然这不是一个完整的解决方案。如果我创建多个租户来支持我们的开发、测试和生产版本--能够维护一个版本化模板的主列表，并将其中任何一个电子邮件模板版本链接到任何租户和应用程序，那真是太棒了。

如果您熟悉SendGrid --那里的版本模板相当不错，模板中可以使用的条件逻辑可以减少必须维护的文档总数。

出于我的理智和与这些电子邮件相关的维护负担，我只想对这些帐户维护电子邮件使用FusionAuth或SendGrid。由于SendGrid是更健壮的电子邮件解决方案，所以可能是更好的选择。

使用FusionAuth的用户操作可以完成什么？所有FusionAuth电子邮件模板都可以从FusionAuthUI和API中禁用吗？

从UI中添加用户将需要创建(或返回) FusionAuth用户，设置FusionAuth应用程序注册，设置角色，然后触发必要的电子邮件。

如果所有可以配置为多步骤用户操作的操作创建/更新和配置用户，然后触发SendGrid模板电子邮件，这将是非常酷的。

Answer 1

电子邮件模板的版本控制和复制选项是很棒的想法。FusionAuth目前不支持用户界面中的电子邮件模板版本控制或复制/复制。您能在GitHub？https://github.com/FusionAuth/fusionauth-issues/issues中将这些作为功能请求打开吗？

我们确实支持模板中的条件逻辑。在FusionAuth文档中有一个简短的教程。https://fusionauth.io/docs/v1/tech/email-templates/email-templates

要构建条件逻辑，基本上可以使用FreeMarker支持的任何东西。https://freemarker.apache.org/

例如

[#if user.data.favoriteColor == "blue"]
  Hi ${user.firstName}, I see you like the color blue.
[#else]
  Hi ${user.firstName}, 
[/#if]

如果您有一些特定的用例，或者需要一些帮助，请在模板中构建逻辑，可以在FusionAuth槽中寻求帮助，或者在这里请求帮助。

也就是说，SendGrid是在电子邮件游戏中，他们可能会有一些强大的功能，在FusionAuth中不可用。如果您需要许多功能强大的用户功能，我不会试图劝阻您不要使用SendGrid。但是要打开功能请求，这样我们就可以使我们的电子邮件模板尽可能有用。

使用FusionAuth的用户操作可以完成什么？

用户操作是一种自由形式的事件，将使用我们的Web钩子配置发送。它们只能用于FusionAuth中已经存在的用户，因此它可能不适合您的用例。除了用户操作之外，您还可以启用诸如user.create等事件，因此，如果这有帮助的话，您可以在FusionAuth中响应这些类型的事件。

所有FusionAuth电子邮件模板都可以从FusionAuthUI和API中禁用吗？

不确定您的意思-您可以禁用SMTP电子邮件配置，它隐式禁用所有电子邮件的使用。这可以通过系统配置API来完成。https://fusionauth.io/docs/v1/tech/apis/system#update-the-system-configuration见systemConfiguration.emailConfiguration.enabled。FusionAuth首先是一个API，所以在API中可以做的所有事情都可以通过API来完成。

如果所有可以配置为多步骤用户操作的操作创建/更新和配置用户，然后触发SendGrid模板电子邮件，这将是非常酷的。

用户操作将无助于此用例。但是，您可以在更少的API调用中完成这一任务。如果您知道用户还不存在，您可以使用Combo (Create + register )在一步内创建和注册用户。https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

如果您忽略了此请求中的角色，则将为用户分配在应用程序上配置的任何默认角色。

如果您启用注册验证，这将向用户发送您选择的电子邮件。这主要是为了验证要为应用程序注册的用户。

自定义工作流的想法是一个很好的想法，但是，请随时打开一个问题上的GitHub。我会把它想象成应用程序的工作流构建器。

示例：

On user registration:
1. Assign role(s): [x] user
                   [ ] manager
                   [ ] admin

2. Send email: [select box for email template]