Permission management for enterprise-level development

In the process of development of various enterprise-level systems, it is difficult to avoid the design of permission processing. A good permission system not only provides a secure solution for the system, but also saves development time and improves the maintainability of the system.
There are two types of permission requirements:
A. Module Permissions
Permission of the operation function module or menu. For example, does user u have the right to operate the "invoice interface ".
B. Data Permissions
Data permissions control the data access scope.
For example, if there are 1000 invoices, user U has the right to operate on the control of invoices, whether to operate on all invoices, self-created invoices, or invoices of its own department.
C. Field Permissions
In some cases, we set permissions for special fields. For example, the customer service department cannot see the customer contract amount.
D. Operation permission
The operation permission is the user's control over the data operation method. It is the creation, modification, deletion or other special permissions, such as sharing.
The operation permission is generally based on the module permission. For example, you can control the operation permissions of the user U invoice module. However, there may also be special situations. For example, a data recorder can create all data types and cannot browse, modify, or delete data.

To create a permission control framework suitable for your project, you need to decide based on your project needs. What suits you is the best. One-sided pursuit of flexibility and powerful functionality may not provide users with the best experience. We recommend that you use the simplest solution to meet your project requirements when deciding what permission framework to use.

There are usually several levels based on requirements.
1. Fixed roles
The system provides several fixed roles. Such a system generally has stable requirements and has fewer changes. For example, a forum provides several simple roles, namely administrators, moderators, members, and non-members, to control permissions. In this way, due to the fixed role, we can adopt hard encoding in the code, so it is easier to control role permissions or data permissions. This control method is simple and effective, and provides good security control in the shortest time. Simplified coding not only reduces development costs, but also reduces maintenance costs. More important user operations are also simplified, significantly improving ease of use.
If your system uses this method to solve the problem, it is absolutely not recommended to use other solutions. Many colleagues will say that if the demand changes, will the code be frequently modified? There are endless demands. If you want to make a huge effort to meet unknown demands, it is not worthwhile to waste your precious time on things that may not happen. It can also be called a good system to meet the needs of a period of time.
Of course, if you can clearly understand that this method cannot meet your needs in the future, you can consider the following solution.
2. Dynamic roles:
Many projects do not have several fixed roles to meet system requirements. As the business operation mode changes, more positions may be set, and more positions will bring more role demands. At this time, using a fixed role is very bad.
A. Module permissions:
Creating dynamic roles to control module permissions is not complicated. We only need a few tables: "menu", "role menu", and "User Role table" to implement our system.
B. Data Permissions
Data permission control is generally related to the organizational structure. In Microsoft's CRM, data permissions are divided into multiple types: Global, department, subordinate organization, and owner.
Global: All data
Department: Data of the current Department, excluding subordinate organizations.
Subordinate organizations: Data of subordinate organizations, excluding their respective departments.
Owned: owned or created.
The classification of specific scope levels must also be tailored to different project requirements. For example, global, subordinate personnel, and yourself.
C. Field Permissions
The control of field permissions is the most tedious control of permission control, because the control of field permissions often leaves the scope of permission control and affects the interface layout.
Field permissions are generally based on the module permissions. We need to set "module field table" and "role module field table" to store the field permissions owned by the role.
D. Operation permission
Operation permissions are the control of a specific user's operation permissions. The control of Operation permissions is often based on the module permissions, and occasionally there are special cases.
The module-based operation permission is relatively simple. You only need to set the "role operation table" for the Operation permission.
The module-based operation permission control is relatively complex. You need to set a "module operation table" to maintain the operation types owned by the module, at the same time, set the "role module permission table" to control the operation scope of the module owned by the role.

(Note: The tables mentioned above are just examples. They are not classic designs .)

Tasks are often more complex than the situations listed above, and it becomes more difficult to gather permissions together.
For example, in CRM, there will be coexistence. First, the basic dynamic role permissions, then the role-based module permissions, and then the module-based operation permissions, the data permission is also staggered with the module permission, and the field permission is troublesome. We fell into a bitter sea.

Finally, we would like to remind our colleagues that they must clearly understand their project requirements before starting your design. Only the design based on the requirements can be a good design, and it will not waste your sweat. Never get lost in the ideal realm of the all-powerful.

PS: The above is just my opinion. please correct me if there are any omissions or mistakes. As for more detailed table design and code implementation, I will try my best to offer them when I have time.
(Original, reprinted, please specify the source .)