Odoo 论坛为什么“采纳答案”会改排序和权限：accepted answer、karma 与 moderation 链路讲透

先说结论

Odoo 论坛里的“采纳答案”，从来不是一个孤立的 UI 小勾选。

从 website_forum/models/forum_post.py 与 controllers/website_forum.py 看，它会同时影响：

• 答案排序；
• 问题是否被视为已解决；
• 谁能执行采纳动作；
• 社区 karma 奖惩；
• pending 内容、nofollow 外链和 moderator 审核的整体信任链。

也就是说，Odoo 的 forum 不是“发帖 + 点采纳”的轻量问答页，而是：

一套把内容质量、社区信任和审核干预绑在一起的机制系统。

这也是为什么一个看似简单的 accepted answer，背后会牵出排序、权限、内容风险控制和运营节奏。

一、为什么 accepted answer 会直接改变页面结构

forum.post 的默认排序就是：

• is_correct DESC
• vote_count DESC
• last_activity_date DESC

这意味着被标记为正确答案的回复，会天然被推到前面。

这里的产品思路很明确：

• 投票高说明社区认可；
• 最近活跃说明讨论还在继续；
• 但 已采纳答案 代表当前问题已有一个官方或提问者认可的解决出口。

所以 accepted answer 在 Odoo 里不是纯视觉徽章，而是会重排答案曝光顺序。

也正因为如此，采纳动作一旦出错，影响的不是一个图标，而是整页信息结构。

二、为什么“只有一个正确答案”是被控制器强制保证的

控制器 post_toggle_correct 有一段很关键的逻辑：

• 切换当前答案前，先把同问题下其他 child_ids 的 is_correct 全部写成 False；
• 然后再切换当前答案。

这说明 Odoo 不允许一个问题同时挂多个 accepted answers。

它要的是一个清晰出口，而不是“很多都差不多正确”。

对社区运营来说，这个决策很重要，因为它把问答页从“讨论串”拉向“解决方案页”：

• 访客进来先看到最可信的一条；
• 其余答案继续保留，但不和最终出口混在一起。

三、为什么采纳答案不是谁都能点

_compute_post_karma_rights() 会计算 can_accept，而门槛来自：

• 自己的问题采纳自己的门槛；
• 采纳他人问题答案的更高门槛。

write() 里也对 is_correct 做了手动安全检查：

• 如果没有 can_accept，就不能改；
• 还会按是否真的发生状态切换，处理对应 karma 变化。

这说明 accepted answer 不是普通写权限的一部分，而是被单独视为一个治理动作。

换句话说：

“能编辑帖子”不等于“能定义哪条是社区认可答案”。

这和很多简单问答系统不一样。Odoo 明确把“内容编辑权”和“问题定性权”拆开了。

四、为什么 pending 审核和 accepted answer 属于同一信任体系

源码里提问 / 回答并不天然等于立刻公开。

在创建逻辑里，如果新问题作者还没达到自动放行门槛，帖子可以被设成 pending。

控制器也会对 pending 内容做隐藏：

• 非 moderator；
• 非作者本人；

通常不能直接看见。

这跟 accepted answer 看起来像两回事，但其实属于同一条社区信任链：

• 低信任内容先延迟公开；
• 高信任内容再允许定性问题出口。

所以 Odoo 论坛治理的重点，不是简单地“谁能发言”，而是：

• 谁的内容能立即公开；
• 谁的内容能影响问题最终结构；
• 谁有资格作为 moderator 介入。

五、为什么外链 nofollow 和富文本限制也要跟 karma 挂钩

_update_content() 有两层非常实用的风险控制：

1. 如果 karma 低于 karma_dofollow，链接会被加上 rel="nofollow"；
2. 如果 karma 低于 karma_editor，带图片、链接或某些样式的内容甚至会直接被拒绝。

这背后的思路其实很先进：

• 不必一刀切禁止新人发言；
• 但要先限制其外链价值与富文本攻击面；
• 再随着社区信任提升，逐步开放更强表达能力。

所以论坛里的 accepted answer、pending、nofollow、full editor，看起来像分散功能，实际都是同一个问题的不同答案：

系统到底多信任你。

六、为什么 moderator 权限是最后一道人工兜底

can_moderate 也由 karma 或管理员身份决定。

这意味着 Odoo 并不是把社区治理完全交给机器规则：

• 低信任内容可以 pending；
• 高风险内容可以 flag；
• 但最终仍需要 moderator 对 offensive、pending、关闭等状态做人工决策。

这套设计非常务实，因为社区产品里有些问题根本不适合全自动：

• 语义灰区；
• 软广告；
• 不礼貌但不违法；
• 看似技术正确却会误导新手的答案。

Odoo 的做法是：

• 用 karma 做日常分流；
• 用 moderator 做高风险兜底。

最后给社区站点运营者的 4 个提醒

1. 不要把 accepted answer 当成纯前端交互

它会改排序、改 solved 状态，也会改社区认知。

2. 不要只看发帖权限，不看自动公开门槛

can_post 与 can_ask/can_answer 不是同一件事。

3. 不要忽略 nofollow 与富文本门槛

这是防垃圾与防滥链的重要一层。

4. moderator 规则最好和社区节奏一起设计

如果门槛太低，社区会脏；太高，则会让内容流速过慢。

参考源码

• addons/website_forum/models/forum_post.py
• addons/website_forum/models/forum_forum.py
• addons/website_forum/controllers/website_forum.py