Dolores企业通讯解决方案
Dolores
Dolores试图成为一套完整的企业通信解决方案，一个完整的企业沟通工具（以下简称企业IM）至少需要支持以下几个功能：IM消息服务、组织架构管理、工作流集成
IM消息服务
实时消息这一块有很多开源的解决方案比如XMPP，但是企业通信对IM这块的可靠性要求很高，所以目前我们打算使用比较成熟的云服务，后期如果时间比较充裕，考虑开发自己的IM服务器。在对比了市场上数十家IM云服务厂商以后，我们决定选择环信来为Dolores提供消息服务。
组织架构
企业通讯录可以说是企业沟通中最重的业务之一，能够提供员工各种服务的认证，获取员工的联系方式等等。
组织架构-Server
服务端主要包括以下功能：
支持管理人员（例如HR）对部门和员工进行增删改查
支持部门和员工自定义排序，自定义元信息存储
权限管理
员工通讯录视图 （员工根据自己的权限生成通讯录）
通讯录增量更新 （鉴于移动端特殊的网络环境和设备，通讯录应该支持差量更新）
集成 IM 用户系统
在这里我们主要讨论以下两个问题：
权限管理
随着企业逐渐的发展，团队壮大为了更有效的沟通，以及保护公司内部的一些商业信息不被泄漏，我们应该为通讯录添加权限管理。
基于Role-based access control（RBAC）的权限管理模型
为了介绍此权限管理模型，我们先解释一下基本概念
角色：通常是指企业中某一个工作岗位，这个岗位具有特定的权利和职责。被赋予此角色的员工，将获得这种权利与职责
权限：被赋予访问实体的权利。在本项目中是指访问部门和访问某一个或者某一类员工的权利
用户-角色分配(User-Role Assignment URA)：为某个用户指定一个或者多个角色，此员工将获得这些角色所具有权利的集合
角色-权限分配(Role-Permission Assignment RPA)：将权限分配给角色，一个角色可以包含多个权利。在本项目中是指多个访问部门和访问员工的权限
在用户和权限之间引入角色中介，将用户与权限的直接关系弱化为间接关系。
|ˉˉˉˉˉˉ| |ˉˉˉˉˉˉˉ| |ˉˉˉˉˉˉˉˉˉˉˉˉˉ| | User |---URA---> | Role |<---RPA---| Permission | |______| |_______| |_____________|
以角色为中介，首先创建访问每个部门和员工的访问权限，然后创建不同的角色，根据这些角色的职责不同分配不同的权限，建立角色-权限的关系以后，不同的角色将会有不同的权限。根据员工不同的岗位，将对应的角色分配给他们，建立用户-角色关系，这就是RBAC的主要思想。
一个员工可以用户多个角色，一个角色可以用于多个访问权限。RBAC 极大的简化了员工的授权管理。
由于企业的部门和员工数量很多，在创建权限时管理员不可能去设置每一个权限可以访问的每一个部门和每一个员工。所以本项目将功能和指责类似的部门和员工看作是同一类型，在创建部门和员工的时候为每一个部门和员工分配固有属性type，管理员在设置权限规则的时候只需要指定可访问的部门类型和员工即可。
增量更新
鉴于移动终端计算资源有限，如网络，存储，电量等，所以通讯录的更新技术应该保证尽量少的资源。另外由于通讯录的特殊性，通讯录的变化需要能实时通知到受影响的在线员工。
基于版本号与变更日志的增量更新模型
客户端第一次登陆系统以后，我们根据当前登录角色生成对应的通讯录视图，并以当前时间戳作为版本号，返回给客户端。客户端后续通过此版本号增量更新通讯录。
版本号
版本号有两种：一是客户端当前通讯录版本 c-version, 二是服务端通讯录每一次变化时的版本号s-version
变更日志
在管理员修改权限规则，或者修改某个岗位的访问规则时会影响大面积员工的通讯录视图，此时如果用增量更新会导致服务器流量异常，因此在这2中情况会清空原来的变更日志并且要求客户端进行一次全量更新。
如果管理员新增了员工，服务端会根据被修改的员工或者部门type， 反推出所有受影响的员工，然后生成一条变更日志， 例如：
{
"content" : [
{
"cn" : "Lucy.Liu",
"id" : "b4vlfg91scgi1dcju8v0",
"title" : "市场运营负责人",
"email" : [
"lucy.liu@dolores.store"
],
"priority" : "101111",
"name" : "刘小飞",
"telephoneNumber" : "18888888888"
}
],
"createTimestamp" : "20170614063303Z",
"category" : "member",
"action" : "add"
}
客户端在请求增量更新的时候，通过当前登陆ID与版本号，可查找出所有与自己相关的变更日志，然后在客户端数据库中应用这些变更，即可完成同步。
组织架构-Client
由于现在员工办公设备的多样性，客户端要根据自己公司的情况，覆盖的足够完整，常见的平台有 iOS Android windowsmac linux , 对于后三个平台可以用 Web APP 来覆盖，iOS&Android 用原生的app来提升用户体验。
客户端App主要包括以下功能：
会话列表
优秀的聊天界面，历史记录
组织机构全量／增量更新
员工个人资料展示
客户端数据库设计
IM数据库设计
当前版本使用环信SDK，暂不讨论（TODO）
组织架构数据库设计
表设计
客户端组织架构较服务端简单，不关联用户Role，客户端本地存储Staff（员工）和Department（部门）信息：
一个部门可以包含相关子部门和部门员工。该部门员工和部门在视图上处于同级关系。
员工隶属于部门，同一员工可以存在于多个部门。
员工角色用title来表示。
用户在登录客户端成功后，会根据该用户信息创建用户对应的数据库文件，用户表（User）保存用户相关信息，关联该用户staff信息。
客户端组织架构同服务端逻辑。
工作流集成
（TODO）
如何使用Dolores
本项目现在已经完成了第一个测试版本，本小节将指导您如何安装使用。
后端数据库
鉴于通讯录对数据库操作的特点多度少写，以及部门之间的树状关系，我们选择LDAP协议来存取数据。
我们有独立的repo来帮助您完成数据库的安装与初始化。请移步这里
组织架构管理
Dolores 初始版本使用Golang实现，大家既可以下载各个平台的可执行包，也可以安装Go语言的开发环境自己编译。
我们有独立的repo来帮助您，运行后端服务。请移步这里
客户端
我们现在有提供一个iOS版的Demo。请移步这里
Done
如果您顺利的完成以上三步，访问 http://localhost:3280 (端口号根据自己的配置，可能会有差异)，使用 username: admin, password: dolores 登陆后端管理页面，添加权限规则，添加角色，添加员工、部门，然后使用iOS客户端登陆，就可以愉快的开始聊天啦～
对每个repo做一个简单的介绍
Dolores: 项目简介, 整个项目的架构, 数据库设计等等 你想了解的一切都可以在这里看到
dolores-ios: iOS版demo，可以聊天查看组织架构
dolores-android: 哈哈 还没有，当然我们欢迎各路安卓大牛贡献安卓版demo
organization: 组织架构的创建管理、更新、审计等等核心的东西都在这里啦
dolores-server: 为客户端提供restfull api 与环信服务器集成
dolores-admin: 后台管理网站，用于管理部门员工。一个基于React的webapp还很基础，欢迎各位大牛pr.
dolores-ldap-init: 后台数据库的初始化工具，详情可以查看readme
easemob-resty：对环信rest api的封装，让调用环信api更简单
dolores-avatar：生成类似钉钉那样的默认头像