除隐藏外，是否有其他禁用Settings应用的方法？Odoo权限回收异常求助

一、除隐藏应用外，拒绝用户访问Settings的其他方法 #

• 严格管控用户组权限：确保用户不属于任何拥有Settings访问权限的组，核心是移除用户与base.group_system（系统管理员组）的关联，同时检查自定义组是否继承了该组权限，彻底切断权限来源。
• 记录规则限制操作权限：针对res.config.settings模型创建记录规则，限制特定用户/组的读写权限。即使用户能看到Settings入口，也无法查看或修改任何设置内容。
• 视图层面精准隐藏入口：开发轻量自定义模块，通过XML视图继承，为特定用户组隐藏Settings菜单入口，比全局隐藏更灵活，可实现精细化权限控制。
• 菜单级权限规则阻断：创建针对ir.ui.menu模型的记录规则，直接限制用户访问Settings对应的菜单记录，从入口层面完全阻断访问。

二、权限回收后Settings模块仍显示的问题排查与修复 #

常见原因及解决步骤： #

• 强制清除浏览器缓存：Odoo Web客户端会缓存菜单权限数据，按Ctrl+Shift+R强制刷新页面，清除本地缓存后重新加载。
• 清空服务器端缓存：
  • 开发者模式下：进入「设置 -> 技术 -> 缓存管理」，点击「清除所有缓存」。
  • 命令行方式：重启Odoo服务时添加参数 ./odoo-bin --clear-cache。
  • Python Shell：执行env['ir.ui.menu'].clear_caches()强制清除菜单缓存。
• 检查组继承关系：查看res.groups表的parent_id字段，确认用户所在组是否通过继承链间接获得Settings权限，若有则调整组继承关系。
• 重新计算用户菜单：开发者模式下，找到Settings对应的菜单记录（路径：「设置 -> 技术 -> 用户界面 -> 菜单」），点击「动作 -> 更新菜单」；或执行env['ir.ui.menu'].update_menu()方法强制重新生成用户可见菜单列表。
• 排查自定义模块干扰：部分自定义模块可能重写了菜单权限逻辑或硬编码显示Settings菜单，临时禁用近期安装的模块，测试是否恢复正常。

内容的提问来源于stack exchange，提问作者K.D