浅谈Oracle Agile PLM系统的权限管理

作者：

欢迎访问e展厅 展厅 3 PDM/PLM/CAPP展厅 图文档管理系统, CAPP... Agile PLM系统在实施时可以实现零代码上线，即所有客户需求可以通过系统配置来实现其功能。在所有的系统配置功能中，Agile PLM系统在权限配置方面显得最为灵活。同时也造就了它的晦涩难懂。以至于很多实施人员对他们的客户说，如果你清楚了Oracle Agile PLM系统的权限配置，你就完全掌握了Agile PLM系统。这句话虽然有些偏颇，但也不失为Agile PLM系统在权限配置方面"晦涩难懂"的有力证据。 下面的文字试图从本人的经验中来探讨一下Agile PLM系统在权限管理方面的一些思想。 Agile PLM系统从8.0版本以来就没有太大的变动，一直遵行着同一套设计思路。 要讨论Agile PLM系统的权限（Privilege），不得不从Agile PLM系统的"角色（Role）"说起。角色放到社会这个大环境中主要指个人在特定的社会环境中相应的社会身份和社会地位，并按照一定的社会期望，运用一定权力来履行相应社会职责的行为。而放到Agile PLM系统中，则可以理解为既有相同身份与职能，并安装系统给定的权限，来履行相应职责的用户集合。在Agile PLM系统中，系统每个用户属于一个或多个特定的角色。系统的各种权限并不赋予具体某个用户，而是赋予某种角色。由角色来承载相应的权限。举个例子，有一个角色叫R&D工程师，在进行权限设定时，我们不必考虑公司到底有几个R&D工程师用户。我只需要R&D工程师角色来承载权限就够了，将所有R&D工程师用户能够拥有的权限赋予R&D工程师角色。任何一个R&D工程师用户需要在系统中行使系统赋予的权利和义务时，只需将该R&D工程师用户设定为R&D工程师角色即可。这样简化了权限设定。 角色与用户之间的关系为多对多的关系，一个角色可以拥有多个用户，同时一个用户也可以属于多种角色。很显然，女王同时也是别人的妻子。 同时，角色与权限也是多对多的关系。一个R&D工程师不但设计产品，同时也申请物料。 那么，权限的行使靠什么来节制呢，是否在任何条件下都可以行使赋予的权限呢？答案当然是否定的，总统的权利甚至可以被两院架空。在Agile PLM系统中。权限的行使范围和时机通过"条件（Criteria）"来限制。在分析"条件"之前，我们来看看下面这个权限定义的例子： 当物料发行流程在采购签核阶段时，采购工程师可以修改元器件类型的物料的单价。 从这个权限中我们可以看出以下几点： 1.权限类型：修改 2.权限行使范围：修改物料单价 3.权限行使时机：物料修改流程在采购签核阶段 4.权限行使的对象：元器件物料 5.权限行使者：采购工程师 在这几点中，第1点属于权限本身的类型，第5点属于角色。其他2、3、4三点都是权限行使的条件了。在这个条件中规定了权限行使范围、权限行使时机和权限行使的对象。这些限制就是通过"条件（Criteria）"来达到目的的。 所以，一个完整的条件必须包含范围、时机和对象三项内容。者也正是Agile PLM系统中条件设定所具备的资格。范围指明了权限的作用域；时机指明了权限的行使时间点；对象指明权限行使的对象。整个用户、角色、权限、条件和对象的关系可以通过下图来表达。 Agile PLM系统中，权限可以作用于各种数据对象，这些对象包括：Items、Change等，也包括Folder、Attachment等；还可以包括Workflow甚至Processing Extension。权限类型非常丰富多样，包括Read、Create、Modify、Discovery；Get、Checkin、Checkout、Printer；Approve/Reject、Observe/Comment等多达45种。这些权限不仅仅是为了满足管理系统数据的需求，更是为了满足客户对系统权限的需求。 在Agile PLM系统中，每个权限都必须设定一个相应的行使条件。正因为权限收到限制，系统各种资料才能在正确的时机被赋予正确的动作。比起硬代码或者简单的勾选方式实现对系统数据权限控制的机制，Agile PLM系统权限管理方式可谓有着无可比拟的优势。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (5/28/2009)