TOPIC PICKS
很多团队把售后补偿理解成“客服在工单里发张券给客户”；但企业版 Helpdesk + Loyalty 真正做的是工单发券、邮件发送、网站分享链接、coupon/gift card 分流以及 loyalty card 与 ticket 的双向留痕。本文从 `action_coupon_generate_send()`、`action_coupon_generate_share()`、`generate_giftcard()` 与 `open_coupons()` 把这条链路讲透。
可以顺着继续读的相邻方向
从 Odoo 19 的 portal 与 sale portal 控制器源码出发，讲清门户列表页并不是“search 一把然后分页”这么简单。domain、pager、session history 与 access token 彼此有边界，自定义时最容易在这里做出越权或漏单问题。
很多团队把网站预约理解成“选个时间 + 选个资源”这么简单；但企业版 Appointment 真正解决的是容量组合、linked resource 联动、前台人数上限与提交瞬间 booking line 分摊的一致性。本文从 `_slots_fill_resources_availability()`、`_slot_availability_select_best_resources()` 到 `appointment_form_submit()` 把这条链路讲透。
很多人以为 Odoo 网站定价只是给每个网站挂一组 pricelist，但 website_sale 实际会把 GeoIP 国家、partner pricelist、网站可见价目表、session 已选价目表和购物车上下文一起纳入 current pricelist 决策。
很多人以为 Odoo 官网招聘只是把 hr.job 发布到网站，但 website_hr_recruitment 实际把搜索、GeoIP 国家预选、污染式筛选计数、分页和 slug 路由串成了一套职位发现系统。
很多人把包邮理解成“把 delivery line 价格改成 0”；但标准 Odoo 在 sale_loyalty_delivery 里真正做的是保留原始运费行，再新增一条 shipping reward 负行，并把 delivery line 排除在积分门槛与积分累计之外，还限制同一时间只能有一个 shipping reward。本文把这套边界设计讲透。
很多人把 Odoo Portal 理解成后台单据的前台壳，但 portal 控制器实际上把 partner domain、分页 URL、session 历史导航和 access token 访问串成了一套文档浏览框架。
