概念 : 用户>角色>权限 的管理（Role-Based Access Control）

*primaryKey是email format， 电话号码，webchat。。。

*灰色是之前的需求，保留而已
自动登入，在employer page 登入后，会有cookies，去到candidate page时，会自动登入。过程是发现有cookies同时type 是customer。如果在candidate 登出时，employer 也会自动登出。因为在登出后，在refresh又会自动登入，死循环很奇怪！

半自动登入，在employer page 登入后，会有cookies，去到candidate page时，点击登入，在这里看当下页面的业务逻辑，
如果是只有一个角色可以登入的话，就直接帮他登入
如果是2个角色，就会有一个选项让他选择哪个角色，
如果是选择的角色在HdLogin有记入的话，会自动登入 （cookies是属于当下界面）
如果是选者的角色是不在HdLogin的话，会需要自己登入

手动登入，意思是每一个页面的业务逻辑都是只有支持自己页面的cookies。
当登入candidate page时，再去到employer page，会查找HdLogin，结果会发现没有记入，然后要求登入

account Type 会记入抽象或具体 user administrator，staff，manager...
举个例子：当manager登入admin page，之后再去到前台page，
如果前台page是“自动登入”或“半自动登入”，首先会去HdLogin去查找看看cookies有没有当下的页面
如果有记入，就broadcast
如果没有记入，就看记入中的account type是不是如何业务逻辑。现在account type是administrator，是可以登入的，在购买房间时，会确定角色是不是manager（因为业务只支持administrator 的 manager可以购买），然后完成！
但是如果是staff 呢？
举个例子：当staff登入admin page，之后在去前台page，
如果前台page是“自动登入”或“半自动登入”，首先回去HdLogin去查找看看cookies有没有当下的页面，
这时发现他的account type是administrator，是可以登入的，但是在购买房间时，资源会发现他不能访问，因为角色只有manager才可以购买

seek的概念，同个email，不同password
在结构上，user 是accounts的父层，但是在创建candidate email后再创建 employer email，是没有把这2个email在同个accounts！
完全是2个email。

roles的数据结构
举个例子：manager要操作supervisor的操作，这时必须roles.roleTaskss 添加一个supervisor。所有的manager就一定要有角色，不然会有bug！

roles ：[
            {
                type: "manager",
                roleTaskss : ",manager,supervisor,"
            },
            {
                type: "supervisor",
                roleTaskss : ",supervisor,"
            }
        ],

概念 : 用户>角色>权限 的管理（Role-Based Access Control）

标签：