权限的默认规则

概要

由于权限的复杂度很高，有时会造成一些冲突，比如Action中配置“忽略用户权限范围”，同时在ActionConnect中又配置了”忽略用户权限范围的TAG“，此时就需要一些默认的冲突处理规则

权限规则

• SQL的注入支持@InjectSupport 注入的SQL的位置与tableNameWithAuthInject 层面相同
• 权限SQL会追加在ActionConnect中的tableNameWithAuthInject 层面，如果该值为空，则会放在最外层
• 业务权限中的拼接SQL总是拼接到tableNameWithAuthInject对应的SQL层（UPDATE/DELETE语句只会拼接到最外层），可以通过表名重命名将之前的表名更改成配置的表名来解决内部查询重命名后外部追加业务权限的功能，追加的业务权限SQL会和功能权限SQL进行拼接（根据配置的AND/OR进行拼接，如果是AND拼接则可能导致自己创建的数据无法查到，只能查到满足业务数据权限条件的数据）。
• 列权限中的排除字段只会追加到tableNameWithAuthInject配置相同的层面，如果该层面的SELECT查询没有配置的列，将会被忽略
• 功能权限设置为全部后，业务权限和列权限依然会生效
• 业务权限范围设置为”全部“或”自定义“时，则不会添加默认分公司过滤，职位权限范围设置为”自定义“时，不会添加默认分公司过滤。
• 通过PermContext.addUserNos()进行注入用户，如果未配置忽略用户，不会添加默认分公司过滤

冲突处理规则

• Action中配置”只过滤本公司时“，会自动忽略用户委托和组织委托
• 默认情况下总是进行公司的过滤，配置权限后，默认情况下总是会进行本公司的过滤，如果要去掉，可以在@Action中配置ignoreCompanyScopeTags或者在PermContext中设置withIgnoreCompanyScope，当权限范围为用户自定义时，也会忽略公司的过滤
• 默认情况下总是进行create_user的过滤，如果要去掉，可以在@ActionConnect中配置beAlwaysFilterCreateUserColumn 或在PermContext中设置withIgnoreCreateUserColumn
• 同时设置ignoreUserScopeTags和ignoreGroupScopeTags时，权限只过滤本公司

职位的规则

规则

• 职位不关注功能（后期可能会关注），只关注范围，默认情况下职位能够对范围内所有数据进行操作（后期可能会针对特定功能，比如只能看不能改和删）
• 职位与组织关联，即一个职位只能对应一个组织
• 只有该组织下的人员才能分配组织下对应的职位，并且只能分配一个职位
• 职位能与角色进行关联，例如”经理“职位拥有审批菜单
• 人员默认没有职位，没有职位是显示”职工“

权限范围

注意

职位自定义跨公司分配对应部门人员时，使得跨公司查看数据变得简洁，例如财务跨公司对账，拉对账单等，同时也存在权限分配不当的风险，分配时应谨慎处理！

职位的数据权限包含以下几种

• 部门全部 能看到该部门所有的数据
• 本人及下属 能看到本人的数据及部门下子部门的所有数据，与本人平级的人员数据看不到
• 本人 只能看到本人的数据
• 指定范围，自定义指定范围的数据，注意可以进行跨公司查看

授权码规则

提示

授权码是一种临时授权措施，可用于自己的业务分配给同事代做的情况，也可认为是共享数据的一种方式

人员可通过授权码进行登录，可在个人中心配置授权码密码（账号相同）及授权时间段（后期可能添加允许IP），有如下规则

• 只能通过指定的页面(/user/logintemp)进行登录（与正常登录不在同一个页面）
• 不能用原始密码进行登录
• 登录后只能看到create_user为自己的数据（分配的权限不会生效）
• 操作后创建人（create_user）和更新人(update_user)会添加一个*号来标注是授权码操作的
• 授权码登录只能由一用户登录，同一授权码登录会”顶掉“前一个授权码