用户管理组织架构管理新增岗位/虚拟组织

[pagezz-canway]

功能需求背景，例如你遇到了什么问题

客户管理用户时，除了按照管理属性进行组织架构划分外，一般还需要根据人员职责确定不同的岗位。如DBA、运维经理等。但是这些人可能属于不同的实体组织（如数据中心、运维中心等），所以需要有虚拟组织管理这些用户分组，并且默认通过API拉取用户列表和架构不返回。

描述你觉得更好的解决方案

岗位/虚拟组织管理

• 用户管理中新增虚拟组织的功能
• 虚拟组织在根目录下创建
• 虚拟组织下的所有子目录都是虚拟组织
• 虚拟组织默认不传给API（list_departments、list_users等），可以通过加一个新参数或新接口获取
• 虚拟组织下不能添加用户，只能从其他实体组织拉取

岗位属性

• 虚拟组织可以自定义属性，如组名、组长

额外信息

客户场景案例：
在用户管理SaaS平台，虚设组织，用来管理所有的岗位信息，其他SaaS通过接口调用的方式获取相应的岗位信息进行消费。

岗位信息只会作为以上业务场景消费，不会在常规的组织、人员选择的地方出现。

[Shutulee]

岗位/虚拟组织更多的相当于一个类型标签/属性字段，并基于标签字段重新组织用户的展示结构，即类似于数据库中提供相应的逻辑视图。（和字段可能不一样的地方在于，虚拟组织可能会有一/二/三级结构，相当于新的组织字段）
——————————————————————————————————
需要考虑：
用户实际上使用岗位/虚拟组织满足了什么业务需求。（需要调研具体的使用场景，目前信息还不够）

前端SaaS：
基于不同的岗位信息展示新的用户拓扑。
……

API调用：
周边SaaS使用API调用岗位/虚拟组织的信息。目前来看这类需求偏多。
例如ListJobGoup()这种方法。但需要考虑，这个需求是否可以通过通用的查询类API就能解决。类似阿里云ECS的DescribeInstances方法，以携带的请求参数作为过滤器，过滤出用户期望看到的数据或视图。是否也能达到跟岗位/虚拟组织功能类似的效果？需要评估一下现在的API结构。