私人主题插件

您知道这个ActiviyPub插件能一起工作吗?

我没有测试过。这个插件会覆盖访问和可见性检查,所以它通常能与其他插件很好地协同工作。但我可以想象 ActivityPub 插件可能会钩入一些(无意中)绕过这些检查的地方。唯一的方法就是进行测试。

话虽如此,我看不出私有主题类别有任何适用于 ActivityPub 的用例。

2 个赞

哦,我明白了。我误解了它的作用。

那更好。

2 个赞

感谢您提供的这款出色的插件,我们期待这一功能已久。

我们尝试将其与“邮件进入”功能结合使用。对于简单的情况,它运行良好,但更复杂的情况效果不佳:

  • 如果有人发送邮件到两个“私有主题”类别邮箱,它只会出现在其中一个(这在 Discourse 的工作方式中很正常,但对于使用邮件的用户来说却难以理解)。
  • 如果用户发送到多个绑定到群组和其他类别邮箱的地址,情况也是如此。
  • 如果用户发送到外部邮箱和“私有主题”类别邮箱,当我们回复时,其他外部邮箱将收不到回复。(群组消息支持此功能,因为我们可以邀请某人加入对话)。

这些问题并非此插件特有,而是分类主题与群组收件箱的普遍缺点。此插件无意解决所有这些问题。

1 个赞

修复:Discourse AI 语义搜索能够绕过保护。现已解决。如果您将此插件与 Discourse AI 插件一起使用,请确保进行更新!

3 个赞

看到了这个插件。非常酷。

1 个赞

感谢 @RGJ 的插件,它似乎满足了我需要的功能:slight_smile: 在测试过程中我遇到了两个问题:

  1. 如果我通过在安全设置中激活“启用私有主题”复选框并将其他群组 B 的权限添加到可以发布其私有主题的权限,来“开放”现有的类别 A(到目前为止只有群组 A 可以访问),那么群组 A 的其他用户发布的所有现有主题似乎都可以被群组 B 的成员查看。因此,_私有主题_功能似乎只对启用插件之后创建的主题有效,而对插件启用之前创建的现有主题无效。有人能确认这一点吗?
    我期望/希望的功能是,现有主题也能对群组 B 的用户保持/变为隐藏(就像新主题那样)。否则,我不确定如何迁移。
  2. 在测试过程中,我注意到在群组 A(类别所有者)的用户创建了一个主题之后,群组 B 的用户在类别视图中看到了计数器 New (1)。由于该主题对用户来说(正确地)是隐藏的,这个计数器通知似乎是一个错误,可能会让用户感到困扰。

discourse 3.2.0.beta5-dev (cef6aca6e5)
插件 1.5.3 (709df2c)

该插件不仅会影响启用插件后创建的主题,还会影响那些类别中的所有主题。

我不确定

是什么意思。如果它与复选框下方的组选择器有关,那么该设置并非如此。
主题对主题发起者以及以下组中的用户可见
当您在此处添加组 B 时,您将授予组 B 的所有成员查看所有主题的权限。这适用于例如您的支持团队。

如果它与该组选择器无关,请更详细地描述您的设置。

抱歉,我表达得不好。

我并没有在那里添加群组 B。我只将群组 B 添加到了通用安全设置中,以允许他们查看类别和发帖主题。

更详细的设置说明:
启用插件之前的类别设置:

  • 只有群组 A 可以访问该类别(查看、回复、发帖)。

启用插件之后的类别设置:

  • 为该类别添加群组 B 的访问权限(查看、回复、发帖)
  • 为该类别启用私有主题
  • 将群组 A 添加到“主题对主题发起者和以下群组的用户可见:”(实际上,默认已添加)

首先,我刚刚推送了一个针对 Ember5 的修复程序,但这不应该影响插件的工作。为 100% 确定,请从头开始重建和配置插件。

我无法重现此问题。

  • 按照您所说的进行设置,用户 A 在 groupA 中,用户 B 在 groupB 中。
  • 用户 A 发表了一篇帖子
  • 设置插件
  • 用户 B 发表了一篇帖子
  • 用户 A 又发表了一篇帖子

管理员视图

用户 A 看到

用户 B 看到

所以这表现符合预期。

另外,这非常奇怪,那里没有任何默认的组添加。

1 个赞

感谢您的快速反馈和测试,@RGJ!抱歉回复晚了,其他任务让我离开这个问题几天了。我更新了插件并使用另一个类别重新测试。我现在自己无法重现它,所以似乎按预期工作。只有管理员发起的帖子才会显示在类别中(可能是故意的且合理的),我可能在第一次测试中弄混了。抱歉打扰了!

“新”帖子计数器的问题似乎仍然存在:一个只允许查看自己帖子的用户所属的组有一个“新”计数器,但如果“支持”组(允许查看所有帖子)的用户发布新帖子,他却看不到新帖子。请参见下面的截图:“无权限用户”的“新 (5)”


有权限的“支持”用户的视图:

1 个赞

正确,这由设置 private topics permitted groups(允许私有帖子的群组)中的“始终显示由此群组的成员发起的帖子”控制。

是的,这是一个已知问题。欢迎提交拉取请求(PR)或提供相关线索。

1 个赞

一个问题,即使我可能知道答案。

如果插件因某些冲突等原因必须禁用,会发生什么?届时所有帖子和回复都会对所有人可见,还是该类别将对所有人受限?

因为第一种选择对我来说是绝对不可行的,包含太多敏感数据。但如果是第二种……我可以接受。

禁用插件后,该类别中的所有主题都将对所有人可见。

如果您想避免这种情况,应该在禁用插件之前修改类别权限,使其更加严格。

1 个赞

正如我所预料的那样。所以,存在一个巨大的风险:人为错误。如果我必须禁用它,我应该记得在那种混乱中也要调整组限制。这确实是一个很大的疑问。

避开混乱,你就没事了 :wink:

1 个赞

确实如此🤣 但插件和环境的问题超出了我的能力范围(否则会……很精彩🤦‍♂️)

只是在构思……如果有一些安全措施,比如一个伴随组件,它只有一个工作:监控插件的状态,并立即通知管理员该类别对公众可见。

我只是个小玩家,但我只是想知道那些使用这个并且经常不止一个管理员的公司论坛是否完全意识到了这个风险🤔

1 个赞

在不了解可能性太多,因此也许只是一个无关紧要的想法的情况下,如何减轻风险:在禁用插件之前/期间,向用户显示一个对话框,提醒他们禁用插件的后果,并让他们仔细检查类别安全设置。

只是我个人的看法:总的来说,我认为这个问题很小,因为我认为人们不会盲目禁用他们需要的插件,而是在需要禁用插件时会花一些心思来满足他们的需求……

最常见的原因是论坛宕机。而且我不知道有多少管理员在知道原因和修复方法是禁用某个插件时,还会继续思考。我喜欢 Category Lockdown,但因为它坏了,我立刻就把它撤下了。这时我应该记住一个长期以来运行良好的特定插件的局限性。

这和备份是同样的问题。我们都知道备份有多重要。但如果它依赖于手动操作和记忆……那么就没有备份,或者备份非常陈旧。

人为因素是最大的风险。

总之。这个插件本身很棒,但我必须仔细权衡利弊。我受到不同的法规约束,暴露这些数据可能会付出多方面的代价。

2 个赞