Odoo Discuss 个人设置为什么不只是偏好项：频道默认通知、Push-to-Talk 与单人音量矩阵讲透

先说结论

Discuss 里的个人设置，不只是浏览器本地小偏好。

Odoo 把很多协作偏好正式建成了 res.users.settings 数据：频道默认通知、Push-to-Talk、语音激活时长，甚至对每个参与者单独保存音量。

这意味着这些设置会影响真实协作体验，而不只是当前页面展示。

一、为什么“默认频道通知”值得单独落库

res.users.settings 里有 channel_notifications，值不是无限多，而是聚焦在：

• all
• no_notif

帮助文本还说明：如果频道成员本身没有自定义设置，就回退到这个默认值。

这意味着个人设置不是孤立存在，而是在和 discuss.channel.member.custom_notifications 形成层级关系：

• 成员级设置更具体
• 用户设置做默认兜底

这是一种非常典型的“全局默认 + 局部覆盖”设计。

二、为什么 Push-to-Talk 也要落到用户设置里

源码里保存了：

• push_to_talk_key
• use_push_to_talk
• voice_active_duration

这说明 Odoo 认为语音协作不是临时实验功能，而是需要跨会话保持习惯的能力。

否则每次刷新页面都重新配快捷键、重新试麦克风阈值，实际根本无法在团队里长期使用。

三、为什么“单独给某个人调音量”会变成一张表

res.users.settings.volumes 很有意思。

它不是保存一个总音量，而是保存：

• 某个用户设置
• 对某个 partner 或 guest
• 一个 0 到 1 的音量值

并且用唯一索引保证：

• 同一个用户对同一个 partner 只有一条音量设置
• 同一个用户对同一个 guest 只有一条音量设置

这说明 Odoo 的语音协作视角很现实：

• 有些人麦克风总是太大
• 有些外部 guest 声音太小
• 用户需要长期记住“我对这个人的收听偏好”

四、为什么设置变化后还要广播

set_res_users_settings() 和 set_volume_setting() 都会通过 bus 往前端推。

这意味着设置不仅要存下来，还要尽快让当前协作界面生效。

否则会出现：

• 数据库里已经改了
• 当前通话或当前 Discuss 侧栏还沿用旧状态

对实时协作来说，这是不能接受的。

五、这套设计说明了什么

它说明 Odoo 对个人协作设置的理解是：

• 不是装饰性的 UI 偏好
• 而是影响通知噪音、语音输入方式、音频可懂度的长期参数

也就是说，这些设置虽然看起来“个人化”，本质上却在决定团队协作的摩擦成本。

六、最容易踩的误区

误区 1：默认通知和成员通知互不相干

不是，成员设置会覆盖默认，默认又会作为兜底。

误区 2：音量设置只是本地浏览器滑块

不是，它会正式落库。

误区 3：语音快捷键改完只影响当前页面

不是，设计目标就是跨会话保留。

七、排错顺序

当用户说“我明明改了设置怎么没生效”时，建议按这个顺序查：

1. 改的是全局 res.users.settings 还是频道成员级设置
2. 当前频道是否有 custom_notifications 覆盖默认
3. 音量是对 partner 还是 guest 设的，有没有命中唯一记录
4. bus 广播是否及时把新设置推回前端
5. 最后再看浏览器音频权限或前端缓存

最后一句

个人设置之所以重要，不是因为它“看起来贴心”，而是因为协作系统必须允许每个人把通知噪音和语音体验调到自己能长期承受的状态。

Odoo 在这点上其实想得很实用。