我从 2017 年初的 讨论 中了解到，徽章不适用于受限的群组。
我们想看看是否有办法绕过这一限制，先简单介绍一下背景。
我们的群组 99.9% 仅对拥有“成员”角色的用户开放。我们还有少数群组对所有用户开放，用于公开讨论或帮助/支持。作为一个付费会员群组，如果能够表彰这些私密群组内的活动，那将非常棒，因为在我们 130 多万条帖子中，大部分都位于这些群组内。
是否有变通方法或配置可以实现这一目标？
4 个赞
原因是任何引用帖子的徽章都会针对 badge_posts 表运行查询。该表仅包含所有用户均可访问的类别中的帖子。
是的，我明白这确实是个问题。一个可能的解决方法是重写您网站的徽章查询，使其使用 posts 表而不是 badge_posts 表。这可能会导致无法访问您网站受保护类别的用户在查看与您用户徽章关联的帖子时遇到问题，但听起来这不会影响您网站上的太多用户。可能还有其他方法可以解决这个问题。
7 个赞
老实说，就我们的用途而言，我认为那完全可以接受。
这容易实现吗？还是说从长远来看会有问题？
1 个赞
将您网站上徽章查询中的 badge_posts 表替换为 posts 表相对简单。但要彻底解决问题，可能需要进行更大的改动。例如，您肯定不希望徽章被颁发给员工分类下的帖子，或者任何存在泄露主题标题风险的其他分类。
我在想，是否可以通过插件为具有类似配置的站点添加一个新的 Postgres 视图。然后，该视图可以替代 badge_posts 视图，用于徽章查询。
4 个赞
好的，我喜欢这个理论。
如果该路线是一个选项，那么该视图是否可以包含所有公开群组的内容？比如我们现在有的内容，加上任何对特定群组可见的群组？在我们的案例中，就是“成员”群组。
这将是会员群组的终极解决方案！
2 个赞
让我们看看 Discourse 的工程师们对此类方法有何看法，或者他们是否有其他建议。这并非该问题首次被报告。如果能提出一个通用的解决方案固然很好，但一个适用于众多站点的优质方案，可能比我建议的更为复杂。
4 个赞
我不太喜欢频繁更换视图。
我的建议是，@Mitchelsellers，从小处着手。先颁发徽章，而不必关联到具体的帖子。
[作为成员发布了二十个超级赞的帖子]（标题待定）是一个不错的起点。
基本上，通过自定义查询来设计一种独特的认可方式。
在我们将徽章与帖子关联的各个位置添加权限检查会很棘手，建议不要走这条路。
从小处、从简单开始。
5 个赞
我们认为这对我们来说也是完全可以接受的。
有什么好的建议吗？
1 个赞
我想，这里的第 0 步是用英文勾勒出你希望获得的徽章、徽章名称以及概念定义。
3 个赞
好的，我们将着手处理此事！
1 个赞
我一直在查看现有的徽章查询，以了解哪些查询针对 badge_posts 表中的帖子，或者使用其他方法来排除受保护类别中的帖子。
以下徽章查询会指定特定帖子，并且不会在私密类别中的活动授予：
- 编辑者
- 首次标记
- 首次点赞
- 首次链接
- 首次引用
- 首次分享
- 首次表情
- 首次提及
- 首次嵌入
- 首次通过电子邮件回复
- 读者
- 维基编辑者
- 优秀分享
- 良好分享
- 帮助台
- 不错分享
- 欢迎
- 著名链接
- 优秀回复
- 优秀主题
- 良好回复
- 良好主题
- 热门链接
- 不错回复
- 不错主题
- 流行链接
以下徽章不查询特定帖子，并且会在私密类别中的活动授予：
- 持照
- 自传作者
- 认证用户
- 本月新用户
- 阅读指南
- 受敬仰者
- 冠军
- 疯狂恋爱
- 忠实粉丝
- 富有同理心
- 鉴赏家
- 周年纪念
- 活动家
- 回馈者
- 更高之爱
- 受尊重者
- 被感激者
- 热情者
- 出于爱
- 推广者
- 感谢
- 领导者
- 常客
- 基础
- 会员
- 工作人员
- 个人资料图片
类似的内容已经由“被感激者”（20 个帖子各获得 1 个赞）和“受尊重者”（100 个帖子各获得 2 个赞）徽章覆盖。可以添加这些查询的一些变体。例如，20 个帖子各获得 10 个赞。还可以考虑授予“超级点赞主题”的徽章，其功能相当于“优秀主题”徽章。例如，当用户创建了 10 个各获得 10 个赞的主题时，可以授予该徽章。
我不确定为单个帖子或主题（不链接到该帖子）的活动授予徽章是否有意义。例如，可以创建一个替代的“首次点赞”徽章，其 SQL 如下：
SELECT pa1.user_id, pa1.created_at granted_at
FROM (
SELECT pa.user_id, min(pa.id) id
FROM post_actions pa
JOIN posts p on p.id = pa.post_id
WHERE post_action_type_id = 2
GROUP BY pa.user_id
) x
JOIN post_actions pa1 on pa1.id = x.id
为了使查询生效，需要使用“每日更新”触发器，而不是“当用户对帖子采取行动时”的查询。在徽章页面上，将显示已获得该徽章的用户及其获得徽章的时间，但不会提供授予该徽章的帖子链接：
这种思路对于主要拥有受保护类别的网站是否有意义？如果有意义，它可以用于复制当前针对 badge_posts 表的一些查询。
4 个赞
我认为这是一个很好的举措！
我只是想跟进一下这件事。
对于这类功能的实现，您有什么想法吗？
谢谢你提醒我！我会开始整理一份我认为有用的徽章列表，这些徽章不会暴露任何受保护分类中的帖子。
2 个赞
我们最初开设论坛时要求“必须登录”，最近添加了一些公开分类，同时将现有分类的访问权限限制为 trust_level_0。
因此，对于现有用户而言，他们访问论坛的方式并未改变，但上述列表中的所有徽章均被撤销。我们的论坛规模不大，但从用户反馈来看，显然大家觉得徽章系统完全出了问题。在这种设置下，我几乎不得不将其禁用。
我认为，当选择限制分类访问权限时，需要在设置中的某个位置更明确地告知用户：现有徽章将被撤销。对我们来说，这一变化来得毫无预兆。
更广泛地说，我不理解当前的优先级安排。分类权限和徽章系统都被宣传为 Discourse 的核心功能，但按现有方式，两者几乎无法协同使用。仅在公开可访问的帖子中显示徽章的优势，似乎是让其他用户能看到某枚徽章是授予哪篇帖子的？在我看来，这一功能的重要性并不突出。为什么不直接移除这些可见链接，而仅在每位用户自己的徽章页面中显示与其相关的帖子呢？
3 个赞
哎哟！好的，这几乎意味着在有很多私人空间的社区中，整个徽章基础架构都相当没用……
我同意。
是否有某种插件或新设置（在过去六年里）可以让徽章在主要私密的社区中变得可行？
2 个赞
我赞成改进开箱即用的工作方式。
尽管这个话题已经沉寂多年，但我听到人们在其他地方也要求进行类似更改。
只是需要弄清楚具体需要什么更改，并确定它在其他优先级中的位置。
3 个赞
这似乎与另一个主题中提出的关于促进社区成员在开放（公共）和封闭（不同程度的“私密”）空间之间进行定位的问题有关，包括私人消息。
处理网络的半公共性质和半重叠的受众是在在线社交世界中面临的主要挑战。这并不直观。大多数社区都会努力解决如何确保人们了解其不同部分是多么公开/私密。Discourse 假设这种公共和私有空间的混合是大多数社区的默认设置，并考虑如何为社区成员导航它可能会有意义？
1 个赞
我是这个对话的新手，但我认为在徽章设置（Badge Settings）下设置一个切换开关会最简单。默认情况下保持关闭状态，勾选它以查询所有版块（包括私有版块）以获取参与徽章。
如果为插件/组件可以使用的钩子（hook）保持开放，以后可以引入一个钩子来为徽章在特定分类中计数提供权限。
2 个赞
