User Role Permissions

I feel that although many people can make a member qualification management module, not many can do well. The management principles of this Member are unclear, and the implementation capability is not strong. In my opinion, to do a good job in member qualification management, we must first have a deep understanding of the concept and principles of member qualification management. Then there is a good design and implementation.

Therefore, I will discuss with you the concept and principles of membership management.

There are three important concepts in member qualification management: users, roles, and permissions.

A user is an entity or virtual entity that exists in the business logic (invisible but exists ). The user has a certain purpose and right.

A role is a set of user groups with certain commonalities (this set can be empty ).

Permission is a set of access rules. Permissions are essentially rules. It is a rule that specifies which users can do what and which users cannot do what.

For example, you can view reports only when you have a manager. This is what we did when parsing: A group of people can view reports, and these people share a common feature, that is, they have the role of a manager. The role feature of a manager is that in the actual business logic, the manager or the manager has the same high right.

The relationship between users and tasks is defined in permissions, and roles are not involved. Therefore, if you do not use a role, you can manage membership. However, as a collection of some users, role is more convenient, reasonable, and more in line with the objective form of business logic.

Priority of users and roles:
If a user is denied or allowed to access the same function operation, but the role of this user is allowed or denied, can this user perform this function operation? The answer we provide is no. Also, if there is a clear user who can do or cannot do it, follow this rule! Why? Because the role only serves to better organize users, it represents a category of users. However, there must be differences among these users. It is clear that user access rules are to acknowledge or implement such differences. Users are atomic, but roles are composed of user groups, so they are not atomic. Only atomic objects can ensure the correctness of this access rule.

Deny and permitted priority:
What is the highest priority of allow and deny? A user can have multiple roles, but some of these roles are allowed by an access rule, some are disabled, and some are not defined. At this time, whether to allow the user to pass or reject the request. We believe that the user's pass should be rejected. It is the complexity of a user role. Therefore, if there is not enough evidence to prove that "some roles in it are denied, but this user should not actually be denied", the user should be rejected first. This is also out of security considerations.

Relationship between department settings and roles in an enterprise:
I think a department is a role and a special role closely related to reality. This role contains a series of users (employees in this department, computers in this department (Virtual users), and so on)