Projects:Role Access Extension
Contents |
Status
- Stage: Definition
- Development repository: https://code.openbravo.com/erp/devel/pi-roles/
- Planned Release:
Team
Definition
Currently, Openbravo security model allow to grant access to roles for different windows. It is also possible to exclude access for a tab within a granted window by using the table access. But more fine grained security for fields is no supported.
Feature overview
The objective of this project is to increase this security granularity making possible to define for a concrete role, in a window that has access to, which are the fields that cannot edit.
Users & use cases
The roles affected by this new feature are:
- Administrator: It is in charge of defining for each role, which are the fields that are not editable.
- Any role: Any role that modified as defined above will be affected in the sense it will not be allowed to edit the ungranted fields.
Design
Functional specification
The way of granting/revoking editability will be:
- Window level. It remains as it is now. It is possible to grant access to a window setting whether it is editable or not.
- Tab level. After this project it will be possible to add tab level access. At tab level it will be possible to define which tabs within a window are read only, it will be also possible to select a tab for allowing to write in order to be able to set some fields as readonly. Some considerations to take into account:
- When table is marked as no editable for the role, it is not possible to make it editable by tab (DAL wouldn't allow it).
- If a window is readonly and a tab within it is marked as editable, it will make this tab to be the only one that can be edited in that window.
- If a tab is marked as readonly (and there is no field set as editable), new and delete buttons should be disabled.
- Field level. In the same way as tab, it is possible to define whether a field is editable or not.
- If a tab is editable but all of the fields in it are not editable, the delete buttons should be disabled.
- Not editable fields in this way shouldn't be affected by read only logic.
Examples
Assuming the following window structure:
W1 (window) |- T1 (tab) |-F1 (field) |-F2
Model Definition | UI | Notes | ||||
W1 | T1 | F1 | F2 | F1 | F2 | |
E | - | - | - | E | E | Current case |
RO | - | - | - | RO | RO | Current case |
E | RO | - | - | RO | RO | New/Save/Delete buttons disabled |
E | RO | E | - | E | RO | New/Save/Delete buttons enabled |
E | E | RO | - | RO | E | New/Save/Delete buttons enabled |
E | E | RO | RO | RO | RO | New/Save/Delete buttons disabled |
Technical specification
Model Changes
Two new tables to be created:
- AD_Tab_Access and AD_Field_Access. Controlling access per role for each tab/field. These tables will have a check field to set read only.
New tabs:
- Tab Access and Field Access within Window window bellow Window Access.
- Tab Access and Field Access within Role window bellow Window Access.
Server Side Changes
As these new settings are role specific, they must not be cached, so the implementation cannot be in the window generation side.
It must be implemented in WindowSettingsActionHandler which is called when instantiating a new window.
Client Side Changes
WindowSettingsActionHandler is invoked in OBStandardWindow.initWidget, the callback function where the new information regarding tab/window accesssibility to modify the required javascript objects.
User experience design
NA
Planning
Development
Tracking
This feature development is tracked using the following issue(s): to-be-added