ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 【自然框架】之通用权限(三):组织结构表组

【自然框架】之通用权限(三):组织结构表组

原创 Linux操作系统 作者:iDotNetSpace 时间:2009-07-28 11:17:35 0 删除 编辑
     继续,这是第三章了。拖得有点长,但是我也是一边写,一边在想办法,想怎么做才能让资源权限也能通用起来。看大家的回复也给了我一些提示,我也在修改我的方案。原来打算用来解决一个人虽然在业务一部,但是却可以看业务一部、业务二部的客户信息的情况,但是仔细想了一下,这么做也不行。不过还好,我又找到了另一个方法来解决,而且可以让资源权限更加通用。不过这个详细的方法要放在下一章的角色表组里面来说明了。(这是写这篇之前的想法,写完之后想法又变了。)


组织机构表组


      这个简单一些,目前只有两个表。
      Dept_Department,这个是n级分类的设置,对以小公司来说,可以放业务部、客户服等部门;对于集团来说可以先放分公司(比如子公司1、子公司2),然后再在下一级里面放业务部、客户服等。而对于更大的集团的话,可以先放置“西北区”、“华北区”、“华东区”这样的大区,然后再在下一级放分公司,再在下下一级放业务部、客户服。就是说一个公司不管如何去划分“部门”,总之都往这个表里面放。

 

字段名中文名 字段类型字段大小 默认值是否为空 说明
DepartmentID组织机构int410主键
机构名称机构名称nvarchar50_0可以是部门,也可以是分公司、地区
机构简称机构简称nvarchar50_0机构简称
结构描述结构描述nvarchar50_0结构描述
机构类型机构类型nvarchar50_0机构类型
办公室电话办公室电话nvarchar50_0办公室电话
传真传真nvarchar50_0传真
邮编邮编varchar6_0邮编
地址地址nvarchar50_0地址
备注备注nvarchar50_0备注
子机构数量子机构数量int400不包括子子机构
本机构员工数本机构员工数int400本机构(不包括子机构)的员工数
本机构全部员工数本机构全部员工数int400本机构和子机、子子机构的员工数量
ParentID父节点IDint410父节点ID
ParentIDPath父节点ID的路径nvarchar300,0父节点ID的路径
DeptLevel机构层数int410第几级的机构
Sort序号int410总排序

 

      Dept_Department_Person,表示一个机构里面有哪些人员,机构和人员是多对多的关系。

 

字段名中文名 字段类型字段大小 默认值是否为空 说明
DeptPersonID序号int410主键
DepartmentID组织机构int410外键
PersonID人员IDint410外键

 


 

 

      问:为什么要在权限里面加上组织机构?他和权限有什么关系呢?
      答:准确的说,组织机构和操作权限基本上没有什么关系,但是却和资源权限有很大的关系。

      我想用我以前做过的一个CMS项目来说明,我先简要介绍一下客户的情况。出于商业秘密原因,我说的会比较“模糊”,但是并不会影响说明组织机构和资源权限的关系。


      客户是一个集团公司,集团里面有四个销售子公司,和一个售后服务公司。销售子公司都是独立运营,各卖各的产品;售后服务公司内部分为四个服务部,分别对应四个销售公司。(如下图) 

 

      Dept_Department 里的信息如下:
 

 

 部门里的人员信息:

 

      就是说一个客户购买了销售一公司的产品后,服务一部就要对这个客户进行售后服务。这样就出现了,销售一公司填写客户信息的时候,很自然的这个客户就成为了销售一公司的客户(客户的部门ID记录的是销售一公司的部门ID“3”)。然后服务一部的员工要对销售一公司的客户进行售后服务,那服务一部的员工就要可以看到销售一公司的客户(不能看到其他销售公司的客户信息)。
      

      这就出现了一个问题,客户信息里面并没有服务一部的部门ID,那我们怎么区分呢?把服务一部的员工都放在销售一公司吗?这不就乱了吗?我当时是做了一个部门ID的对应关系,虽然可以解决,但是很显然不够通用。

      这还没完,服务部又出来了一个问题,服务一部的经理可以看到服务一部的客户外,还可以看到服务二部的客户信息,而服务三部和服务四部的经理都只能看到自己的服务部的客户信息。这个倒是好办,可以把服务一部的经理放在服务一部和服务二部里面。

      最后还有一个普遍的问题,那就是销售一公司的业务员只能看到自己添加的客户信息,销售公司的经理只能看到销售一公司的客户信息。

 

      三个问题,虽然可以用许多的方式方法来解决,但是如何来统一呢,如何不用写死在代码里面呢?

      问题的根本原因就在于一个人所在的部门,与可以看到的部门不一致!虽然对于第二个问题可以采用强制一致的方法,但是对于第一个问题就不行了。

 

      我前几天的想法是这样的,在Person_User_Info表里面添加一个DepartmentIDs字段,这个字段来记录人员可以查看的部门ID,比如服务一部的售后服务工程师的DepartmentIDs 字段的内容就是:“3,8”。这样我们就是用了两个“地方”来存放人员和部门的对应关系。

 

      但是仔细想一想,这个方法也不够完美,还是有一个问题和一个隐患。
      问题:我需要知道访问页面的人是业务员、服务工程师还是经理。如果不能确认的话,就无法进行资源的过滤。
      隐患:如果发生了冲突了怎么办。比如,假设服务工程师可以看到业务员修改客户信息的页面,那么服务工程师不就会因为DepartmentIDs的原因而可以修改客户信息了吗?虽然我可以不给服务工程司分配业务员的修改客户信息的页面的权限,但是我总觉得,其他的地方有可能会出现冲突的情况。

      所以我就想放弃这个想法,改用角色资源的方式,这个在下一章的角色里面在说明。

      在写这一篇之前还是想放弃这个方案的,但是一边写一边想,最后还是保留这个方法吧,只要能够和角色,资源角色配合好,这个方法还是可行的。

原文地址:http://jyk.cnblogs.com/jyk/archive/2009/06/07/1498201.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12639172/viewspace-610612/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-01-04

  • 博文量
    2376
  • 访问量
    5297101