高度封装的前后端框架-odoo回顾(四):翻译官方教程＜＜高级B:ACL和记录规则＞＞

Advanced B: ACL and Record Rules

高级B: ACL和记录规则

Warning:
警告:

This tutorial assumes you have completed the Core Training.
这个教程默认你完成了核心训练(官方教程)

To follow the exercise, it is recommended that you fetch the branch 14.0-core from the repository XXX, it contains a version of the module created during the core training we can use as a starting point.
为了完成训练,推荐你拉下来14.0-core的代码,它包含了核心训练时候我们拿来做开始点训练的版本

So far we have mostly concerned ourselves with implementing useful features. However in most business scenarios security quickly becomes a concern: currently,
到目前位置,我们几乎只关注现实中有用的特性.但是在多数商业场景中,安全很快变成一个问题: 就现在;

• Any employee (which is what group_user stands for) can create, read, update or delete properties, property types, or property tags.
• 任何雇员(group_user代表的)可以增删改查财产,财产类型,或者财产标签
• If estate_account is installed then only agents allowed to interact with invoicing can confirm sales as that’s necessary to create an invoice.
• 如果estate_account 被安装,然后只有经纪人(允许和发票交互)可以确认交易,因为我们必须创建一个发票

However:
但是

• We do not want third parties to be able to access properties directly.

• 我们不想第三方能够直接访问不动产(之前核心训练,就是创建不动产模块的例子)

• Not all our employees may be real-estate agents (e.g. administrative personnel, property managers, …), we don’t want non-agents to see the available properties.

• 不是所有的我们的雇员都是不动产的经纪人(例如广告上,不动产经理),我们不想非经纪人看到有用的房地产

• Real-estate agents don’t need or get to decide what property types or tags are available.

• 房地产经纪人不需要或去决定财产类型或者标签是否有效

• Real-estate agents can have exclusive properties, we do not want one agent to be able to manage another’s exclusivities.

• 房地产经纪人可以拥有独家房地产,我们不想要一个经纪人能够管理另外经纪人的独家房地产

• All real-estate agents should be able to confirm the sale of a property they can manage, but we do not want them to be able to validate or mark as paid any invoice in the system.

• 所有房地产经纪人应该能够确认他们管理的不动产的交易,但是我们不想要他们能够校验或者标记任何发票为已经付款,在我们的系统里

Note
记住:

We may actually be fine with some or most of these for a small business.
在小型企业,我们可能对这些里面的一些或者大部分问题还感觉ok

Because it’s easier for users to disable unnecessary security rules than it is to create them from nothing,
因为对于用户来说很容易禁用非必要的安全规则,相比于从0创建.
it’s better to err on the side of caution and limiting access: users can relax that access if necessary or convenient.
(相比于其他方面),最好在谨慎和限制访问方面出错: 如果有必要或者图方便,用户可以放松访问规则

1 Groups

1 组

See also
参考
The documentation related to this topic can be found in the security reference.
和这个主题相关的文档可以在安全索引中找到
The guidelines document the format and location of master data items.
该指南记录了主数据项的格式和位置。

Goal
目标

At the end of this section,
在这一节结尾

• We can make employees real-estate agents or real-estate managers.
• 我们可以使员工成为房地产经纪人或者经理
• The admin user is a real-estate manager.
• 管理员用户是房地产经理
• We have a new real-estate agent employee with no access to invoicing or administration.
• 我们有一个新的房地产经济人雇员,但是无法开具发票或者管理

It would not be practical to attach individual security rules to employees any time we need a change so groups link security rules and users.
每当我们需要一个改变,去调整每个雇员的安全规则,这显然不具有可操作性,所以组关联了安全规则和用户.

They correspond to roles that can be assigned to employees.
他们对应着可以分配给员工的角色

For most Odoo applications 1 a good baseline is to have user and manager (or administrator) roles: the manager can change the configuration of the application and oversee the entirety of its use while the user can well, use the application 2.
对于大多数odoo应用,一个好的底线是,拥有用户和管理员(或者admin)角色: 管理员可以改变应用配置和监督整体运行,用户是否能够很好的使用应用

This baseline seems sufficient for us:
这条底线对我们来说够用了:

Real estate managers can configure the system (manage available types and tags) as well as oversee every property in the pipeline.
房地产经理可以配置系统(管理可用类型和标签),也监督系统中的每一个房产
Real estate agents can manage the properties under their care, or properties which are not specifically under the care of any agent.
房地产经纪人可以管理归他们照顾的房地产,或者任何没有经纪人认领的房地产

In keeping with Odoo’s data-driven nature, a group is no more than a record of the res.groups model. They are normally part of a module’s master data, defined in one of the module’s data files.
和odoo的数据驱动现状保持一样,一个组不过是res.groups模型的一条数据.他们一般是模块主数据的一部分.

As simple example can be found here.
一个简单的例子可以在这里被找到(这里关联一个github链接,因为访问不了,暂时就不展示了)

what is the category_id?
什么是category_id

category_id a module category, it is automatically generated from the category defined in module manifest files.
category_id是模块的分类,它自动从模型module manifest文件中定义的类型中生成

Exercise
练习

• Create the security.xml file in the appropriate folder and add it to the manifest.py file.

• 创建security.xml文件到合适到文件夹,并且把它加到__manifest__.py文件中

• Add a record creating a group with the id estate_group_user, the name “Agent” and the category base.module_category_real_estate_brokerage.

• 增加一条记录去创建一个组,使用estate_group_user作为id,Agent作为名称,base.module_category_real_estate_brokerage作为分类

• Below that, add a record creating a group with the id estate_group_manager, the name “Manager” and the category base.module_category_real_estate_brokerage. The estate_group_manager group needs to imply estate_group_user.

• 下面,增加一条记录,创建一个组,使用estate_group_manager为id, manager为名称 base.module_category_real_estate_brokerage为分类.estate_group_manager 组需要继承estate_group_user

Tip:
贴士:

Since we modified data files, remember to restart Odoo and update the module using -u estate.
因为我们改变了数据文件,记住去重启odoo并且用-u estate来更新模块

If you go to Settings ‣ Manage Users and open the admin user (“Mitchell Admin”), you should see a new section:
如果你去 设置->管理用户 并且打开管理员 ‘Mitchell Admin’,你应该看到了下面的选项:

Set the admin user to be a Real Estate manager.
设置管理员用户到房地产经理

Exercise
练习

• Via the web interface, create a new user with only the “real estate agent” access. The user should not have any Invoicing or Administration access.
• 通过网页界面,创建一个用户,只赋予"不动产管理员"访问权.这个用户不应该有任何开票或者超级管理员入口
• Use a private tab or window to log in with the new user (remember to set a password), as the real-estate agent you should only see the real estate application, and possibly the Discuss (chat) application:
• 使用一个私有的标签或者窗口去记录新用户(记住去设置密码), 作为房地产经纪人,你应该只能看到房地产应用,和可能的讨论模块
  

2 Access Rights

2 访问权限

See also
也见:

The documentation related to this topic can be found at Access Rights.
关联到这个主题的文档可以从访问权限找到

Goal
目标

At the end of this section,
在这张结尾

• Employees who are not at least real-estate agents will not see the real-estate application.
• 不是房地产经纪人将不会看到不动产模块应用
• Real-estate agents will not be able to update the property types or tags.
• 房地产经纪人将不能够更新财产类型或者标签

Access rights were first introduced in Chapter 5: Security - A Brief Introduction.
访问权最初在第五章节介绍到: 安全-一个简单的介绍
Access rights are a way to give users access to models via groups: associate an access right to a group, then all users with that group will have the access.
访问权限是一条路径, 通过组,给用户一个访问模型的入口: 关联访问权到一个组,然后组内所有用户将会有这个入口
For instance we don’t want real-estate agents to be able to modify what property types are available, so we would not link that access to the “user” group.
举例来说, 我们不想要房地产经纪人能够改变那些财产类型是可用的,所以我们不会关联访问权限到"user"组
Access rights can only give access, they can’t remove it: when access is checked, the system looks to see if any access right associated with the user (via any group) grants that access.
访问权只能够给入口,他们不能移除: 当用户访问该入口,系统会检查该用户是否被赋予了该访问权

group	create	read	update	delete
A	X	X
B		X
C			X

A user with the groups A and C will be able to do anything but delete the object while one with B and C will be able to read and update it, but not create or delete it.
A用户如果被授予A组或者C组,将会能够做任何删对象除以外的事情,但是如果被授予B和C,将只能够阅读或者更新,但是创建删除不了它

Note
记住:
The group of an access right can be omitted, this means the ACL applies to every user, this is a useful but risky fallback as depending on the applications installed it can grant even non-users access to the model.
一个访问权组可以被省略, 这意味着ACL适用于任何用户,这是一个有用但是危险的后备方案,因为依据安装的应用程序,它甚至可以被赋予非用户

If no access right applies to a user, they are not granted access (default-deny).
如果没有访问权适配到用户,他们就没有被赋予任何入口(默认-否定)
If a menu item points to a model to which a user doesn’t have access and has no submenus which the user can see, the menu will not be displayed.
如果一个指向某个模型的菜单,是一个用户没有访问权的,且没有这个用户也没权限看到任何子菜单,拿这个菜单就不会出现.

Exercise
练习
Update the access rights file to:
更新访问权文件到:

• Give full access to all objects to your Real Estate Manager group.
• 给一个对象所有的访问权到你的房地产经理
• Give agents (real estate users) only read access to types and tags.
• 给经纪人(房地产用户)只读类型和标签的权力
• Give nobody the right to delete properties.
• 不给任何人删除房地产的权限
  Check that your agent user is not able to alter types or tags, or to delete properties, but that they can otherwise create or update properties.
• 检查你的经纪人用户是否不能够改变类型或者标签,或者删除不动产,但是他们能创建或者更新房地产
  Warning
  警告:

Remember to give different xids to your ir.model.access records otherwise they will overwrite one another.
记住去给不同的xid到你ir.model.access记录,否则他们一个会被另外一个覆盖

Since the “demo” user was not made a real-estate agent or manager, they should not even be able to see the real-estate application. Use a private tab or window to check for this (the “demo” user has the password “demo”).
因为demo用户没有变成经纪人或者经理,它甚至不能够看到不动产应用.使用一个私有标签或者窗口去检查

3 Record Rules

3 记录规则

See also
参见:
The documentation related to this topic can be found at Record Rules.
这个主题的相关文档可以在这里被找到: 记录规则
Goal
目标:

At the end of this section, agents will not be able to see the properties exclusive to their colleagues; but managers will still be able to see everything.
在这一节结尾,经纪人将不能够看到他同事的独家记录

Access rights can grant access to an entire model but often we need to be more specific: while an agent can interact with properties in general we may not want them to update or even see properties managed by one of their colleagues.
访问权可以授予一个模型的全部访问权,但是我们经常需要有更多区分:当一个经纪人能够和所有房地产交互时候,我们可能不想要他们能够更新或者看到被他同事管理的房地产

Record rules provide that precision: they can grant or reject access to individual records:
记录规则提供这种精度: 他们可以授予或者阻止访问到具体的记录

    A description of the rule's role
    
    
    
    [
        '|', ('user_id', '=', user.id),
             ('user_id', '=', False)
    ]

The Search domains is how access is managed: if the record passes then access is granted, otherwise access is rejected.
搜索domains展示如何管理它: 如果一条记录通过了(搜索domain),则访问被授权

Tip
贴纸:

Because rules tends to be rather complex and not created in bulk, they’re usually created in XML rather than the CSV used for access rights.
因为规则倾向于更复杂和非批量创建,它们通常在XML文件中创建而非用于访问权限的CSV

The rule above:
以上规则:

• Only applies to the “create”, “update” (write) and “delete” (unlink) operations: here we want every employee to be able to see other users’ records but only the author / assignee can update a record.
  只应用于创建,更新,删除项: 这里我们想要每个雇员能够看到别的用户的记录,但是只有作者/受让人可以更新记录
• Is non-global so we can provide an additional rule for e.g. managers.
• 是非全局的,所以我们能够提供额外的规则,比如经理
• Allows the operation if the current user (user.id) is set (e.g. created, or is assigned) on the record, or if the record has no associated user at all.
• 如果当前用户(user.id)被设置到记录上或者如果这个记录没有关联到用户,操作则被允许

Note
记住:
If no rule is defined or applies to a model and operation, then the operation is allowed (default-allow), this can have odd effects if access rights are not set up correctly (are too permissive).
如果没有规则被定义或者适用到模型或者操作上,则操作是被允许的(默认允许).如果访问权限没有被正确设置,这可能有奇怪的影像

Exercise
练习
Define a rule which limits agents to only being able to see or modify properties which have no salesperson, or for which they are the salesperson.
定义一个规则,
You may want to create a second real-estate agent user, or create a few properties for which the salesperson is a manager or some other user.
你应该想要创建第二个房地产经纪人用户,或者创建几个房地产,去给卖家是经理或者其他用户
Verify that your real estate manager(s) can still see all properties. If not, why not? Remember:
The estate_group_manager group needs to imply estate_group_user.
检查你的房地产经理仍然可以看到所以房产,如果不是,为什么看不到呢?记住:
房地产经理需要继承estate_group_user

4 Security Override

4 安全重写

Bypassing Security

绕过安全

Goal
目标

At the end of this section, agents should be able to confirm property sales without needing invoicing access.
这张结尾,经纪人应该能够确认房地产交易,无需发票权限
If you try to mark a property as “sold” as the real estate agent, you should get an access error:

如果你尝试标记一个房地产被房地产经纪人"已售",你应该会有一个错误:

This happens because estate_account tries to create an invoice during the process, but creating an invoice requires the right to all invoice management.
这发生了,是因为在这个过程中,estate_account 尝试创建一个发票,但是创建一个发票需要所有发票管理的权限

We want agents to be able to confirm a sale without them having full invoicing access, which means we need to bypass the normal security checks of Odoo in order to create an invoice despite the current user not having the right to do so.
我们想要经纪人能够确认一次交易,而无需他们拥有全部发票权限,这就意味着我们需要绕过odoo的常规安全检查去创建发票,尽管当前用户没有权力做这个

There are two main ways to bypass existing security checks in Odoo, either wilfully or as a side-effect:
在Odoo中,有两个主要的途径绕过现存安全检查,要么故意的,要么是副作用

The sudo() method will create a new recordset in “sudo mode”, this ignores all access rights and record rules (although hard-coded group and user checks may still apply).
sudo()方法将会在'sudo模式'下创建一个新的记录集,这回忽略访问权限和 记录规则(尽管硬编码的组和用户检查还在应用)

Performing raw SQL queries will bypass access rights and record rules as a side-effect of bypassing the ORM itself.
执行通用SQL插件将会绕过访问权限和记录规则,作为绕过ORM的副作用

Exercise

Update estate_account to bypass access rights and rules when creating the invoice.

Danger
危险:
These features should generally be avoided, and only used with extreme care, after having checked that the current user and operation should be able to bypass normal access rights validation.
这些特性通常应该放弃使用,并且只能在高度关注下使用: 完成了检查当前用户和操作应该能够绕过常规访问全校验

Operations performed in such modes should also rely on user input as little as possible, and should validate it to the maximum extent they can.
在这种模式下的执行的操作应该尽可能少的依靠用户输入,并且应该尽可能大的校验用户输入

5 Programmatically checking security

5 编程的方式检查安全

Goal

At the end of this section, the creation of the invoice should be resilient to security issues regardless to changes to estate.
在这一届结尾,创建发票应该变成一个有弹性的安全议题,不管房产的创建

In Odoo, access rights and record rules are only checked when performing data access via the ORM e.g. creating, reading, searching, writing, or unlinking a record via ORM methods. Other methods do not necessarily check against any sort of access rights.
在odoo,访问权和记录规则只是在通过操作ORM(如增删改查或者通过执行ORM方法)操作数据的时候被检查．其他方法不一定检查任何访问权限

In the previous section, we bypassed the record rules when creating the invoice in action_sold. This bypass can be reached by any user without any access right being checked:
在上一节，当我们在action_sold中创建发票的时候,我们绕过了记录规则.这种绕过可能被任何用户使用,没有任何访问权限被检查

Add a print to action_sold in estate_account before the creation of the invoice (as creating the invoice accesses the property, therefore triggers an ACL check) e.g.:
创建发票之前,在estate_account中增加一个点(因为创建发票访问了房地产,所以触发了ACL检查)

    print(" reached ".center(100, '=')

Execute bypass.py in estate_account, giving it the name of your database, and the name of your version of action_sold (unless you named it action_sold then it’s fine)
在estate_ccount中执行 bypass.py,给它你数据的没吃,和你的版本的action_sold的名字(除非你就把他命名为action_sold)

You should see reached in your Odoo log, followed by an access error.
你应该看到你odoo中的日志显示:下面的访问权错误:

Danger
危险

Just because you’re already in Python code does not mean any access right or rule has or will be checked.
因为你已经在python代码中,不意味着任何权限或者规则将会被检查

Currently the accesses are implicitly checked by accessing data on self as well as calling super() (which does the same and updates self), triggering access errors and cancelling the transaction “uncreating” our invoice.
当前,访问权通过数据时候调用super()被隐式检查的(更新自身的时候也一样),触发访问权错误和取消事务"不创建"我们的发票

However if this changes in the future, or we add side-effects to the method (e.g. reporting the sale to a government agency), or bugs are introduced in estate, … it would be possible for non-agents to trigger operations they should not have access to.
但是如果在将来发生变化,或者我们增加副作用到方法上(比如报告销售情况到政府部门),或者引入了错误,…对于非经纪人来说,触发他们没有的操作也是可能的

Therefore when performing non-CRUD operations, or legitimately bypassing the ORM or security, or when triggering other side-effects, it is extremely important to perform explicit security checks.
因此,当操作非增删改查操作的时候,或者合法的绕过ORM或者安全见a,或者当触发其他副作用时候,执行明确的安全检查就格外重要了

Explicit security checks can be performed by:
明确的安全检查可以通过以下方式执行:

• Checking who the current user is (self.env.user) and match them against specific models or records.
  检查当前用户是谁(self.env.user),将他们和特定的模型匹配

• Checking that the current user has specific groups hard-coded to allow or deny an operation (self.env.user.has_group).

• 检查当前用户是是否有特定的组,这些组硬编码允许或者禁止操作(self.env.user.has_group)

• Calling the check_access_rights(operation) method on a recorset, this verifies whether the current user has access to the model itself.

• 在记录集上调用check_access_rights(操作)方法,浙江检查当前用户是否有权限操作模型

• Calling check_access_rule(operations) on a non-empty recorset, this verifies that the current user is allowed to perform the operation on every record of the set.

• 在记录及上调用check_access_rule(操作),浙江检查当前用户是否允许在这个集合上执行动作

Warning
警告

Checking access rights and checking record rules are separate operations, if you’re checking record rules you usually want to also check access rights beforehand.
检查访问权和检查记录规则是独立的操作,

Exercise
练习
Before creating the invoice, use check_access_rights and check_access_rule to ensure that the current user can update properties in general, and this specific property in particular.
创建发票之前,使用check_access_rights 和check_access_rule 去确认当前用户能否更新一般的不动产,和特定的不动产
Re-run the bypass script, check that the error occurs before the print.

6 Multi-company security

6 多公司安全

See also
参见:
Multi-company Guidelines for an overview of multi-company facilities in general, and multi-company security rules this in particular.
多公司指南概述了多公司设施的总体情况，尤其是多公司安全规则。
Documentation on rules in general can, again, be found at Record Rules.
总体上的规则任然可以从Record Rules.中找到

Goal
目标

At the end of this section, agents should only have access to properties of their agency (or agencies).
在这一届结尾,经纪人应该只能够访问他们机构的不动产

For one reason or an other we might need to manage our real-estate business as multiple companies e.g. we might have largely autonomous agencies, or a franchise setup, or multiple brands (possibly from having acquired other real-estate businesses) which remain legally or financially separate from one another.
因为一个或者几个原因,我们可能需要将我们的不动产业务作为几个公司管理.例如我们可能有大量的自主性的机构,或者特许经营设置,或者多品牌(可能来自于收购其他房地产公司),他们在法律上或者财务上彼此独立

Odoo can be used to manage multiple companies inside the same system, however the actual handling is up to individual modules: Odoo itself provides the tools to manage the issue like company-dependent fields and multi-company rules, which is what we’re going to concern ourselves with.
在同一个系统中,odoo可以用作管理多公司而,但是真是的操作是单独一个模块:odoo自身提供工具去管理公司依赖字段和多公司规则的议题,这就是我们要关联自身的业务到上面的

We want different agencies to be “siloed” from one another, with properties belonging to a given agency and users (whether agents or managers) only able to see properties linked to their agency.
我们想要不同的机构彼此"独立",房产属于给定的机构和用户(无论是经纪人或者经理)只能够看到和他们公司相关的不动产

As before, because this is based on non-trivial records it’s easier for a user to relax rules than to tighten them so it makes sense to default to a relatively stronger security model.
在之前,因为基于重要的记录,对于用户来说很容易放松规则(相对于收紧),所以使用一条偏于强大的安全模型就很重要了

Multi-company rules are simply record rules based on the company_ids or company_id fields:
多公司规则是简单的记录规则,基于company_ids或者company_id字段

company_ids is all the companies to which the current user has access
compay_ids是这个用户可以访问的所有公司
company_id is the currently active company (the one the user is currently working in / for).
compay_id 是当前活跃的公司(这个用于正在为其服务的)

Multi-company rules will usually use the former i.e. check if the record is associated with one of the companies the user has access to:
多公司规则将会通常使用前一个,检查这个记录是否关联到这个用户有访问权的公司

    Appraisal Plan multi-company
    
    [
        '|', ('company_id', '=', False),
             ('company_id', 'in', company_ids)
    ]

Danger
危险:
Multi-company rules are usually global, otherwise there is a high risk that additional rules would allow bypassing the muti-company rules.
多公司规则通常是全局的,否则有一个致命危险: 额外规则将会允许绕过多公司规则
Exercise
练习
Add a company_id field to estate.property, it should be required (we don’t want agency-less properties), and should default to the current user’s current company.
增加公司id字段到estate.property,它应该是必须的(我们不会想要不属于任何机构的不动产),并且应该默认为当前用于的当前公司

• Create a new company, with a new estate agent in that company.
  创建一个公司,并且创建一个新的不动产经纪人到该公司
• The manager should be a member of both companies.
  经理应该是两家公司的成员
• The old agent should only be a member of the old company.
• 旧的经纪人应该只是旧公司的经纪人
• Create a few properties in each company (either use the company selector as the manager or use the agents). Unset the default salesman to avoid triggering that rule.
  在每家公司创建几个房地产(使用选择器或者经纪人都行),不用设置默认卖家避免触发规则
• All agents can see all companies, which is not desirable, add the record rule restricting this behaviour.
• 所有的经纪人能看到所有的房地产,这是不可取的,增加记录规则,约束这种行为

Warning
警告

remember to --update your module when you change its model or data
记住 --update 你的模块,当你改变模型或者数据的时候

7 Visibility != security

7 可见不等于安全

Goal
目标

At the end of this section, real-estate agents should not see the Settings menu of the rea-estate application, but should still be able to set the property type or tags.
在这一节的结尾,房地产经纪人应该不能看到real-estate的设置菜单,但是应该仍然能够设置不动产类型或者标签
Specific Odoo models can be associated directly with groups (or companies, or users). It is important to figure out whether this association is a security or a visibility feature before using it:
具体的odoo模块可以被直接关联到组(或者公司,或者用户),在使用之前,对于弄清楚这种关联到底是安全或者可视化的特性是很重要的

Visibility features mean a user can still access the model or record otherwise, either through an other part of the interface or by perform operations remotely using RPC, things might just not be visible in the web interface in some contexts.
可见性特性意味着,一个用户仍然能够访问模型或者记录,无论通过界面的另外一部分,或者使用RPC执行远程操作,事物只是在一些网页界面的上下文中不可见

Security features mean a user can not access records, fields or operations.
安全特性意味着,一个用户不可能访问记录,字段或者操作

Here are some examples:
这里是一些例子

• Groups on model fields (in Python) are a security feature, users outside the group will not be able to retrieve the field, or even know it exists.

• 在模型字段(在python)上的组是安全特性,这个组外部的用户将不能够取到字段,甚至知道它是否存在

• Example: in server actions, only system users can see or update Python code.

• 例子: 在服务器动作中,只有系统用户可以简单或者更新python代码

• Groups on view elements (in XML) are a visibility feature, users outside the group will not be able to see the element or its content in the form but they will otherwise be able to interact with the object (including that field).

• 视图元素(在xml)上的组是可见性特性,组外用户将不能在表单中够看到元素或者内容,但是他们反而能够和对象交互(包括那些字段)

• Example: only managers have an immediate filter to see their teams’ leaves.

• 只有经理有即时过滤器来查看他们团队的休假。

• Groups on menus and actions are visibility features, the menu or action will not be shown in the interface but that doesn’t prevent directly interacting with the underlying object.

• 菜单和动作上的组是可视化特性,菜单或者动作将不在界面上展示,但是这不会阻止潜在的交互

• Example: only system administrators can see the elearning settings menu.

• 例子: 只有系统管理员能够看到在线学习的设置菜单

Exercise
练习

Real Estate agents can not add property types or tags, and can see their options from the Property form view when creating it.
不动产经纪人不能够添加财产类型或者标签,并且当使用时,能够从财产表单视图上看到他们的选项
The Settings menu just adds noise to their interface, it should only be visible to managers.
设置菜单只会让他们的界面变得杂乱,应该只对经理展示

Despite not having access to the Property Types and Property Tags menus anymore, agents can still access the underlying objects since they can still select tags or a type to set on their properties.
尽管没有不动产类型和不动产标签菜单的访问权了,经纪人仍然能够访问潜在的对象,因为他们能够选择标签设置到他们的不动产上

1

An Odoo Application is a group of related modules covering a business area or field, usually composed of a base module and a number of expansions on that base to add optional or specific features, or link to other business areas.

一个odoo应用是一组相关的模块,它们覆盖了一块商业领域或者地段,通常由一个基础模块和一些拓展模块组,拓展模块增加了可选的定制特性或者关联到其他商业领域
2

For applications which would be used by most or every employees, the “application user” role might be done away with and its abilities granted to all employees directly e.g. generally all employees can submit expenses or take time off.
对于一些将会被大部分或者每个员工使用的应用,应用用户角色应该被设置取消,并且授权给所有用户.例如所有员工都能提交费用报销或者请假