“自定义收件邮箱地址”选项不适用于自动群组。这对所有人以及 trust_level 群组来说都没问题,但我不太确定这对 staff/admins/moderators 群组是否适用。
我不得不为我们的群组创建一个单独的“support”群组,其中包含版主。这作为一种变通方法是可以的,但会带来一些小但烦人的管理负担。
是否有充分的理由禁用这些群组的此功能(或 IMAP)?
“自定义收件邮箱地址”选项不适用于自动群组。这对所有人以及 trust_level 群组来说都没问题,但我不太确定这对 staff/admins/moderators 群组是否适用。
我不得不为我们的群组创建一个单独的“support”群组,其中包含版主。这作为一种变通方法是可以的,但会带来一些小但烦人的管理负担。
是否有充分的理由禁用这些群组的此功能(或 IMAP)?
如果我将电子邮件地址插入论坛的 @moderators 的 groups.incoming_email 中会发生什么?在没有全新实例的情况下,很难安全地进行测试。
既然没有人告诉我这完全是愚蠢的,我已经在一个很少使用的实例上测试了这个 rails 命令。
而且它似乎(到目前为止)有效!
自担风险使用并先备份
Group.where(name: "=groups.name=").update(incoming_email: "=groups.name=@=domain=")
Group.where(name: "=groups.name=").update(incoming_email: nil)
@nathank,我不确定这是否已准备好成为指南?它似乎未经充分测试。
好的,好的,我会进一步测试,然后一旦证明可行,就会将其移至指南部分。到目前为止,一切都很好。
我仍然不确定为什么它在用户界面中被禁用——虽然我可以看到电子邮件加入大型自动群组存在风险(特别是对于像 meta.discourse.org 这样备受瞩目的网站),但完全取消管理员执行此操作的能力似乎很奇怪。
我确实认为这是一个历史遗留问题,应该重新考虑——特别是对于管理员/版主/工作人员。
我会看看我能找到什么。 ![]()
在我看来,它应该可以工作。我不确定这是一个好主意,但我不认为它会造成任何损害。
[quote=“Nathan Kershaw, post:5, topic:212147, username:nathankershaw”]
我仍然不确定为什么它在UI中被禁用
[/quote]因为那些组有点特殊,因为它们实际上是别名,为组织中的“管理员”或“员工”创建“普通”组更有意义。
我认为我的犹豫在于它是否足够明智可以被添加为一项建议。我不确定它通常被阻止的原因,但我倾向于相信用户界面。
不过,如果事实证明没问题,我们随时可以把它加回来。![]()
我正在为我的社区论坛研究如何为员工创建电子邮件地址,并遇到了这个问题。有一个管理员收件箱,所以在我看来,为该收件箱设置一个电子邮件地址以便人们可以写信给它似乎是合理的。同样的事情也适用于版主,为他们设置一个电子邮件地址以便人们可以写信给他们来寻求账户登录等方面的帮助也是合理的。
对于像我的社区论坛这样非正式运行的私密、仅限邀请的社区,否则没有办法联系到网站的所有者,除非所有者在描述中留下一个电子邮件地址,而这个地址现在会显示在登录页面上。我宁愿提供一个能联系到版主的电子邮件地址,而不是我的个人 Gmail。
我将尝试这个解决方法,但也认为通过用户界面(UI)实现这一点,甚至鼓励私人网站使用它,可能会很有趣。
我认为一个接受 username@hostname 的插件应该是可行的。
正是我的想法!在两个大型私有站点上使用它 6 个月后,我没有发现任何问题。尽管它在登录页面上很显眼,但我们收到的邮件很少,垃圾邮件更是少之又少。
因此,到目前为止,它取得了巨大的成功,我非常希望它能被添加到 UI 中。
这完全是另一回事——但可能非常有帮助,Jay。如果可以配置为应用于指定组的所有个人,那将非常有效。
对于那些想要从其管理员账户管理账户(例如 Mailgun、AWS、Digital Ocean)的用户来说,auto_generated_allowlist 站点设置非常有用。
它允许“no-reply”和其他自动生成的电子邮件通过通常严格的过滤器。这使得发票和账户确认电子邮件可以由您的团队在您的实例内进行管理。