Design and Implementation of custom system for general module management functions (32 -- permission design [2])

Permission design (2)

Ii. Visual permissions of module records. In general, what records can you see and what records can't be viewed? It's easy to say and not easy to do.

Let's start with a simple requirement. If one internal engineer processes all the contracts in the sales system built above, there is no permission to design the system, add the internal departments to the sales department to view all the contracts for sales 1, 2, and 3. However, if each sales department has a separate internal engineer to process the sales orders of its own department and does not interfere with each other, the visual permission of the design record is required. Now the system has built-in Department permissions. The Department structure in the example is as follows:

Department Code	Department name	Operation Records	Operation Level	Others
00	Company
0001	Office	True
0002	Finance Department	True
0010	Sales Department
001001	Sales Division 1		True
001002	Sales Department 2
001003	Sales Department 3

In the above structure, the operator sets the visual permission for the Record Based on the department to which it belongs. The person in department 00 can view all the data, 0001,0002. Because the option for operating all records is set, the person in both departments can also view all the records. 0010 you can view all data of 001003, and. You can only view data under your own department. 001001 sets an operation-level value, indicating that the user can view the permissions of 0010, and the data of the same level can be seen.

Corresponding permission settings are actually the process of adding conditions to SQL. For the salesman, let's look at the SQL statement of the salesman in Sales Department 2.

    select       _t6020.tf_salesmanId as tf_salesmanId ,        _t6020.tf_name as tf_name ,        _t6020.tf_sex as tf_sex ,        _t6020.tf_birthday as tf_birthday ,        _t6020.tf_age as tf_age ,        _t6020.tf_telnumber as tf_telnumber ,        _t6020.tf_phonenumber as tf_phonenumber ,        _t6020.tf_eMail as tf_eMail ,        _t6020.tf_remark as tf_remark ,        _t9011.tf_departmentId as _t9011___tf_departmentId ,        _t9011.tf_name as _t9011___tf_name     from        Salesman _t6020     left outer join        _Department _t9011             on _t9011.tf_departmentId = _t6020.tf_departmentId      where        (            (                _t9011.tf_departmentId like '001020%'            )        )

Query the SQL statements for all orders in business 2

Select _ t6040.tf _ ordersId as tf_ordersId, _ t6040.tf _ ordersNumber as tf_ordersNumber, _ region _ date as tf_date, _ t6040.tf _ finished as tf_finished, _ region _ remark as tf_remark, _ t6010.tf _ customerId as _ t6010 ___ tf_customerId, _ t6010.tf _ name as _ t6010 ___ tf_name, _ t601_tf _ salesmanId as _ t6020 ___ alias, _ t601_tf _ name as _ t6020 ___ tf_name, _ t9011.tf _ 1_mentid as _ t9011 ___ tf_1_mentid, _ t9011.tf _ name as _ t9011 ___ tf_name, from Orders _ t6040 // order left outer join Salesman _ t6020 // clerk on _ t601_tf _ salesmanId = _ t6040.tf _ salesmanId left outer join _ Department _ t9011 // Department on _ t9011.tf _ required mentid = _ t601_tf _ 1_mentid where _ t9011.tf _ 1_mentid like '000000'

We can see that the sub-modules of all departments, no matter how far they are from the department, must be associated in a level-1 manner when searching for data, and are eventually associated with the Department and added to the qualified value of the Department. For the system structure, we can see that the sub-modules of the Department include: salesman, order, order details, and order receipt.

Not only does the above limit value need to be added when data is directly obtained from each sub-module, but also the value of the Department should be limited when the fields of these modules are used as the aggregate field count or sum, all departments and their sub-modules must be added to the Department's limit value when the number of Statistics records is used as the navigation value. In a word, the people in Sales Department 2 SEE and collect data from their respective departments. Regardless of the distance between the module and the Department. If your system is designed at a level 10 or above, efficiency may be considered, but this should not be your consideration. Is this Z kernel? Http://www.bkjia.com/kf/ware/vc/ "target =" _ blank "class =" keylink "> encrypt/decrypt/6aOsxuR3aGVyZdfTvuTKx8/zyc/D5rXE1eLR + bzTyOu1xDxwcmUgY2xhc3M9" brush: java; "> where _ t9011.tf _ partition mentid like '201312'

This has to be optimized, because it is the last level and can be used.

_t9011.tf_departmentId ＝ '001020'

If the permission is 0010

_t9011.tf_departmentId like '0010%'

This is the permission of a single department. You can also design this permission.

_ T9011.tf _ dimension mentid like '000000' or
_t9011.tf_departmentId like '001030%'
This operator can view all data of Sales Department 2 and sales department 3.

The preceding method is used to design the permission record for a single module. Now, we can add this limited permission to the records of any module. For example, we have a statistician who specializes in counting orders of gold customers, we can add a permission to the "customer level" module, and then assign this permission to the statistician so that they can only see all the data of gold customers, and other data will not be seen.

If you have an industry order analyst, you can add permissions to the industry module and select one industry or several industries, so that analysts in this industry can only see all customers and orders in these industries.

The above permissions can be superimposed: for example, if there is a gold analyst in Sales Department 2, then when you check the customer unit, the gold unit is limited and the salesman is limited to Sales Department 2, when querying the sales order, you must be satisfied with the order of the gold medal customers who sold the second division.

All these permissions are designed to take effect immediately after the front-end design.

Continue to extend. For example, if a large order analyst sees an order of more than 0.1 million yuan, he should also be able to design a permission to place it above the total order amount. I did not do this function now, but I just came up with an idea. If I want to do it, it will take 1 or 2 days.

The above is a simple design of the visual permissions of module records, if there is a better way, please follow the instructions or exchange jfok1972@qq.com.