Projects:Role Access Extension

Contents 1 Status 2 Team 3 Definition 3.1 Feature overview 3.2 Users & use cases 4 Design 4.1 Functional specification 4.1.1 Examples 4.2 Technical specification 4.2.1 Model Changes 4.2.2 Server Side Changes 4.2.3 Client Side Changes 4.3 User experience design 5 Planning 6 Development 6.1 Tracking 6.2 Implementation 6.3 Documentation 7 Resources

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

Implementation

Documentation

Resources