前言
组织代表公司的基本架构，也是用户实施业务操作的基本要求，只有加入组织的用户才能参与具体的业务（分配权限、设置角色及业务系统操作等）。组织也是数据权限的委托维度（委托是数据权限的一个概念）。上一章我们讨论了 权限系统设计-用户设计，本章我们详细讨论组织设计。
组织设计
做如下约定：我们把组织类比为一个集团，下属很多分公司，每个分公司再分为很多部门。创建的最高层次组织为分公司（分公司只是定义，可以认为是其他名字，比如总部，此处为了方便类比）
与用户设计类似，我们从属性和功能、关联关系三个维度来具体考虑：
- 组织属性 组织名称 等级 父节点等等
- 组织功能 增删改查 加入用户、移除用户、查询用户等等
- 关联关系 关联用户，组织中可以有多个用户（例如部门中很多员工）；关联职位，组织中有多个职位（例如部门经理、技术经理等）
属性和功能
从属性和功能两个维度，经过梳理后，形成以下花型图：
通过花型图，我们总结如下：
- 属性中绿色部分为组织业务逻辑所必须，其中ID、名称、是否删除为业务所必需，父节点、节点级别、左节点值、右节点值、为结构所必需，红色部分为审计属性。
- 功能中橙色部分为组织自身管理相关的功能，蓝色部分为其关联用户关系的功能，黄色部分为其关联用户职位的功能，组织关联关系包括用户和职位。
关联关系
组织和用户的关系为N：N，即一个用户可以位于多个组织（具体查看用户设计章节），一个组织包含多个用户。组织和职位的关系为1：N，即一个组织有多个职位，一个职位只能位于一个组织。 对应关系图（用户章节讨论过）：
从图中可以看出用户与组织是不可分割的一个整体，只有用户加入了组织才能参与职位、用户组、角色及其他业务的关联，这对于权限系统设计很重要。
职位是数据权限的一个重要维度，为保证数据权限设计的简洁性，约定一个用户在一个组织中只允许一个职位，具体在后续职位章节详细说明。
组织属性
业务属性
组织是一个树形结构，拥有树形结构所支持的属性：父节点、节点级别、左节点值、右节点值，同时对应的业务结构为ID、名称、是否删除，详情如下：
- ID 主键唯一值，作为审计字段存在于其他表中，主要表示创建人所对应的组织，手动生成，对应一定的生成规则
- 名称 组织的名称，例如某分公司，某部门等，同一父组织下不允许重复
- 父节点ID 对应的父组织的ID
- 节点级别 约定公司为一级，随层级依次往下加一，例如青岛分司为1，其下属财务部为2
- 左节点值 该组织对应的左节点值，用来进行并集计算时使用
- 右节点值 该组织对应的右节点值，用来进行并集计算时使用
- 是否删除 用于逻辑删除标识。删除组织是一个很危险的行为，物理删除会导致部分数据权限失效，尤其是业务数据，因此暂设计为逻辑删除策略
某些业务表中的用户关联无法添加人员对应的组织，例如订单中有销售人员、库管人员、客服人员等相关人员很多，如果为每个人员都添加上对应组织会很冗余，此时对应的数据可以设计为 组织ID#人员账号 的方式，在数据权限过滤中会自动根据#（具体符号可自定义只是用来分割组织和用户）来进行拆分，通过用户委托和组织委托分别过滤。
审计属性
审计属性用来记录数据是谁创建的、何时创建的、创建人的组织、谁更新的、何时更新的。审计属性详情如下：
- 创建人 当前数据的创建人，存储的是用户的登录账号
- 创建时间 一般与业务无关，数据库自动填充（为防止被干预，应该设计为自动填充）
- 更新人 更新数据的人员账号
- 更新时间 与业务无关，数据库自动填充
- 创建人中文名 创建人的姓名（对于海外系统为创建人的英文名）
- 更新人中文名 更新人的姓名
- 创建人组织 创建人对应的组织ID
审计属性对于数据权限有着重要的意义，默认的数据查询（不设置任何数据权限情况下）条件为创建用户为当前登录用户，如果要查某组织下的所有数据，只需要通过委托组织ID，ID左匹配（与ID设计思想有关）
组织设计思想
青岛分司下会有很多的部门，如果要看青岛分司下的所有数据，如何查看？ 很简单：利用组织ID
组织ID是一个重要的设计点，是数据权限中组织委托的依据。通过一张图了解下：
通过组织树形图总结如下：
- 约定根节点为R（类比集团），系统不可见（逻辑不可见）
- 所有节点的ID都包含父节点的ID，例如根节点为R，青岛分司为R01，青岛分司下的销售部为R0101，查询青岛分司的数据只需要条件 like R01%
- 青岛分司的左节点为2 右键点为13，所有大于2小于13的组织都为青岛分司的子节点。组织委托销售一部，销售二部，求左右节点的并集4到7即（3,8）区间，只需要委托组织销售部ID R0101即可
- 根节点R节点级别为0,往下青岛分司、上海分司、北京总部节点级别为1，以此类推，这样查找分司主要查找节点级别为1的数据
此处每个组织ID都用两位数字来表示（对于公司和部门而言已足够，如有特殊需求可添加字母或者扩展位数）。
组织插入时时需要将右边的数据批量更新左右节点，因此需要一定的锁机制，在此不详细讨论。
组织功能
组织的功能除了自身的管理功能外还有维护关联关系的功能，我们分开进行讨论。
组织管理功能
组织的功能可以在Snapper权限系统中查看，账号密码（ximen/123456）
从花型图上分析，组织管理功能如下：
- 新增分公司 增加一个分公司，根据前面的约定，分公司为新增最高层次的组织，其他新增都是增加子节点，因此作为一个单独的功能。
- 新增子部门 增加一个子部门，可以在每个公司增加子部门
- 修改 修改组织信息包括分公司和子部门，只能修改名称
- 删除 删除分公司或子部门，此操作有一定的风险，为防止出现问题，约定：只有其下没有用户才可以删除
- 查询部门 通过名称关键字查询（树形结构查询）
- 查询明细 查询部门的明细
原则上组织可以添加无限层级，建议设计5层以内，层级过深需要注意ID的长度，避免过长导致出错。
用户关联功能
此处的用户关联功能与前面用户章节功能有重叠的部分，具体查看权限系统设计-用户设计
- 添加成员 对当前组织中添加新成员，只能添加已加入组织的成员（位于别的组织的成员），用于满足一个用户位于多个组织的功能
- 删除成员 将人员从该组织中删除
- 移动成员 将一个成员从该组织移动到另一个组织
- 加入成员 针对无组织的成员加入到该组织，注意与添加成员的区别
- 激活 激活组织中的用户，与用户功能中的激活功能相同
- 停用 停用该用户，与用户功能中的停用功能相同
- 启用 启用该用户（取消停用），与用户功能中的启用功能相同
- 查询用户 根据条件查询用户，条件中可关联组织，也可不关联组织
由于用户和组织在与角色关联时是不可分割的，所以移动成员时会导致关联关系失效，为避免角色关系失效（移动大多与资源权限无关，与数据权限相关），移动功能会更新用户组织与角色的关联关系
职位关联功能
- 设置职位 设置该用户位于该组织的职位，用户在该组织内只能设置一个职位
职位创建后（具体在后续职位章节中详细讨论），可以给组织内的用户设置职位（职位也位于此组织），如果职位设置了数据权限，该用户默认拥有职位的数据权限，如果职位设置了角色，该用户将自动拥有职位对应的角色（拥有角色的资源权限）。这样能做到换人不换岗，例如部门经理职位，拥有部门下所有数据权限（职位权限范围在后续职位章节中讨论），拥有审批权限（资源权限），张三离职后，李四上任，直接对李四设置部门经理职位即可。
总结
前面我们讨论了组织的设计包括功能设计和属性设计，再次强调用户只有加入组织才能参与业务，参与业务时必须明确组织（如果有多个组织），下一章将开始职位的设计。
