odoo13-addon-role-policy 13.0.1.1.1

菜单、操作和字段上的默认访问权限

Odoo的标准做法是在没有安全组的情况下，允许用户访问所有菜单项和动作绑定。本模块改变了这种做法。注意：也可以添加客户端动作！每个菜单项和动作绑定都必须明确添加到角色中，才能供用户使用。

除了“不可触碰的组”外，所有标准组都被从菜单和动作中移除。这些默认为：

• base.group_no_one

• base.group_erp_manager

• base.group_system

• base.group_portal

• base.group_public

视图上的默认访问权限

在本模块的当前版本中，视图访问通过以下组合来保证安全：

• 视图模型ACL

• 动作绑定

• 菜单项

在视图加载时也会移除视图架构内的组。

为了弥补在视图元素上添加组的能力，添加了一个新的属性：“角色”，其值为角色代码列表。

角色属性的作用类似于组属性：如果用户不属于指定的角色之一，视图元素将被移除。

语法

<button roles="R1, R2" name="button_name" type="object" />

必须使用视图修改器规则来隐藏视图元素。

视图修改器规则

最大的区别可能是“视图修改器规则”部分，它取代了标准视图继承机制，例如在某些角色需要隐藏某些字段时。视图修改器规则有一个优先级字段，用于确定在为单个用户授予多个角色时哪个规则是获胜的。

组合角色可能会导致最终用户遇到意外结果。例如，一个用户可以在某个角色中访问某个按钮，但在组合角色中失去访问权限。

建议具有多个角色的用户通过其偏好设置（默认情况下，所有角色都是组合的）选择启用的角色。

在视图/视图元素方法与其他角色策略规则的不同之处在于，由于在视图渲染时标准安全组被移除，每个视图/视图元素都发送到用户界面。我们不想引入管理负担来明确在角色中定义每个视图/视图元素。因此，必须通过删除选项来删除不想要的视图或视图元素。

不可见和删除之间的区别是至关重要的，因为不可见意味着用户需要ACL访问不应渲染的字段。

视图修改器规则还允许设置特定元素的修饰符，而不指定视图，例如隐藏对象上所有视图的特定字段。可以通过应用特定的视图类型进一步细化。不允许在不定义视图的情况下使用删除选项。

由于复杂的环境可能有许多视图修改器规则，本模块允许加载大型的规则集而不进行语法检查。因此，从Excel加载新角色可能会导致相关用户的屏幕错误。将提供一个语法检查按钮，以在可行的情况下进行语法检查和自动纠错。

视图类型属性规则

使用此功能，视图类型属性（如创建、编辑、删除、复制、导入、导出_xlsx）成为基于角色的。任何此类属性都可以用这些规则替换（例如基于角色的装饰-%）。

视图模型操作规则

使用此功能，所选模型的一组操作成为基于角色的。定义这些操作将对模型上定义的所有视图产生影响。

您还可以通过指定default作为模型名称来为所有模型设置默认值。

支持的操作

• 创建

• 编辑

• 删除

• 复制

• 导出

• 导入

• 存档

模型方法

通过“模型方法”选项卡，您可以授予对ORM模型上预定义方法集的执行权限。

role_policy 基础模块提供了该功能的框架。需要应用特定模块来扩展预定义的方法集。

添加额外的方法只需要几行代码。它包括通过模型方法扩展选择列表，将角色策略查找添加到方法中，并传递 role_policy_has_groups_ok 上下文。

例如，模块 role_policy_account 将 account.move,post 方法添加到该列表中

class AccountMove(models.Model):
    _inherit = "account.move"

    def post(self):
        self.env["model.method.execution.right"].check_right(
            "account.move,post", raise_exception=True
        )
        ctx = dict(self.env.context, role_policy_has_groups_ok=True)
        self = self.with_context(ctx)
        return super().post()

此集合中定义的方法仅对在 模型方法 笔记本页中添加了它们的角色可用。

组合角色 - 角色策略选择器

组合角色可能会导致最终用户遇到意外结果。例如，一个用户可以在某个角色中访问某个按钮，但在组合角色中失去访问权限。

以下规则具有优先级字段，用于确定在授予单个用户多个角色时获胜的规则

• 视图修改器规则

• 视图类型属性规则

• 视图模型操作规则

其中，用户角色的一个规则没有被视为最高优先级。

这种逻辑在某些业务场景中是有意义的，但对于其他用例来说可能是完全错误的。实际上，不可能达成一组可维护的角色并配置所有可能的组合角色的用例。

在大型组织中，新角色将定期添加。为了确保新角色可以与所有现有角色组合，维护一致的规则会导致数百万种组合，因此难以维护。

一个具体的例子来说明获胜规则逻辑

Let's assume we have three roles: Back Office Sales (BO), Sales Manager (SM), Finance Manager (FM)

Now we define the following View Modifier Rules on a Sale Order:

- partner_id readonly=1 for role BO, with priority 2 for this rule.
- partner_id readonly=0 for role FM, priority 1.
- no partner_id rule for role SM

Now the Finance Manager goes on leave and the security officer temporarily adds the FM role to a Back Office Sales employee.
This person will now be able to change the partner_id on a Sale Order because of the highest priority rule wins.

The SM will always be able to change the partner_id field since the standard Odoo Sale Order form allows this.
If the SM temporarily needs to take over BO tasks and hence gets the two roles he will still be able to
change the Sale Order partner_id field because no rule for one of the user roles is considered highest priority.

But if we now add the partner_id rule to the SM role with readonly=0 and standard priority 16, than we get
as result that the SM can update the partner_id in his SM role but looses this capability in the combined SM/BO role.

应通过创建新角色来解决此类冲突，从而避免需要组合角色。

如果有人需要临时接管同事的活动，创建新角色是不现实的。

为此应使用 角色策略选择器。

通过“我的个人资料”表单，用户可以选择他的“启用角色”作为他有权获得的角色的子集。通过这样做，他将获得启用角色的功能，而不是所有角色的组合。

管理员用户

以下用户不应用角色策略规则

• base.user_admin

• base.user_root

这是为了避免管理员用户无法再纠正错误（例如，当在 res.users 上禁用编辑时）。

从安全角度出发，建议仅在特殊情况下使用管理员账户（base.user_admin），并创建其他具有管理权限的账户以维护 Odoo 配置。

用户类型/内部用户

在当前模块的实现中，每个用户都被添加到标准的“base.group_user（用户类型/内部用户）”安全组。大多数 Odoo 模块也会添加新对象以及在这些新对象上的 ACL。在许多情况下，这些标准 ACL 被设置为针对此 base.group_user* 组。

这可能会导致授予用户过多的权限，因为从 ACL 的角度来看，新用户收到 group.group_user ACL 和其角色（的）ACL 的组合权限。

目前正在进行将常规用户从“base.group_user”组中删除的调查。

ACL

创建新用户时，唯一可用的对象是具有

• 全局 ACL 的对象（例如，res_country group_user_all，授予对 res.country 的读取访问权限）

• base.group_user ACL（例如，ir_ui_menu group_user，授予对 ir.ui.menu 的读取访问权限）

当将用户添加到一个或多个角色中时，此用户也将获得其角色（的）中定义的所有 ACL 权限。

多公司设置

角色可以在公司之间共享。为了做到这一点，您应该调整 res.role，company_id 字段的默认功能。

导入/导出

您可以将导出的策略文件更改为更新角色或创建新角色。

为了删除条目，您应在“删除条目”列（列标题）的列中输入“X”。

在导入过程中将忽略以“#”开头的任何行。

标准组删除

移除标准组可能会导致意外的行为，因为有几个模块在Python中硬编码使用了标准组。

例如，在销售模块中我们发现以下代码块

def _compute_sales_count(self):
    r = {}
    self.sales_count = 0
    if not self.user_has_groups('sales_team.group_sale_salesman'):
        return r

从安全管理的角度来看，这并不干净，但这是使用该模块的公司必须面对的现实。只有经验丰富的Odoo开发者才能找出并修复由此做法引起的问题。

我们的意图是创建一套自动安装的模块，称为role_policy_X，其中X是已经对这种编码实践进行过修改的模块名称。这样，安全官员就可以配置角色，而不需要过度依赖Odoo开发技能。

例如，role_policy_sale。

演示数据库

您可以通过安装role_policy_demo模块来更好地了解该模块的工作方式。

目录

作者

• Noviat

贡献者

• Luc De Meyer <luc.demeyer@noviat.com>

• Els Van Vossel <els.vanvossel@noviat.com>

其他鸣谢

本模块的开发得到了以下机构的财务支持

CANNA

维护者

此模块由OCA维护。

OCA，即Odoo社区协会，是一个非营利组织，其使命是支持Odoo功能的协作开发并推广其广泛应用。

当前维护者

此模块是GitHub上OCA/role-policy项目的一部分。

欢迎您贡献力量。要了解如何贡献，请访问https://odoo-community.org/page/Contribute。