Implementation of OA permission management (II)

Implementation of OA permission management design

The physical data model is shown as follows:

Physical Data Model Diagram

According to the above design ideas, permission management requires the following basic tables:

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 operations in the system;

Tb_permit: The system basic permission table generated by combining tb_module and tb_action;

Tb_permit_group: Permission group table, which divides all permissions in a module into one permission group. You can grant user permissions through the permission group;

Tb_role: Role table, a set of basic permissions. There are no superiors or subordinates;

Tb_position: rank table, which has the upper and lower levels;

Tb_project: Project Team table,

Tb_role_permit: Role authorization table;

Tb_postion_permit: Job authorization table;

Tb_project_permit: Project Authorization Table;

Tb_project_user: project member table. The islead field indicates that the member is the project leader;

Tb_postion_user: Job member table;

Tb_user_permit: user authorization table, user ID and role, position, project, and directly granted permission string table;

Permission generation:

It consists of modulecode in tb_module and actioncode in tb_action.

PermissionCodePermitcode = modulecode + actioncode.

Instance: modulecode = 0101, actioncode = 01, permitcode = 010101.

The permission value is a combination of modulevalue and actioncode, which is connected by an underscore.

Instance: modulevalue = sys_user, actionvalue = add, permitvalue = sys_user_add

Permission group:

Including a combination of permissions under a group of the same module, such as managing users including basic permissions: add, delete, modify, view, etc, combine these to form a user group-"user management" permission group. Others are similar. It is only for easier viewing of system permissions and permission allocation.

Instance: for example, if the permission code for managing a user is 010101 * view a user, 010102 * Add a user, 010103 * delete a user, 010104 * modify a user, and 010105 * audit a user, these basic permissions are combined into a set to form a "user management" permission group.

Roles, positions, and projects:

That is, a set of permissions is divided according to specific needs. Use the Role authorization table, position authorization table, and Project Authorization Table. The permission code permitcode is stored in the authorization table, not the groupcode code of the permission group.

User authorization:

Implemented by the user authorization table. The rolecode, positioncode, and projectcode in the user authorization table are the rolecode strings in the role table, the positioncode strings in the job table, and the projectcode strings. It does not correspond to the role code rolecode In the Role authorization table, positioncode in the position authorization table, and projectcode in the Project Authorization Table (not the foreign key relationship between the master table and the slave table ).

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

Permitcode in the user authorization table is the directly authorized permission code string, which directly assigns permissions to the user.

Instance:

The user permission authorization table with userid = 1 is recorded as follows:

Rolecode = 001,003

Postioncode = 001,002

Projectcode = 001,005

Permitcode = 010101,020102

Indicates that the user has two roles, code 001 and 003, and inherits the permissions of these two roles;

Hold two positions: 001 and 002, and inherit the permissions of the two positions;

The project code is 001 and 005, and inherits the permissions of the two projects.
The permissions assigned to the user are the permissions of the Code 010101 and 010102.

User permission string:

A permission string is obtained based on the role code, job code, and project code of the user authorization table, and the permission strings directly allocated in the table are combined into a set of all the user permission strings.