功能介绍

基础功能

1. 运营人员登陆、注销。
2. 用户注册、登陆、注销。
3. 实时聊天功能。

用户中心（针对用户）

1. 消息：实时聊天功能，好友聊天、群组聊天
2. 通讯录：我的好友、新的好友、我的群组
3. 个人信息修改
4. 我的企业：注册公司、查询我的公司，切换默认登陆公司。
5. 修改密码
6. 切换角色、组织机构

运营后台管理（针对运营人员）

1. 租户管理：租户信息查询，应用、菜单权限开通锁定等。
2. 应用管理：运营、2B、2C应用管理，应用菜单设置，2B预制角色管理。
3. 管理员管理：运营管理人员管理。
4. 运营角色管理：运营角色管理，运营菜单绑定，管理员授权。
5. 用户管理：编辑、删除、重置密码。
6. 配置管理：租户默认开通应用及默认管理员角色设置。
7. 接口管理：微服务接口管理，服务启动自动生成接口数据。
8. 接口访问统计：统计各个接口的访问情况，按小时、按天统计。

系统权限管理（针对租户）

1. 组织机构管理：树状组织机构创建编辑。
2. 成员管理：租户成员查询、邀请、组织机构绑定等。
3. 角色管理：预制与自定义角色管理，角色菜单绑定、组织机构绑定、人员绑定。
4. 菜单管理：拥有菜单查询，后期支持租户自定义菜单。

重要功能介绍

1. 运营后台-租户管理

   租户属于2B业务，租户之间数据隔离，可以为不通的租户开通不同的2B应用及相关的菜单权限。

   TODO: 后期会添加针对租户开通应用及具体菜单的访问量统计功能；添加访问量阈值设定功能；访问量超过阈值，自动进行锁定功能。

   **注意：**新注册的租户默认开通系统权限管理的应用权限，但是没有开通改应用下菜单的权限，需要在租户管理-应用信息中单点进行开通。还可以在运营后台-配置管理界面，配置默认开通应用及预制角色。

2. 运营后台-应用管理

   应用分为 2B、2C和运营三种类型。

   2B针对租户，每个租户各自管理各自的成员，实现了对租户的数据隔离，可以设置预制角色及菜单资源信息。

   2C针对该平台用户，可以设置菜单资源。

   运营针对运营人员，可以设置菜单资源。

   菜单分为分类导航、菜单页面、查询按钮、操作类按钮四类，其中查询和操作类按钮会绑定接口信息，用以实现接口级别的权限控制。

   预制角色实现了页面及接口访问权限和七级数据权限控制。权限挂接在角色中，通过给组织和人员授权不通的角色，来实现不同的人员权限的控制。

   0:可以操作该租户的所有数据
   1:可以操作所属机构及下级机构所有数据
   2:可以操作所属机构及当前机构所有下级机构数据（感觉这级权限有点脱离需求，虽然实现了）
   3:可以操作所属机构的数据
   4:可以操作当前机构及下级所有机构数据
   5:仅能操作当前机构数据
   6:仅能操作用户自己的数据

3. 预制角色和自定义角色功能

   预制角色在运营后台-应用管理进行创建，自定义角色在租户权限管理后台-角色管理界面进行创建。

   预制角色的意义及定位：1）每个新建立的租户，其超级管理员必须有管理这个租户所有功能的权限，可以通过授予默认预制角色来快速进行授权，该配置可以在运营后台-配置管理页面进行配置。2）对应人员较少的租户来说，预制角色即可覆盖所有租户成员，方便租户快速掌握使用系统。

   自定义角色意义及定位：1）每个租户可以自定义专属于自己的角色，用于满足企业自身的个性化权限控制需求。2）对应人数较多的租户。

   角色分为组织角色和组织成员角色，组织角色给具体的组织机构进行授权，授权后的组织机构下的所有成员都有该角色的权限。组织成员角色需要先对组织机构进行授权，然后需要对该组织机构下的具体成员进行授权，只有该组织机构下的具体成员授权了这个角色，才会拥有这个角色的权限。

   组织角色是为了进行批量授权，不用每个成员都单点进行授权。

   组织成员角色是为管理人员设置的，例如组织机构的司长、局长、部长、组长之类的，他们的权限需要区别于普通的成员。

4. 运营后台-配置管理

   租户默认开通应用及租户管理员默认预制角色管理。

   TODO： 后期实现默认应用菜单的开通。

5. 运营后台-接口管理

   查看该平台所有的接口信息，以应用、controllerName、接口地址进行区分。

   TODO: 后期实现各个接口的访问量统计信息展示。

6. 运营后台-接口访问统计

   现实现：小时-接口访问统计、小时-租户即可访问统计、日-接口访问统计，日-租户访问统计，接口访问量top10，租户访问量top10。

   TODO： 后期实现IP访问量TOP10、应用内互相调用统计图及对外接口访问统计图。

   注： 有兴趣的小伙伴可以仔细看下这个页面的ajax请求信息，这六个统计功能全都是一个接口不同的参数实现的。

7. 用户和成员进行区分

   用户是平台的用户，成员是租户下的成员，一个用户可以属于多个租户，每个租户下都有各自的成员信息，进行区分的主要目的在于，将租户的成员变成了平台的用户，方便平台进行用户级别的业务需求。

8. 便携的基础集成包,只要是和upms一个注册中心，其他业务微服务引用如下jar包，会自动收集该微服务的所有接口信息及接口访问情况。

   <dependency>
       <groupId>com.nodecollege.cloud</groupId>
       <artifactId>upms-client</artifactId>
       <version>0.0.2</version>
   </dependency>

   在进一步，配置该微服务配置参数如下，并且在该微服务controller层添加@UserLoginAnnotation(checkDataPower = true)注解，会自动实现接口的访问控制，和数据权限校验。具体的可以参考pcgl这个项目。 application.yml

   upms:
     # 是否校验登陆 默认不校验
     loginCheck: true

   这样做的目的是为了分离业务，各个微服务做各个微服务自己的业务，其他微服务要使用接口权限校验时，直接引包和配参数就行了，不需要自己实现功能。
   当然数据级别的权限是需要根据具体业务具体处理的，我这只是提供了一个方便的方式，在调用某个具体的接口后，可以用如下的方式获取具体的数据权限数据和进行校验。

       @PostMapping("/getList")
       public NCResult<Pcgl> getList(@RequestBody QueryVO<Pcgl> queryVO) {
           ApiDataPower apiDataPower = ThreadUserUtils.getLoginUser().getApiDataPower();
           return pcglService.getList(queryVO);
       }

   @Data
   public class ApiDataPower {
       /**
        * 租户id
        */
       private Long tenantId;
       /**
        * 成员id
        */
       private Long memberId;
       /**
        * 能操作的组织机构列表
        * 为null，可以操作租户下所有组织机构数据
        * 为空, 只能操作当前登陆人的数据，memberId必填
        * 不为空，可以操作列表中组织机构的数据
        */
       private List<Long> orgList;
   }

9. 接口访问来源校验 访问来源分为两种

   • 通过nginx访问的方式，来源固定为nc-nginx
   • 通过feign的方式访问，来源为applicationName

   添加了@ApiAnnotation注解且checkSource 为 2 的接口会有以下的处理方式

   • 需要校验是否登陆

10. 前后端分离，使用了spring cloud （是不是勉强可以称做云服务了=͟͟͞͞(꒪⌓꒪*)）

11. 实时在线聊天功能

    好友聊天、群组聊天、好友添加、群组创建