转载：http://book.odoomommy.com/chapter1/README8.html
Odoo的权限管理, 从粗到细可以大概分为四个等级, 对象级 视图级 字段级 记录级, 什么意思呢, 总结起来大概如下面的描述:
在了解这4个层级的权限控制之前, 我们首先要认知Odoo权限控制系统中的两大主角: 用户和组。
用户的概念就是我们平时其他系统中的用户概念, 它代表了可以合法访问系统资源的对象。
在odoo中，用户可以分为三种类型：
用户在odoo中对应的对象模型是res.users，12.0内置了两个用户，id为1的是一个名叫Odoobot的机器人，它会记录用户的操作。id为2的是超级管理员账号。
创建用户的同时，系统会自动创建一个partner对象，并关联到用户上。
未设置密码的用户不允许登录
odoo密码加密采用的是passlib库， passlib是一个跨平台的哈希算法库，支持30多种加密算法的实现。
DEFAULT_CRYPT_CONTEXT = passlib.context.CryptContext(
# kdf which can be verified by the context. The default encryption kdf is
# the first of the list
['pbkdf2_sha512', 'plaintext'],
# deprecated algorithms are still verified as usual, but ``needs_update``
# will indicate that the stored hash should be replaced by a more recent
# algorithm. Passlib 1.6 supports an `auto` value which deprecates any
# algorithm but the default, but Ubuntu LTS only provides 1.5 so far.
deprecated=['plaintext'],
)
由odoo的源代码，可以得知，默认采用的加密算法是pbkdf2_sha512，简单说就是通过哈希算法加盐迭代数次得出的结果作为密码的算法。
pdkdf2(Password-Based Key Derivation Function)，它的基本原理是通过一个伪随机函数（例如HMAC函数），把明文和一个盐值作为输入参数，然后重复进行运算，并最终产生密钥。如果重复的次数足够大，破解的成本就会变得很高。而盐值的添加也会增加“彩虹表”攻击的难度。
我们看一个经过这种加密算法得出的密码结构：
$pbkdf2-sha512$25000$tJbyHoNwLuX8f2.N8b43Bg$ViWUeJEtLMCm.NSmtMkZzG5M8.e312gzuee93VXqgGL.5izRTBL/Eza/7HMs.51SdpRjnRV2dVvCziQ3uTy07Q
密码通过$符号被分隔成4部分，第一个部分是计算算法名称，第二个是迭代次数，第三部分是盐值，第四部分是hash值。
12.0之前用户加密后的密码存在password_crypt字段中，12.0取消了这个字段，不再以明文存储。
密码的验证
odoo的密码验证使用passlib提供的verify_and_update方法，这个方法会根据当前密码使用的策略是否过时返回新策略的哈希值或空值。
odoo中验证用户密码使用低阶方法_check_credentials即可。
用户对象
用户对象(res.users)常用的几个方法有：
has_group
has_group方法用于确认用户是否属于某个用户组，接受一个参数xml_id。这里的xml_id指的是用户组的xmlid，例如：
self.env.user.has_group('base.group_system')
base.group_system 指代的是系统中的管理权限，意思就是判断当前用户是否是管理员组的成员。
用户组在odoo中的对象模型是res.groups，一个组里包含多个用户与用户是一对多的关系。
忘记密码
如果管理员忘记了密码，可以通过修改数据库的加密密码字段进行重置。方便起见，这里提供一个小工具，用于生成odoo要求的加密格式的密码。
#!/usr/bin/python3
# @Time : 2019-08-07
# @Author : Kevin Kong (kfx2007@163.com)
"""密码生成器"""
import passlib.context
DEFAULT_CRYPT_CONTEXT = passlib.context.CryptContext(
# kdf which can be verified by the context. The default encryption kdf is
# the first of the list
['pbkdf2_sha512', 'plaintext'],
# deprecated algorithms are still verified as usual, but ``needs_update``
# will indicate that the stored hash should be replaced by a more recent
# algorithm. Passlib 1.6 supports an `auto` value which deprecates any
# algorithm but the default, but Ubuntu LTS only provides 1.5 so far.
deprecated=['plaintext'],
)
def generate_password(password):
print(DEFAULT_CRYPT_CONTEXT.encrypt(password))
generate_password("admin")v
把这段代码保存为python文件运行即可。
这里提供一个原文为admin的加密示例，忘记密码的同学可以直接在数据库中将password字段修改为该字符串即可登录。
$pbkdf2-sha512$25000$X2vNmTMGAABAyDknJCTE2A$50FI91rr9B0JO8eAHKPqSPw0IPjYLfSSSTWeVFA5eK4yU8v79OwTZ3QxpEFXbGFivqMu6pohc5UltojXgfLlbg
或者直接执行下面的sql:
update res_users set password = '$pbkdf2-sha512$25000$X2vNmTMGAABAyDknJCTE2A$50FI91rr9B0JO8eAHKPqSPw0IPjYLfSSSTWeVFA5eK4yU8v79OwTZ3QxpEFXbGFivqMu6pohc5UltojXgfLlbg' where id = 2;
一般通过xml来定义组，跟定义视图类似，不过一般与用户安全相关的文件都放在security文件夹下。下面就是一个典型的组的定义：
<record id="group_sale_order_dates" model="res.groups">
<field name="name">Manage delivery dates from sales orders.</field>
<field name="category_id" ref="base.module_category_hidden"/>
<field name="comment">This option introduces extra fields in the sales order to easily schedule product deliveries on your own: expected date, commitment date, effective date.</field>
</record>
如果希望模块在安装的过程中就将系统预置的用户加入到我们定义的组中，那么可以在xml中像下面这样定义：
<record model="res.users" id="base.user_root">
<field eval="[(4,ref('base.group_partner_manager'))]" name="groups_id"/>
</record>
组的继承
组也是可以被继承的，方法是在组的定义中使用implied_ids字段来指明要继承的组。
<record id="group_shop_user" model="res.groups">
<field name="name">门店店员</field>
<field name="category_id" ref="portal_category_healthelement"/>
<field name="implied_ids" eval="[(4,ref('point_of_sale.group_pos_user'))]"/>
<field name="comment">门店店员，只能查看所属门店的使用权限</field>
</record>
接下来，我们给我们的书店应用创建两个组，店员和书店管理员。在这之前，我们要先创建一个应用分类。所谓应用分类，就是你在用户管理列表中看到分类，本质上是一个ir.module.category对象：
添加分类的方式和添加组类似：
<record model="ir.module.category" id="categ_book_store">
<field name="name">西西弗书店</field>
</record>
然后我们添加两个组，一个店员一个管理员：
<record id="group_shop_user" model="res.groups">
<field name="name">门店店员</field>
<field name="category_id" ref="categ_book_store"/>
<field name="implied_ids" eval="[(4,ref('base.group_user'))]"/>
<field name="comment">门店店员，只能查看所属门店的使用权限</field>
</record>
<record id="group_shop_manager" model="res.groups">
<field name="name">门店店长</field>
<field name="category_id" ref="categ_book_store"/>
<field name="implied_ids" eval="[(4,ref('group_shop_user'))]"/>
<field name="comment">门店店长，只能管理自己的门店</field>
</record>
base.group_user是odoo中内置的内部用户的xml_id,因为我们的模块是内部应用，因此继承该组就不用再为了登录再重新分配权限。
升级西西弗斯书店模块，我们就能看到自己的组出现在了用户的权限列表中：
用户和组有了，那么怎么控制用户的访问权限呢？
odoo对于用户的访问权限的设置有多级设计，大致可以分为如下几个层级：
严格层度由大到小，菜单级仅仅是控制菜单的可见与否，并不能阻止用户通过URL直接访问对象界面。对象级才是真正访问控制的一级，渲染页面时，odoo会验证该页面所有引用到的对象与当前访问用户的权限关系，只有拥有访问权限的用户才能访问到页面。视图级是控制当前页面的某些部分只能由某些有权限的组访问，比如，产品的成本信息等。字段级，精确到某个字段应该由哪些组可以访问。
本节只介绍对象级的访问控制。其余将在第二部分介绍。
对象的访问权限主要控制的内容有读取(read)、创建(create)、修改(write)和删除(delete)，也就是你在odoo的组的权限tab页中看到的内容：
即一个组对哪些对象，拥有哪些权限。通常这些由系统管理员进行配置。不过通常编写的模块都会将权限预置，在安装模块的时候就已经写入到数据库中了。预置的方法就是在security文件夹下新建一个csv文件，并配置在manifest文件的data中。csv文件的格式如下:
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_book_store_book,book_store.book,model_book_store_book,base.group_user,1,1,1,1
access_book_store_author,book_store.author,model_book_store_author,base.group_user,1,1,1,1
access_book_store_publisher,book_store.publisher,model_book_store_publisher,base.group_user,1,1,1,1
access_book_store_ebook,book_store.ebook,model_book_store_ebook,base.group_user,1,1,1,1
access_book_store_sbook,book_store.sbook,model_book_store_sbook,base.group_user,1,1,1,1
继承的组会自动继承父组中的访问权限，因此，在父组中拥有的访问权限不必在子组中再次声明。
访问权限只能限制用户组对改对象的访问权限，并不能限制特定用户对某些记录的访问。举例来说，销售人员A拥有对销售单sale.order的访问权限，他能够看到全公司的销售单。很显然，这是现实生活中不可以接受的情况。通常的规则是，销售人员只能看到自己创建的销售单据。在odoo中，这种需求的解决方案就是规则(ir.rule)。
规则的管理在系统设置-技术设置-安全-记录规则中：
规则的设置主要有一下几点：
前面的例子中，销售人员只能看到自己的销售单，应用的规则domain是：
['|',('user_id','=',user.id),('user_id','=',False)]
"|" 代表的是或关系，"&"代表与关系，一般可以省略。user_id是销售单上的销售人员字段，该domain翻译过来的过滤条件即：过滤出销售单中销售人员是我，或者没有销售人员的单据。
我们在使用权限的过程中，可能会碰到由于安全原因提示有关记录不能被访问的提示。通常是由读取当前对象的字段时关联到了其他对象，而其他对象由于记录规则的原因导致当前用户没有权限访问而提示出错。 如果关联字段时计算字段，那么可以使用sudo提权来规避报错，如果是非计算字段，那么可以在视图中的字段上添加权限组，用来规避当前用户没有权限，odoo视图中没有出现的字段是不会被读取到的，因此也就不存在访问错误。
本章介绍了用户和用户组，以及用户组中的访问权限设置和用户规则，读者可以试着自己创建一个组并设置权限，练习一下吧。