PDM设计审批流动态权限认证过程实现.docVIP

　　PDM设计审批流动态权限认证过程实现|第1 内容加载中... NM-PDM审批流管理就是根据工程图对象生命周期的状态来进行的。 2、NM-PDM审批流管理模型功能分析 在传统的手工管理工作流程中，对工程图生命周期各状态相应功能的执行是通过图纸的传递来进行的。而在NM-PDM审批流管理系统中，对工程图生命周期的状态的确立，是根据识别提供给操权限状态代码来实现对工程图的处理。全部过程在PDM控制下进行。NM-PDM审批流系统的管理模型如图2所示。 当一个用户准备进行工程图设计时，首先要登录系统，系统进行登录身份确认；当用户登录后，系统自动寻找其所属用户工作组，判别其是否可以使用设计用户界面；进入设计用户界面后，用户选择一个项目，系统会对其进行项目组成员身份认证，此时系统主要从两方面来对用户权限进行认证，一方面，判别用户是否为该项目组成员，另一方面，如果是,他在该项目组中所担任的角色是什么；用户选择项目子项后，系统要对该子项的所有权进行识别。 这部分工作是通过建立员工表存储用户登录身份认证数据、建立工作组表存储不同用户的不同权限认证数据和建立项目组表存储用户在不同项目中所担任的不同角色认证数据来进行。用户操作时通过读取这些信息来动态地约束用户操作。 3、权限认证过程设计 权限认证过程设计，主要研究系统在运行时工程图权限状态的动态变化过程。工程图的使用权限在其被调用过程中是动态变化的，其主要体现为用户权限的动态变化。一个具有审核权限的用户，他可以通过设计角色进入设计用户界面来进行设计工作，此时，对该张工程图来说，他的最高使用权限仅为设计，但这并不能剥夺其对该机型其它工程图的审核权限，当其进入审核用户界面后，他仍然可以浏览该图。一份未经校对的工程图对同一工作组中其他具有校对权限的用户来说，他们的使用权是相同的，一旦某一用户打开它并开始校对时，其它具有 校对权限的用户就只有浏览权了，但该工程图校对未通过并退回给设计者，在重新提交校对时，他们的使用权又是相同的了。因此，必须对工程图动态加载使用权限信息，并将用户权限传递到设计图。根据NM-PDM审批流所要进行的相关权限认证程序确立的系统权限审批流程图如图3。 用户权限代码传递的总体方案是：用户登录，读取权限代码，进入系统，系统根据用户所在工作组决定其对某项菜单的使用权限。一旦用户进入某一操作模块，例如，用户进入设计操作界面，选定某一机型，如果用户不是该项目组成员，则该用户只有浏览权限且不能对该项目的任何数据进行修改；如果该用户是该项目的成员，则其选取某一图纸目录选项时，系统会判断该图纸是否为该设计员设计，是否且未提交审核，就可打开其修改，否则其只有浏览权。 3、工作组权限代码的分配及其作用 工作组代码由单位汉语拼音前三位和顺序号组成，当然这种编号仅仅是为了便于将相同工作部门的工作组放于一处，系统并非根据用户组代码来分配其权限，而是根据“QX”字段来分配权限。 权限代码由1-9 、A-Z字母组成，每字段一位，不重复用户权限代码，就是为了可使以上字母叠加。如系统管理员权限代码为“1”，摩托车科设计组权限代码为“8”，那么，如果要求这两个工作组都可操作某一菜单，则这两位权限代码都必添加到权限包含的变量中。在应用程序中，定义了一个全局变量“gs_role_have”，当户进入系统后，系统会将权限代码读入到“ user_role”中，并一直保持不变，直到用户退出系统。在应用程序中，每一个需要控制用户权限的地方，都有一个判断语名来过滤用户的操作行为。如要求系统管理员、打印工作组、更改工作组可操作信息添加菜单项，则用如下语句： gs_role_have =1+5+6 //具体代码含义见图4 IF POS(gs_role_have, user_role)=0 THEN MESSAGEBOX(注意,你没有进行信息添加的权限！) RETURN ELSE OPEN(-PDM的实际情况，我们总共确立了十四个用户组， 用户组及其描述见图4。 项目工作组表由员工代码、项目关键字作为主关键字，即一个项目中可以有多个不同的成员，一个员工可属于多个不同的项目组。但是，一个用户在一个项目组中只能是以某种指定的角色出现，用户在某一项目中的角色决定了其打开某一项目中文件的具体权限。如一用户在该项目中担任设计员，则其在该项目中就不能担任校审员的角色。 项目工作组表是以代表角色的角色代码来决定用户对该项目文件的操作权限的。也就是说，用户一旦获得选取某一项目的权限，对该项目文件的操作权限就交由工作组表中所规定的项目角色所控制。 4.2 权限代码的传递及系统对权限代码的识别 下面通过一个实例来说明这一传递过程。 员工代码：