先说结论
复制 Odoo 项目时，界面上的“我看到什么” 和 系统里“这个项目携带什么配置” 不是同一层东西。
从 /home/ubuntu/odoo-temp/addons/project/tests/test_project_embedded_action_settings.py 可以看出，官方对 embedded actions 的复制策略非常克制：
- 与项目共享相关的嵌入动作，可以被复制到新项目
- 纯用户私有的嵌入动作，不应该跟着模板或复制项目盲目复制
- 项目删除时，关联的 embedded action settings 也要清理
这说明 embedded actions 不是普通装饰，而是介于：
- 项目级工作台配置
- 用户级界面偏好
之间的一层配置资产。
所以复制项目时，真正的问题不是“能不能全带走”，而是：
哪些属于项目模板能力，哪些只是某个用户的个人工作习惯。
第一层：为什么复制项目不能无脑复制所有界面配置
很多实施团队喜欢把“项目复制”想成“所有东西克隆一份”。
但这在界面配置上非常危险。
原因很简单：
- 有些配置是项目自己需要的
- 有些配置只是用户在自己界面里调了个顺手顺序
这两类东西如果不分开，复制后的结果会很怪：
- 新项目带着旧用户的私人工作台偏好
- 其他用户被迫继承不属于自己的布局
- 模板项目开始携带大量历史使用痕迹
测试里正是在防这个问题。
第二层：什么是“应该复制”的共享动作
测试表明，如果 embedded action 是：
- 共享的
- 绑定在某个项目上下文
- 但不属于某个特定用户私有配置
那么项目复制后，相关设置可以跟着复制。
这类动作更像什么？
- 项目级快捷视图
- 项目工作台里预置的功能块
- 团队共用的嵌入入口
它们本质上是项目模板能力的一部分。
所以复制项目时保留这些东西，符合用户预期：
- 新项目仍保留原来的工作台结构
- 团队不用每次重新摆一遍
第三层：什么是“不该复制”的用户私有动作
测试还特别验证了一种情况：
- user-specific embedded action
- shared embedded action
- 同时存在于旧项目设置里
复制项目后：
- 共享动作可以复制
- 用户私有动作不该照搬进新项目设置
这个设计非常关键。
因为用户私有动作本质上回答的是：
- 这个用户喜欢把哪个块放左边
- 想把哪个入口先显示
- 对这个项目做了什么临时个性化安排
这些都不是项目模板资产，而是个人偏好。
如果强行复制，会产生两个问题：
- 污染模板：个人习惯被误当标准流程
- 污染新项目：复制后出现一堆别人看不懂或没权限的私有入口
第四层：为什么项目删除时要顺手清 embedded settings
测试最后还验证了：
- 删除项目时，相关 embedded action settings 也应被清掉
这一步看起来普通，其实是配置治理问题。
如果项目删了，设置还留着，就会出现：
- 悬空配置
- 用户设置里残留指向不存在项目的 UI 片段
- 后续查询、复制、渲染都变脏
所以这不是清洁癖，而是为了保证：
- 项目生命周期结束
- 它的界面级附属配置也同步结束
第五层：这对“模板项目”意味着什么
很多团队会把项目复制当模板机制来用。
那 embedded actions 的复制边界就尤其重要。
一个好的模板项目，应该携带的是：
- 团队共用的视图入口
- 公共工作台配置
- 合理的默认展示顺序
不该携带的是：
- 某个经理临时加的个人视图
- 某个用户专属的自定义入口
- 某次项目特殊操作留下的个人布局
所以模板项目真正要做的是“抽公共骨架”，而不是“冻结某个人的桌面”。
实施建议：如何管理 embedded actions 才不乱
1. 先定义哪些是团队共享动作
凡是复制后应该继续存在的，必须明确是共享资产。
2. 个人偏好一律当个人偏好管理
不要把个人工作习惯包装成项目标准配置。
3. 定期清理无效项目的残留配置
尤其是在大量复制 / 删除模板项目的环境里，配置垃圾会积得很快。
4. 复制项目前，先判断是“模板复制”还是“用户工作副本”
这两种复制诉求不一样，别用同一种期待去看结果。
最后一句
embedded actions 这类功能最容易暴露一个组织的配置治理水平。
真正成熟的做法不是“什么都复制”，而是分清：
- 项目资产
- 团队共享能力
- 用户个人习惯
把这三层分开，复制项目才会稳定，模板项目才不会越用越脏。
DISCUSSION
评论区