Odoo 活动议程为什么不只是“排个演讲表”：议题提案、阶段可见性、收藏提醒与前台议程链路讲透

先说结论

Odoo 的活动议程不是一个静态页面，而是一条把 议题对象、讲师信息、阶段流转、前台可见性、访客收藏和提醒动作 串起来的内容运营链。

从 /home/ubuntu/odoo-temp/addons/website_event_track/models/event_track.py、controllers/event_track.py、models/event_track_stage.py 和 models/event_track_visitor.py 来看，event.track 至少同时承担了四层职责：

• 后台议题提案与审核对象
• 讲师资料与联系方式承载体
• 前台 agenda 是否可见的发布门槛
• 访客收藏、提醒与议程分组的中心节点

所以它真正解决的问题不是“给活动加几场演讲”，而是：

一条议题从征集、审核、排期到前台曝光与观众提醒，如何在同一套模型里稳定流动。

第一层：为什么 event.track 本质上是“议题单”，不是纯时间块

event.track 里不只有 date、duration、location_id，还挂了：

• stage_id
• user_id
• partner_id
• partner_name / partner_email / partner_biography
• tag_ids
• website_cta_*
• wishlisted_by_default

这说明官方并不把它理解成一条普通 agenda line，而是一个带完整生命周期的内容对象。

这很重要，因为真实活动运营里，一个议题往往要经历：

• 征稿
• 审核
• 排期
• 调整讲师资料
• 上线前台
• 触发提醒
• 会后归档

如果模型里只有时间和标题，前后流程就会被迫散落到邮件、表格和人工备注里。event.track 的设计恰恰是在避免这种碎片化。

第二层：阶段为什么直接决定前台能不能看见

event.track.stage 里最关键的不是颜色，而是：

• is_visible_in_agenda
• is_fully_accessible
• is_cancel
• mail_template_id

这里的产品判断很鲜明：议题的后台状态，不只是内部协作标记，而是前台发布策略。

控制器 _get_event_tracks_agenda_domain() 会要求议题满足：

• 属于当前活动
• 且要么已发布 is_published=True
• 要么其阶段允许出现在 agenda

这意味着 Odoo 默认允许两种路径让议题上前台：

1. 明确发布某个 track
2. 把阶段设置成可见，让这一阶段的议题整体进入议程

这对大型活动特别实用。因为很多团队不是一条条手动发，而是按“已确认”“已排期”“已公开”阶段来推进内容发布。

第三层：讲师信息为什么不直接等于联系人卡片

event.track 会从 partner_id 计算并回填：

• 讲师姓名
• 邮箱
• 电话
• Biography
• 职位
• 公司名
• 头像

但这些字段又都是可存储、可覆写的。

这背后的逻辑和活动报名很像：

• res.partner 是长期主数据
• event.track 上的讲师资料是这次议题语境下的展示快照

所以你可以理解为：

联系人是“这个人是谁”，议题上的讲师字段是“这个人这次以什么身份出现在这场活动里”。

这样一来，即使讲师在 CRM 里的职位 later changed，活动页上仍可保留当次议题所需的展示口径，不会把历史活动内容一起冲掉。

第四层：议程页为什么不是简单按开始时间排序

controllers/event_track.py 里，Odoo 会把 track 分成：

• live
• soon
• 按天分组的 tracks
• 还未定档的 coming soon

而 _prepare_calendar_values() 还会把一天切成 15 分钟格子，再按地点和时间段计算 rowspan。

这说明官方不是在渲染“线性列表”，而是在构建一个可同时表达多会场并行、即将开始、当天分组和未定档预告的议程系统。

这和很多活动系统的差别很大：

• 小型系统只会按开始时间列个清单
• Odoo 则考虑多地点占格、即将开始提示、过往议程折叠、未排期议题预热

所以做实施时，如果你把 track 只当普通文章，会低估它在活动现场导流中的价值。

第五层：收藏和提醒为什么单独建了 event.track.visitor

event.track.visitor 把 visitor_id、partner_id、track_id、is_wishlisted、is_blacklisted 放在一张中间表里。

这张表非常关键，因为它表达的不是“谁浏览过”，而是“谁对哪场议题表达了持续关注”。

前端 event_track_reminder.js 点铃铛时，会：

• 调 /event/track/toggle_reminder
• 记录收藏状态
• 视情况请求邮箱提醒
• 触发 push notification 引导

这里最值得注意的一点是 wishlisted_by_default 与 is_blacklisted 的组合。

也就是说，官方支持这种场景：

• 某些关键议题默认被所有参会者收藏
• 但个体仍可显式关闭提醒

这不是简单点赞，而是活动运营中的“重点议题触达机制”。

第六层：阶段邮件模板为什么放在 stage 上

event.track.stage.mail_template_id 说明：当议题进入某阶段时，系统可以自动发出邮件。

这意味着 stage 不只是看板列名，而是自动化触发点。常见用途会变成：

• 议题被接受时通知讲师
• 议题排期完成时发上台信息
• 进入 fully accessible 阶段时发访问链接或准备提醒

这类设计很成熟，因为活动内容运营里真正难的不是“把数据存起来”，而是让关键状态变化自动带出动作。

最容易误解的三个点

误区一：Track 就是活动里的 blog post

不是。它有时间、地点、讲师、状态、提醒、CTA、访客收藏等一整套执行语义。

误区二：前台看见什么，全靠手动发布

不完全是。阶段本身就会影响议程可见性与访问级别。

误区三：收藏只是用户个人偏好

也不是。它还承担关键议题默认订阅、邮箱提醒和 push 触达的运营角色。

实战上怎么用最顺

如果你要把 Odoo 活动议程用顺，我建议按这条线设计：

1. 先把 stage 定义成真实运营状态，而不是随便几列
2. 明确哪些阶段允许进入 agenda
3. 讲师资料在 track 上做活动上下文快照
4. 对重点议题启用默认收藏或提醒策略
5. 把议程页当现场导流工具，而不是官网装饰页

这样你会发现 event.track 真正像一张“活动内容执行单”。

最后总结

Odoo 的活动议程体系，核心不是“把演讲排时间”，而是把 内容征集、审核、前台可见、访客关注和提醒动作 收进一套统一对象。

所以 event.track 最值得学习的地方，不是字段多，而是它把活动内容运营里最容易散掉的环节，收成了一条连续的产品链路。