feat: update privilege keys and module configurations for enhanced access control
- Refactored privilege keys in `api.md` to use a more structured naming convention, aligning with the new `Group.Parent.Module` format. - Updated various module configurations across the application to reflect the new privilege key structure, ensuring consistent access control. - Removed deprecated keys and streamlined the privilege management process, enhancing clarity and maintainability. - Added new tests for privilege key parsing and grouping functionalities to ensure reliability and correctness. These changes significantly improve the application's privilege management system, providing a clearer structure for access control and enhancing overall security.
This commit is contained in:
@@ -240,36 +240,41 @@ HTTP mapping:
|
||||
| `DELETE /:id`, `POST /bulk-delete` | `delete` |
|
||||
| `POST /import` | `import` |
|
||||
|
||||
Catalog (`GET /privilege-keys`, needs `PRIVILEGES` `view`):
|
||||
Catalog (`GET /privilege-keys`, needs `ADMIN.SETTINGS.USER.PRIVILEGES` `view`). Keys use `Group.Parent.Module` or `Group.Parent.Module.Submodule`:
|
||||
|
||||
| code | label |
|
||||
| ------------------------ | ---------------- |
|
||||
| `PRIVILEGES` | Privileges |
|
||||
| `USERS` | Users |
|
||||
| `CONFIGURATION.DIVISION` | Divisions |
|
||||
| `CONFIGURATION.BRANCH` | Branches |
|
||||
| `CONFIGURATION.CUSTOMER` | Customers |
|
||||
| `CONFIGURATION.EMPLOYEE` | Employees |
|
||||
| `CONFIGURATION.PRODUCT` | Products |
|
||||
| `SALES.REQUEST` | Sales requests |
|
||||
| `SALES.ORDER` | Sales orders |
|
||||
| `SALES.PACKING_SLIP` | Packing slips |
|
||||
| `SALES.INVOICE` | Sales invoices |
|
||||
| `SALES.PAYMENT` | Sales payments |
|
||||
| `CONFIGURATION.SETTING` | Company settings |
|
||||
| `SALES.CYCLE` | Sales cycles |
|
||||
| `SALES.PLAN` | Sales plans |
|
||||
| `LOGISTICS.CYCLE` | Logistics cycles |
|
||||
| `LOGISTICS.PLAN` | Logistics plans |
|
||||
| code | label |
|
||||
| ---- | ----- |
|
||||
| `ADMIN.SETTINGS.USER.PRIVILEGES` | Privileges |
|
||||
| `ADMIN.SETTINGS.USER.USERS` | Users |
|
||||
| `ADMIN.SETTINGS.DATA.DIVISION` | Divisions |
|
||||
| `ADMIN.SETTINGS.DATA.BRANCH` | Branches |
|
||||
| `ADMIN.SETTINGS.DATA.CUSTOMER` | Customers |
|
||||
| `ADMIN.SETTINGS.DATA.PRODUCT` | Products |
|
||||
| `ADMIN.SETTINGS.DATA.SETTING` | Company settings |
|
||||
| `ADMIN.SALES.DATA.EMPLOYEE` | Employees |
|
||||
| `ADMIN.SALES.DATA.CYCLE` | Sales cycles |
|
||||
| `ADMIN.SALES.ACTIVITIES.REQUEST` | Sales requests |
|
||||
| `ADMIN.SALES.ACTIVITIES.ORDER` | Sales orders |
|
||||
| `ADMIN.SALES.ACTIVITIES.INVOICE` | Sales invoices |
|
||||
| `ADMIN.SALES.ACTIVITIES.PAYMENT` | Sales payments |
|
||||
| `ADMIN.SALES.ACTIVITIES.PLAN` | Sales plans |
|
||||
| `ADMIN.SALES.REPORT` | Sales reports |
|
||||
| `ADMIN.LOGISTICS.ACTIVITIES.PACKING_SLIP` | Packing slips |
|
||||
| `ADMIN.LOGISTICS.DATA.CYCLE` | Logistics cycles |
|
||||
| `ADMIN.LOGISTICS.ACTIVITIES.PLAN` | Logistics plans |
|
||||
| `ADMIN.LOGISTICS.REPORT` | Logistics reports |
|
||||
| `MOBILE.SALES.PLAN` | Sales plans (mobile) |
|
||||
| `MOBILE.SALES.PLAN.ATTENDANCE` | Branch attendance |
|
||||
| `MOBILE.SALES.VISIT` | Customer visits |
|
||||
|
||||
### Field purpose
|
||||
|
||||
Cycles and plans do **not** use a single key. Privilege is resolved from `purpose`:
|
||||
|
||||
| purpose | cycle key | plan key |
|
||||
| ----------- | ----------------- | ---------------- |
|
||||
| `sales` | `SALES.CYCLE` | `SALES.PLAN` |
|
||||
| `logistics` | `LOGISTICS.CYCLE` | `LOGISTICS.PLAN` |
|
||||
| purpose | cycle keys | plan keys |
|
||||
| ----------- | ---------- | --------- |
|
||||
| `sales` | `ADMIN.SALES.DATA.CYCLE` | `ADMIN.SALES.ACTIVITIES.PLAN`, `MOBILE.SALES.PLAN` |
|
||||
| `logistics` | `ADMIN.LOGISTICS.DATA.CYCLE` | `ADMIN.LOGISTICS.ACTIVITIES.PLAN`, `MOBILE.LOGISTICS.PLAN` |
|
||||
|
||||
`purpose` is read from **body** (writes) or **query** (lists). If omitted, the user may proceed if they have the action on **either** purpose; list results are filtered to purposes they can view. Superadmin bypasses.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user