您好、欢迎来到现金彩票网!
当前位置:9号彩票app下载 > 工作流 >

后台设计的基石:用户权限管理(RBAC)及工作流(workflow)模型

发布时间:2019-05-09 21:12 来源:未知 编辑:admin

  后台产品同学在设计后台时,会发现一般后台的各个功能模块总结起来有两大类型:功能类、流程类。在设计功能或流程前都需要预判不同的使用角色对应不同权限,设计流程前则还得思考最基本的工作流原理。

  用户权限是设计后台普适的基本管理功能,设计系统时几乎都需要考虑权限问题。后台系统在面对不同部门不同岗位的人员时,如何区分授权?在考虑前端不同身份的用户访问时(如普通用户、普通会员、超级会员),如何自动判断权限?工作流则是设计流程需要具备的基本理论,一个完整的流程会会包含哪些节点动作?节点是否可自主配置?

  RBAC(Role-Based Access Control)基于角色的访问控制。这是从传统的权限模型基础上,改进而来并且相当成熟的权限模型。这里强调三个要素:用户、角色、权限。用户与角色是多对多关系,角色与权限是多对多关系。

  传统模型中无角色概念,直接为用户赋上权限,一是导致配置权限相当麻烦,二来无法快速为多个用户批量删除权限。用户角色权限多对多的关系,解决了这些问题。

  权限是用来访问资源的,为用户赋予权限,则可访问资源;在权限基础上,将权限打包为一个权限集合角色,如财务经理角色,则为用户赋上财务经理角色,用户可访问财务经理角色下的资源集合。

  将一个或多个权限挂到角色下,在将一个或多个角色赋予用户,权限与角色的关系,角色与用户的关系,均是多对多的关系。

  场景。为财务经理岗建立财务经理角色,将对账、付款审批、回款确认等权限配置在财务经理角色下,则公司再更换财务经理人员,只需每次为新来的财务经理配置财务经理角色。

  为客户经理建立客户经理角色,客户管理、客户查询、抢单等权限配置在客户经理角色下,适应于公司流动性高且占比庞大(多的甚至上千人)的客户经理群体,若某个权限不适宜配置给客户经理,直接在角色中删除即可,无需分别对每个人进行权限删除。

  引入继承概念,一个角色可以从另一个角色继承许可权。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承,受限继承关系则进一步要求角色继承关系是一个树结构。

  场景。适用于角色之间的层次明确,如总经理与副总经理,业务部门如总经理团队经理业务员。也适用于用户分级管理,初级用户只能使用部分功能,中级用户能够使用更多功能。

  加入了角色的访问控制。规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

  同一用户只能分配到一组互斥角色集合中至多一个角色,支持责任分离的原则。案例:在审计活动中,一个角色不能同时被指派给会计角色和审计员角色。

  一个角色被分配的用户数量受限;一个用户可拥有的角色数目受限;一个角色的权限数目受限。案例:如VP类角色不可随意分配给多个用户。

  指要想获得较高的权限,要首先拥有低一级的权限。案例:先有副总经理全下,才能有总经理权限。

  RBAC1+RBAC2的集合体。即支持角色间的继承关系,又支持角色间的责任分离关系。一般无需如此全面负责的模型。

  可见功能菜单页、功能操作按钮、数据字段,均可通过颗粒度较细的权限,去组合成一般角色。

  指可查询的数据范围。同一个一般角色,如查看客户数据,大区总监能看到整个大区的数据,上海分公司经理只能看到上海客户数据。上级组织职能看到下级组织员工负责的数据,而不能看到其他平级组织及其下级组织的员工数据等。

  用户按架构新建在对应的组织上。一般挂到机构→部门(一级部门二级部门)下。

  对于公司内部管理系统,管理用户的前提,是需要合理的组织架构,只有支持组织架构的灵活配置,才能进一步支持组织内人员的增删调整。

  所有角色的管理功能。新建角色时,可将角色建立在某级机构或机构及以下,代表此角色只能适用此级别或此级别以下级别。

  支持自主配置菜单一级二级,支持新增菜单、修改菜单、删除菜单,更改菜单(修改菜单名、菜单顺序等),每个菜单对应一个权限。

  用户所属组,用于配置统一组同一部门用户。有了用户组,在新建角色时,可直接将角色赋予某个组,则进入此组的人员自动获得对应角色。

  一个业务流程包含多个环节的审批确认关系,按照业务流程,将各个节点串接起来,即时工作流。系统实现各个节点的自动流转,解决手工处理工作流程的低效和失误,提高工作效率的同时,还可通过线上直接流程状况进行实时跟踪,实现业务流程流转的自动化。

  案例:入职流程,人力专员提交——HRBP审批——人力总监审批,顺序走完流程。

  并行的多路分支集结到一个点的路由方式,前序分支节点全部都经过处理,最终才到汇合节点处理

  这种是很特殊的路由方式,在流程实际运行时跳出原来定义的线路,自由跳转到任意的步骤。

  每个节点提交后,下一节点将有谁审批?一般会为对应岗位的人员配置对应的节点。但若涉及到分公司或分地区审批,则需要设计上报关系。

  上报关系支持灵活配置前一岗与后一岗的对应关系。如北京分公司的审批,提交到财务审核时,只能提交到北京财务部。合作公司的审批,只能提交到综合财务部。此时就需要提前配置上报关系,北京分公司北京财务部;合作公司-综合财务部。各个部门均可配置对应上报关系,包括财务,人力,业务等。

  最后,为用户配置某个财务部的权限,则其仅可接收特定对应的上报关系的审批申请。如权限为综合财务部用户,仅可收到合作公司提交的申请单。

  如操作员入职流程完毕后,自动赋予其岗位对应角色权限,当然这可通过对用户组分配角色实现。当操作员调岗时,根据调岗的跨度大小,自主确定是否更改权限或删除权限。流程节点在系统中可根据对应业务,后台预备支撑性较强的节点变量,支持前台配置,由管理员自主根据对应业务流程,配置相应的流转节点。

  作者:柴小英,先后混迹于大数据及互金领域,负责过资金端理财平台及资产端信贷后台,现任银客集团资产端产品经理

  最近在做权限管理,觉得人和资源之间有对应关系,而且是多对多的。资源只是页面内的展示(操作)内容,完全没有必要把资源和权限建立对应关系。

  如果是平台化,多机构企业入驻,在权限控制方面可否使用单一平台进行控制。如果用单一平台控制,能大体说下思路嘛

  “先决条件角色 :指要想获得较高的权限,要首先拥有低一级的权限。案例:先有副总经理【全下】”,全下=权限吧

  这个可以作为用户权限设计的一个基础思想去理解,具体设计还要根据具体业务来,不断演变组合,以达到效果,师傅领进门,修行再个人。还是要赞一下作者的👍

  艺术来源于生活,我再强调一遍,艺术来源于生活,,,大家觉得对不对,,,,,

  赞!如果业务中某特殊用户的权限超出了某一角色配置的权限,而又不足以满足2个角色的权限,这个一般怎么去设计会比较好呢?

  把角色加个一个用户组,跟自己把权限配置给用户组不是更好,只需保留一个即可

  前提是用户组内的用户会共用一批权限集合,一般在基本的RBAC0模式下,可把基本的权限打包为一个角色,授权给用户组,再针对用户组中的高级人员或特殊人员做单独的角色授权

  感觉这些理论是故意在故弄玄虚,故意用一些貌似高深的词汇。。。。也没有把后台的权限管理清晰的表达出来。

  确定角色等级后,父角色自动继承子角色内的权限集合,一般改进版的还会圈定出公有权限范围可被上级继承,私有权限不可别上级继承

  这不是Beta版!Axure RP 9 正式版,来了(含安装包及汉化文件)

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

http://dralvaro.com/gongzuoliu/153.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有