说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

关于用户离职和升级后的处理?

编辑:说三道四文库 发布时间:2018-06-25 02:59
HTML文档下载 WORD文档下载 PDF文档下载
在原来开发的时候,用户填写意见什么的都是存的用户ID,现在就有这么一个问题:如果A用户离职后,那么如何反映该用户已经离职(是否是删除用户),如果删除的话那么那些意见A原来批示的文章意见怎么反映出来?如果B是一个新用户,在原系统中的信息B如何可以看到,要不该人员的信息全为空??
有没有好的解决方案,谢了!
采用用户与权限角色分开的处理方式;
只要某个用户有访问的权限或分配了这个角色,就可以看到;
将另一用户收回角色,就没有权限访问了。

另离职后的用户,不能删除,最好做离职标志。
有一个这样的问题,如文件1是给A一个人看的,可是A离职后B接替A工作,那么文件1B也应该可以看到?如何处理?谢了
我们可以这样做,为角色分配权限,而不是为针对某人权限。而针对个人,则应属于一定的角色,从角色中继承权限。A离职后,个人档案可除,但可分配另一个担当A的角色。为新用户B分配一个角色,即可根据角色权限查看信息。
也就是说权限只能对角色而不能对人了?
对!权限只能对角色而不能对个人。
把权限授与角色后,扮演此角色的人其权限可以copy该角色即可。
对于比较大一些的系统,一定要用“角色”;
离职,不要做真删除,应该作标记删除。
可以建个功能字典,记录所有的功能(功能号,功能名);然后为登陆用户分配权限,记录在另一个表中(功能名,用户);这样,当用户操作时,先检查是否有该功能权限,
用户属于某一特定角色,角色具有某些或全部权限
一般都这样处理
study
我们的系统采用了权限模板和具体权限的方法,系统的用户不允许用户删除(除非到数据库中删除),系统的用户有一个停用标志,如果选择的话,这个用户只是停用,不能删除!
如果都用角色不用用户的话那么用户多的时候是不是每一个人都有一个属于自己的角色?
如果不是那么比如我想将一篇资料只给单位局长看时怎么操作?或只给C用户看时怎么办?
使用用户的有效期来截止用户权限,又能保持历史纪录,一般不应删除用户。
如果都用角色不用用户的话那么用户多的时候是不是每一个人都有一个属于自己的角色?
如果不是那么比如我想将一篇资料只给单位局长看时怎么操作?或只给C用户看时怎么办?

=============
你的这种说法不对,用户和角色都要有,一个用户可以拥有一种或几种角色,A用户和B用户拥有的角色可能是相同的,那么这时,A和B的权限就是一致的.将一篇资料只给单位局长看时,那就创建一个可以看这个资料的角色,局长对应的用户有这个角色,他就有看这个资料的权限,以后如果其他用户也有这个权限,就只需分配角色就可以了,易于维护
那如果角色被停用了,是不是也最好做一个停用标志?那多角色用户被停用了一个角色之后,
对这个用户怎么处理呀?
hongchenzpm111(红尘) ( ) 信誉:100 
将一篇资料只给单位局长看时,那就创建一个可以看这个资料的角色,局长对应的用户有这个角色
===============
我就是考虑到如果信息很多共享的时候,如用户A、B、C,A将资料1给只给B看,A将资料2只给给C看;以此类推,那不是相当于每一个用户都至少有一个对应于自己的角色了?
如果还有其它相同权限时又有一个角色,这样的话角色是不很多吗?好维护吗?我想这样的话管理员工作量很大

up
授权,

用一个状态标志表示A已经离职,该账户失效,删除不好,无法备份。
B用户接替A,则把A用户的权限授给B。
这么简单的问题。
请问
当多个用户共用一个角色,而且要求每个用户只能关心自己的数据,
当有人离职后,该如何处理权限呢?
把角色分组管理
在这个组里面,组成员拥有的权限是一样的。
在数据的共享上面,细分到增加一个字段为operatorid,这样不同的用户就只能看到自己的数据。
当A离职的时候,如果要把A的数据让B共享,只要update这个字段为A的ID就可以,取数据的时候where opreratorid=B
这不是很简单的问题吗?
关于权限设计的探讨  

但凡涉及多用户不同权限的网络或者单机程序,都会有权限管理的问题,比较突出的是MIS系统。下面我要说的是MIS系统权限管理的数据库设计及实现,当然,这些思路也可以推广开来应用,比如说在BBS中用来管理不同级别的用户权限。权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。这三个部分相互依存,密不可分,要实现完善的权限管理体系,必须考虑到每一个环节可行性与复杂程度甚至执行效率。我们将权限分类,首先是针对数据存取的权限,通常有录入、浏览、修改、删除四种,其次是功能,它可以包括例如统计等所有非直接数据存取操作,另外,我们还可能对一些关键数据表某些字段的存取进行限制。除此,我想不出还有另外种类的权限类别。完善的权限设计应该具有充分的可扩展性,也就是说,系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化,要达到这个目的,首先是数据库设计合理,其次是应用程序接口规范。我们先讨论数据库设计。

权限表及相关内容大体可以用六个表来描述,如下: 
1 角色(即用户组)表:包括三个字段,ID,角色名,对该角色的描述; 
2 用户表:包括三个或以上字段,ID,用户名,对该用户的描述,其它(如地址、电话等信息); 
3 角色-用户对应表:该表记录用户与角色之间的对应关系,一个用户可以隶属于多个角色,一个角色组也可拥有多个用户。包括三个字段,ID,角色ID,用户ID; 
4 限制内容列表:该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述,包括三个字段,ID,名称,描述; 
5 权限列表:该表记录所有要加以控制的权限,如录入、修改、删除、执行等,也包括三个字段,ID,名称,描述; 
6 权限-角色-用户对应表:一般情况下,我们对角色/用户所拥有的权限做如下规定,角色拥有明令允许的权限,其它一律禁止,用户继承所属角色的全部权限,在此范围内的权限除明令禁止外全部允许,范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点,设计的思路也很多,可以说各有千秋,不能生搬硬套说某种方法好。对此,我的看法是就个人情况,找自己觉得合适能解决问题的用。 

先说第一种也是最容易理解的方法,设计五个字段:ID,限制内容ID,权限ID,角色/用户类型(布尔型字段,用来描述一条记录记录的是角色权限还是用户权限),角色/用户ID,权限类型(布尔型字段,用来描述一条记录表示允许还是禁止) 

好了,有这六个表,根据表六,我们就可以知道某个角色/用户到底拥有/禁止某种权限。 

或者说,这么设计已经足够了,我们完全实现了所需要的功能:可以对角色和用户分别进行权限定制,也具有相当的可扩展性,比如说增加了新功能,我们只需要添加一条或者几条记录就可以,同时应用程序接口也无须改动,具有相当的可行性。但是,在程序实现的过程中,我们发现,使用这种方法并不是十分科学,例如浏览某个用户所拥有的权限时,需要对数据库进行多次(甚至是递归)查询,极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道,Unix文件系统将对文件的操作权限分为三种:读、写和执行,分别用1、2、4三个代码标识,对用户同时具有读写权限的文件被记录为3,即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表,加入一个字段:标识码,例如,我们可以将录入权限标识为1,浏览权限标识为2,修改权限标识为4,删除权限标识为8,执行权限标识为16,这样,我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了,例如,假定某用户ID为1,库存表对应的限制内容ID为2,同时规定角色类型为0、用户类型为1,我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为:2,15,1,1。 

确实很简单,不是吗?甚至还有更过激的办法,将限制内容列表也加上一列,定义好标识码,这样,我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然,这样做的前提是限制内容数量比较小,不然,呵呵,2的n次方递增起来可是数量惊人,不容易解析的。 

从表面上看,上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的,但这样做有个弊端,我们所涉及的权限列表不是相互独立而是互相依赖的,比如说修改权限,其实是包含浏览权限的,例如,我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除(1+4+8=13),但事实上,该用户具有(1+2+4+8=15)的权限,也就是说,在这种方案中,13=15。于是当我们调用API询问某用户是否具有浏览权限时,就必须判断该用户是否具有对该数据表的修改权限,因此,如果不能在程序中固化权限之间的包含关系,就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。 

这个问题如何解决?我想到了另外一种设置标识码的方法,那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11,当遇到权限互相包含的时候,我们将它的标识码设定为两个(或多个)基本标志码的乘积,例如,可以将“修改”功能的标志码定为3*5=15,然后将所有的权限相乘,就得到了我们需要的最终权限标识值。这样,我们在询问用户是否具有某项权限的时候,只需要将最终的值分解成质因子,例如,我们可以定义一个用户具有录入+修改+删除库存表的权限为 2*15*7=2*3*5*7,即表示,该用户具有了对库存表录入+浏览+修改+删除权限。 

当然,对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂,否则,光是解析权限代码就要机器忽悠半宿:) 

我希望以上的分析是正确且有效的(事实上,我也用这些的方法在不止一套系统中实现),但无论如何,我觉得如此实现权限管理,只是考虑了数据库设计和应用程序接口两部分内容,对于实现,还是显得很费劲。因此,我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。  
先说第一种也是最容易理解的方法,设计五个字段:ID,限制内容ID,权限ID,角色/用户类型(布尔型字段,用来描述一条记录记录的是角色权限还是用户权限),角色/用户ID,权限类型(布尔型字段,用来描述一条记录表示允许还是禁止) 

好了,有这六个表,根据表六,我们就可以知道某个角色/用户到底拥有/禁止某种权限。 

或者说,这么设计已经足够了,我们完全实现了所需要的功能:可以对角色和用户分别进行权限定制,也具有相当的可扩展性,比如说增加了新功能,我们只需要添加一条或者几条记录就可以,同时应用程序接口也无须改动,具有相当的可行性。但是,在程序实现的过程中,我们发现,使用这种方法并不是十分科学,例如浏览某个用户所拥有的权限时,需要对数据库进行多次(甚至是递归)查询,极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道,Unix文件系统将对文件的操作权限分为三种:读、写和执行,分别用1、2、4三个代码标识,对用户同时具有读写权限的文件被记录为3,即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表,加入一个字段:标识码,例如,我们可以将录入权限标识为1,浏览权限标识为2,修改权限标识为4,删除权限标识为8,执行权限标识为16,这样,我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了,例如,假定某用户ID为1,库存表对应的限制内容ID为2,同时规定角色类型为0、用户类型为1,我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为:2,15,1,1。 

确实很简单,不是吗?甚至还有更过激的办法,将限制内容列表也加上一列,定义好标识码,这样,我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然,这样做的前提是限制内容数量比较小,不然,呵呵,2的n次方递增起来可是数量惊人,不容易解析的。 

从表面上看,上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的,但这样做有个弊端,我们所涉及的权限列表不是相互独立而是互相依赖的,比如说修改权限,其实是包含浏览权限的,例如,我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除(1+4+8=13),但事实上,该用户具有(1+2+4+8=15)的权限,也就是说,在这种方案中,13=15。于是当我们调用API询问某用户是否具有浏览权限时,就必须判断该用户是否具有对该数据表的修改权限,因此,如果不能在程序中固化权限之间的包含关系,就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。 

这个问题如何解决?我想到了另外一种设置标识码的方法,那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11,当遇到权限互相包含的时候,我们将它的标识码设定为两个(或多个)基本标志码的乘积,例如,可以将“修改”功能的标志码定为3*5=15,然后将所有的权限相乘,就得到了我们需要的最终权限标识值。这样,我们在询问用户是否具有某项权限的时候,只需要将最终的值分解成质因子,例如,我们可以定义一个用户具有录入+修改+删除库存表的权限为 2*15*7=2*3*5*7,即表示,该用户具有了对库存表录入+浏览+修改+删除权限。 

当然,对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂,否则,光是解析权限代码就要机器忽悠半宿:) 

我希望以上的分析是正确且有效的(事实上,我也用这些的方法在不止一套系统中实现),但无论如何,我觉得如此实现权限管理,只是考虑了数据库设计和应用程序接口两部分内容,对于实现,还是显得很费劲。因此,我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。  
其实核心思路就是:
1.用户资料不删除,这个是前提,毕竟在企业的发展过程中,一个好的系统是要和其他系统要留接口的,用户的资料将是“人力资源管理系统”、“财务系统”等系统的一个基本资料,当然这些有可能要从其他系统内继承,所以,一个好的系统,这个必须是前提。
2.既然有上面前提,那么,权限的分派和管理就显的非常重要,上面的说的已经很清楚。
我的思路就是,首先要考虑系统的接口,然后要根据这个接口来产生一个权限和角色的分配,那么这样的系统通过“状态定义--自己定义的”来使自己的系统更加的稳健。
角色,就是一个用户组,用于资料共享;
你所说的情况,其实,是限定于某一个人单独可以看到的资料;
一般用户管理是采取角色与用户共存,即在资料的权限设置里面同时有用户组和用户标记。

资料既可以由用户组内所有用户共享,也可以由某些特定的人共享
这个问题我也是第一次感觉到比较困难,以前从没有使用过角色这个设置,不过现在越来越感觉应该设置这个了.如果系统不大,又要使用这个,最好不要出现手工分配角色的维护,而用系统自己维护.
ayine(原振侠) 分析得不错,权限设计的问题也应该算是一门学问了。这个帖子我收藏了。

  学习学习。upup。
没想到大家讨论得这么热烈,请大家继续!!!
Mark.up.
备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘