Relationships among personnel, user groups, roles, and permissions

From: http://wxg6203.iteye.com/blog/682830

Integration of CRM permission management and user groups

Due to the need of work, the old system needs to be transformed, involving permissions. The following is a summary and consideration of the younger brother. If there is any incorrect information, please correct it, thank you !!!!

In the current CRM system, the concept of "User Group" is newly integrated. The purpose of "User Group" is to build a bridge between personnel and permissions through user groups. Realize the indirect many-to-many relationship between personnel and permissions.

I. Questions about merging some functions of the old system into the new system

Question 1: The concept of "department table" and "department dictionary information" and the newly integrated "User Group" must be repeated. Currently, the system uses "owner" to select "User Name" or "responsible department ". Which department is "User Group "? Return to the starting point: is "User Group" and "department" a concept?

Question 2: a department or user group must have the concept of "level": "manager" and "common employee ". So I think the "level" here is the concept of a role. "Role" may be required.

Question 3: there is a relationship between the user group table and the permission table. Then the "user_right" in systemlogin will no longer work, and there will be conflicts (for the time being, it is only to maintain the old system without errors). Should I delete user_right?

Conclusion: we cannot figure out their specific relationships and their repeatability.

2. relationships between individuals, user groups, permissions, roles, and menus

Note:

1. instructor a may belong to the Chinese group or geographical group ".

2. the "Chinese group" must have the "Chinese group leader" and "general teacher" positions, which are "Roles ". The "speech group leader" may only have one person, but there may be many "common teachers in the" speech group ", such as teacher a and teacher B. (Fine-grained control ).

3. the "text group" has multiple permissions. The "text group leader" has the permission to view the work reports submitted by "instructor a" and to view the work reports submitted by "instructor B, and grade the report. "Normal teachers in the Chinese text group" can only view their work reports and correct students' compositions. (Fine-grained Control)

Summary: permissions are often an extremely complex issue, but they can also be expressed simply as a logical expression that judges "who has the right to what (which) whether the logical expression for how operations is true.

Iii. Design Principles

Coarse granularity: indicates the class level, that is, only thetypeofobject is taken into account, not a specific instance of the object. For example, in user management, creation and deletion are treated equally for all users, but do not differentiate the specific object instances for operations. Fine Granularity: indicates the instance level, that is, the instance of the specific object (theinstanceofobject) needs to be considered. Of course, the fine granularity is to consider the specific instance only after the coarse granularity object category is considered. For example, to list and delete a contract, you must determine whether the contract instance is created by the current user.

The design principle is as follows: "The system only provides coarse-grained permissions, and fine-grained permissions are considered to be the responsibility of business logic ".

It should be emphasized again that the permission system described here is only an "incomplete" permission system, that is, it does not provide all solutions to the permission issue. It provides a foundation and solves the "common" (or coarse-grained) parts. Based on this, according to the unique permission Requirements of the "business logic", the remaining (or fine-grained) part of the code is complete. Back to the permission issue formula, the general design only solves the problem of who + What + how. Other permission issues are left to the business logic.

Example:

Personnel -------------- (user group --- role) ------------ permissions: Description

Personnel 1 ----------- (group 1 ------------- team lead) ------------- permission: grade the report of the group members.

Personnel 1 ----------- (group 2 ------------- member) ------------- permission: report writing. View your own reports.

Personnel 2 ----------- (group 1 ------------- member) ------------- permission: report writing. View your own reports.

Personnel 3 ----------- (group 1 ------------- member) ------------- permission: report writing. View your own reports.

Personnel 4 ----------- (group 2 ------------- team lead) ------------- permission: grade the report of the group members.

Recommendation table:

Personnel table,

User Group table,

Role table,

Permission table,

Personnel-group-role table,

Group-role-Permission table.

Oh, you may not be able to think about anything. Please throw your eggs or give your comments !!!!