The design scheme of authority management in OA system

It programmer development Essentials-all kinds of resources download list, history of the most IT resources, personal collection summary.
Due to the large-scale development of the company, the OA system should be required to keep up with the pace of development, I decided to redo the system again.

Now do the pre-system analysis, currently encountered a difficulty: the Authority design scheme.

In Baidu soon found a solution, the following information reproduced from the network:

People with different responsibilities should have different permissions for the system operation. Excellent business system, this is the most basic function.

L can assign permissions to groups. For a business system of a large enterprise, it is a time-consuming and inconvenient thing to ask the administrator to assign the system operation permission to the employee. Therefore, the concept of "group" is put forward in the system, the people with the same permissions are programmed into the same group, and then the rights are assigned to the group.

L The Rights management system should be extensible. It should be able to participate in any system with rights management capabilities. Just as components can be reused, not every development of a management system, it is necessary to re-develop the Rights Management Section.

L Meet functional permissions in the business system. In traditional business system, there are two kinds of rights management, one is the management of the function authority, while the other is the management of resource rights, and the function permission can be reused between different systems, and the resource permission cannot.

For the characteristics of OA system, permission Description:

Permissions

In the system, the permissions through the module + action to generate, the module is a sub-module in the entire system, may correspond to a menu, action is the entire module (in B/s system is a page of all operations, such as "Browse, add, modify, delete", etc.). Combining the module with it can produce all the permissions under this module.

Permission Groups

For more convenient management of permissions, and a combination of all permissions under a module, a " permission group ", that is, a module administrative permissions, including all basic permissions operations. For example, a permission group (user management), including user browsing, add, delete, modify, audit and other operations permissions, a permission group is also a permission.

role

A collection of permissions, a peer relationship between roles and roles that can be added to a role for easy allocation of permissions.

User Groups

A collection of people of a certain type, grouped together with the same characteristics. By granting permissions (roles) to a group, you quickly enable a class of people with the same permissions to simplify the tedious and time-consuming nature of granting permissions to users. The Division of user groups can be implemented by position, Project , or other. Users can belong to one or more groups.

There are 4 ways to empower a person (refer to the Freescale Office system)

A. adoption of positions

A) in the position, the permissions of the position member inherit the right of the current position, and the permissions for the subordinate position are not inheritable.

b) examples : such as the front desk this position, for the attendance check has the right, then you can set the front desk of the job attendance check the right to browse, so that they have the right to use this object, and then set up a, time-out query rights (of course, can not be set, the default can go into this module can query), All front desk personnel have the right to check in and out of attendance.

B. Adoption of the project

A) in a project, the permissions of the project members are derived from the permissions of the project, and they cannot inherit the permissions of the subordinate project, and for the project leader, he has full authority over the project, as well as the subordinate projects.

b) example : In a project, project members can upload documents to the project, view the documentation for the project, and can import the project by setting a browse right for the project, so that each member can access the project, plus the right to upload the project document and view the document.

c) for the group leader, because it can be assigned to a group leader of the right (the team leader is a special authority, it contains a variety of other rights of a rights package), all the team leader for the project has full authority, the project leader can view the project documents, approval, deletion, recovery, etc., these permissions for the project is still effective.

C. Adoption of the role

A) The members in the role inherit the permissions of the role, and the roles do not have a subordinate relationship to the role, they are parallel. Assigning permissions by role means that there is no way to assign permissions by position or item classification, such as: System administrator, data backup clerk ...

b) example : For this system, all personnel should be the default all the modules, such as my mail, My Documents, my log, my attendance ..., these module system members should have, we set up a role for the system default role, all the default access to the module to add the browse right to the inside, These modules are accessible to system members.

D. Direct designation

A) direct designation is the ability to use this permission by assigning a specific permission to an individual. The direct designation is a simplified version of the role designation, in order to create a role such as the leader of a project, omit the step of creating a role, so that the role is not too much.

b) example : Designate a project leader, assign the group leader to a person.

for positions, project groups:

If you add a new employee, the employee swaps the position, the project group, and the ability of the employee to automatically inherit the position, the project group, and the permissions that do not need to be reassigned.

User Management

A user can belong to one or more user groups and can grant permissions to all users in the group by authorizing the user group. A user can belong to multiple project groups, or hold multiple positions.

Authorization Management

Grant a basic permission or a role to a user or user group that has a string of permissions granted to a user or group of users, one of which is taken if the role, position, or project has the same basic permissions, such as leaving a role, position, or project group, except for the permissions granted by this role, position, project group in the user or user group. The permissions that a user has is a collection of permissions granted to all channels. Administrator users can view a list of the final permissions for each user.

Rights Management

Management of basic operation permissions and permission groups (a collection of basic operations permissions).

Realization of OA Authority management design

The physical data Model diagram is as follows:

Physical Data Model Diagram

According to the above design concept, the following basic tables are required for authority management:

Tb_user: Basic table of user information;

Tb_department: Department table;

Tb_company: Company table;

Tb_module: System Module table;

Tb_action: Action table for all actions in the system;

Tb_permit: The System basic permission table which is produced by the combination of Tb_module and tb_action two tables;

Tb_permit_group: A permission Group table, which divides all the permissions in a module into a permission group, which can be granted by permission groups;

Tb_role: A collection of Role tables, basic permissions. No superior and subordinate points;

Tb_position: Position table, with superior and subordinate points;

Tb_project: Project group table,

Tb_role_permit: Role Authorization form;

Tb_postion_permit: Position authorization form;

Tb_project_permit: Project Authorization form;

Tb_project_user: Project member table, Islead field represents this member as project leader;

Tb_postion_user: the position member table;

Tb_user_permit: User authorization form, user ID and role, position, project and directly granted permission string list;

Permissions are generated:

Composed of Modulecode in Tb_module and Actioncode in Tb_action

Permission Code Permitcode=modulecode+actioncode.

Example: modulecode=0101,actioncode=01, then permitcode=010101.

The permission values are Modulevalue and Actioncode, which are connected by an underscore.

Example: Modulevalue=sys_user,actionvalue=add,permitvalue= sys_user_add

Permission groups:

Includes a combination of permissions under the same module, such as administrative users, including basic permissions: Add, delete, modify, view, and so on, which are grouped together to form a user group-the user Management permission group. Other similar. Just to make it easier to see the allocation of permissions and permissions for the system.

Examples: such as the administrative user's permission code for 010101à view users, 010102à add users, 010103à delete users, 010104à modify users, 010105à audit users, and so on, these basic permissions together constitute a set of "User management" permission group.

Roles, positions, projects:

That is, a set of permissions that is divided by a particular need. This is accomplished using the role authorization form, the position authorization form, and the project authorization form. The authorization table holds the permission code Permitcode, not the Groupcode code of the permission group.

User authorization:

Implemented by the User authorization table, the Rolecode, Positioncode, Projectcode in the User authorization table are the strings composed of rolecode in the Role table, the string of the position table Positioncode and the Projectcode. does not correspond to the role code Rolecode in the Role authorization table, Positioncode in the Position authorization table, Projectcode in the Project authorization table (not a foreign key relationship between the primary table and the from table).

This enables a user to have multiple roles, multiple positions, and multiple projects.

The Permitcode in the User authorization table is a directly authorized permission code string that assigns permissions directly to the user.

Instance:

The record of the User Rights authorization table for user ID userid=1 is:

rolecode=001,003

Postioncode = 001,002

projectcode=001,005

Permitcode = 010101,020102

Indicates that this user has two roles, Code 001 and 003, and inherits the permissions of both roles;

Holds two positions, Code 001 and 002, and inherits two positions of authority;

Belong to members of two project groups, project code is 001 and 005, and inherit permissions from two projects.
Permissions that are assigned directly to the user are 010101 and 010102 permissions for both permission codes

User Rights string:

A collection of all rights strings for a user is combined into a permissions string and a directly assigned permission string in the table based on the user authorization table's role code, position code, Project code.