Odoo 企业版网站销售看板为什么不是“后台多一张报表”而已：入口重定向、Digest 链接与权限边界讲透

企业站点运营常常把“看板”理解成可有可无的报表页，但在 Odoo 里真正影响效率的是入口：用户从哪里进、有没有权限进、邮件里点进去会落到哪里。

核心链路

1. website_sale_dashboard/models/website.py 里的 action_dashboard_redirect() 会先判断当前用户是否拥有 sales_team.group_sale_salesman。有权限的用户不再回到通用网站 Dashboard，而是直接跳到 website_sale_dashboard.sale_dashboard 动作。
2. 这一步的意义不在 UI，而在运营路径：同一个“进入网站后台”的动作，对销售人员和普通网站管理员会分流到不同分析入口。
3. models/digest.py 的 _compute_kpis_actions() 又把 kpi_website_sale_total 映射成 website_sale_dashboard.sale_dashboard?menu_id=...。换句话说，Digest 邮件里的 KPI 点击不是去一个静态 URL，而是触发一个后台 action。
4. 这也解释了为什么企业里常见的“邮件里点 KPI，结果打开的页面不对”问题，往往不是统计错了，而是 action / menu_id / 权限组合错了。
5. 虽然模块代码短，但它卡住的是“分析入口是否连贯”这条主链路：站点入口、后台 action、Digest 邮件三者必须对齐，运营团队才能稳定形成日常复盘习惯。

关键源码位置

• /home/ubuntu/odoo-temp/enterprise/website_sale_dashboard/models/website.py
• /home/ubuntu/odoo-temp/enterprise/website_sale_dashboard/models/digest.py

容易误解的地方

• 误区一：看板只是给老板看的。实际上最依赖看板跳转连续性的往往是一线电商运营。
• 误区二：Digest 点击的是网页链接。这里实际跳的是 action，权限和菜单上下文都会影响结果。
• 误区三：没有销售权限的人也应该看到同样看板。模块明确按 group 做分流，不是所有后台用户同权。

实战注意事项

• 如果企业想把电商运营与销售团队拆开管理，先定义谁需要 group_sale_salesman，再谈看板入口。
• 自定义 Digest KPI 时，别只改邮件模板，也要检查 action 是否带了正确 menu 上下文。
• 出了“点击 KPI 404/无权限”问题，优先排查 action XMLID 和用户组，而不是先怀疑统计 SQL。

结语

企业版这些代码共同说明一件事：真正可上线的业务流程，靠的不是“页面上看起来能点通”，而是权限、状态、时机、对账口径和跨模块回写都被收紧。理解这些边界，实施和二开时就不容易走进“功能演示能跑、真实业务一用就散”的坑。