Role Based Permissions
Permission to various documents in ERPNext can be managed using Role Based Permissions.
ERPNext implements a strong role-based permission system, i.e., access to documents and system operations are provided by assigning Roles to users. Permission is not directly assigned to users but is managed at the role level, providing consistency and easier administration within the organization.
The Role Permissions Manager is the hub component that enables administrators to set who can use particular DocTypes and how much control they have over them (e.g., Read, Write, Create, Submit, Cancel, Amend, Print, Email, Import, Export, Share, Report Access, and User Permission Management).
Once the roles are allocated to a user, the permissions can be then limited even more by User Permissions and field-level Permission Levels, yielding a layered and very flexible security system.
1. Using the Role Permissions Manager
To set up role-based permissions, go to:
The Role Permissions Manager functions by assigning permissions based on the following elements:
Roles
Roles determine a user's responsibility or access roles. A user can have more than one role, and a role can have varying levels of permissions.
- Examples of Roles: Accounts Manager, HR User, Employee, Projects User, Sales Manager, Stock User.
- Roles can be adjusted to mirror your organization's structure. You can introduce new roles to indicate special responsibilities.
Once a user is allocated a role they are given the permission allocated within that role throughout the system.
Document Types
Permissions are given on a DocType basis. Every DocType, be it a master (such as Customer, Item, Employee) or a transaction (such as Sales Order, Purchase Invoice, Stock Entry), has an independent set of rules for permissions.
- Examples of DocTypes: Sales Invoice, Leave Application, Project, Issue, Timesheet, Stock Entry, Asset.
- This means that permissions are fine-grained and can be customized for each operational area.
Permission Levels
Each field of a DocType is given a Permission Level (a number between 0 and 9). All fields are by default in Level 0.
- Permission levels enable various sets of rules for various groups of fields.
- For instance, you can grant a Sales User to see all fields at Level 0 (simple information of a Sales Order) but not allow them to edit fields at Level 1 (prices, taxes) without a superior role such as Sales Manager.
This gives exact control over what kind of information can be seen or edited in the same document.
Document Stages
Accesses are also dependent with the lifecycle state of a document. ERPNext documents pass several steps:
- Creation – Draft stage creation of document at first.
- Saving – Stores draft information.
- Submission – Document finalized and typically makes accounting/stock entries.
- Cancellation – Cancels a submitted document (limited to specific roles).
- Amendment – Facilitates changing a submitted document while maintaining audit history.
Besides, roles may be permitted or denied to take actions such as:
- Print or Email files.
- Export or Import information.
- View Reports associated with the DocType.
- Set others User Permissions.
This serves to integrate the control of each step of the document lifecycle so that it is adhered to closely with references to the organizational policies.
User Permissions
Above the role-based permissions, User Permissions enable administrators to limit access to individual records in a DocType.
- For instance, you could enable a Sales User to see only records belonging to a specific Company, Territory, Customer, Supplier, or Project.
- User Permissions can trickle down through Link Fields. For example, limiting a user to one Company will automatically limit them to records linked to that Company on related DocTypes.
For instance, Customer is a link field for a Sales Order or Quotation. User Permissions can be set using the Set User Permissions button in the Role Permissions Manager. This enables administrators to limit which customers a user can choose or view when they create or read documents.
To add User Permissions depending on documents or fields:
- Add a New Rule: Within the Role Permissions Manager, press the Add a New Rule button. A prompt will request that you choose a Role and a Permission Level. When chosen and confirmed, a new row will be inserted into the permissions table. This row determines which role has what access rights on the selected document and at what permission level.
This mechanism not only relies upon the role but also can filter down to record and field levels.
2. Role Based Permissions Operation
The Leave Application is an excellent example that highlights how role-based permissions, user permissions, and permission levels interact with each other.
Employee Role – Leave Application Creation
Leave Application needs to be created by an Employee. For this:
- The Employee role should have Read, Write, and Create permissions on the Leave Application DocType at Permission Level 0.
- This enables employees to edit and create their own leave requests.
Employee Access Restriction
An Employee must not be able to access anybody else's Leave Application. For this:
- A User Permission record should be added for every User–Employee pair, associating the User with his/her respective Employee record.
- This prevents an individual employee from seeing or modifying another employee's leave requests.
Select-Only Permission to Employees
In a few situations, an Employee would need to select a document in a different format but not necessarily have read access on the entire document itself. For this:
- Only give the Select permission for the Employee role.
- Example: If an Employee is picking their Employee ID while filling out a Leave Application form, they can pick it without having complete access to Employee master data.
HR Manager Accessibility: Leave application Comprehensive View
The HR Manager will be required to see every Leave Application in the firm. For this:
- Create a Permission Rule of the HR Manager role on the Permission Level 0.
- Grant Read (and probably Write, in case of edit) privileges.
- Uncheck the box that says Apply User Permissions so that the HR Managers supersede the user-level constraints and can access all records.
Approving Leave Role -Reporting workers only
The Leave Approver should have the ability to view and edit Leave Applications of employees that report to him/her. For this:
- Assign the role entitled Leave Approver to have Read and Write permissions at Permission Level 0.
- The correct Employee records must be incorporated in the Leave ApproverUser Permissions, consequently they can only access the leave applications of such employee.
- This is simplified in ERPNext as records of User Permission are automatically created when a Leave Approver is related to any employee documents, thus saving time to a greater extent.
Approval and Status Updates
Leave Applications may be approved or rejected only by HR Users or Leave Approvers. For this:
- The Status field in Leave Application is made at Permission Level 1.
- HR Users and Leave Approvers are assigned Read and Write permissions for Level 1 fields.
- All other users (including Employees) have only Read access to this field, so they cannot directly alter the status of their leave applications.
HR User Permission Delegation
The HR User must have the ability to delegate Leave Application access to subordinates when necessary. To this end:
- The HR User role is assigned the permission to Set User Permissions.
- A HR User can specify or update User Permissions on the Leave Application DocType for others so that there is controlled delegation of access without the need for administrator intervention.
