ADempiere and iDempiere Role Management Best Practices

Hi Everyone,

ADempiere and iDempiere offer a dizzying number of options to manage security and usability. This is a strength to someone with the right skills and knowledge. This is a hurdle to someone wanting to learn ADempiere or iDempiere. The goal of this post is to introduce you to role management basics and best practices. There are two ways this post can help you:

1. Prevent you from making a role structure mess that is both difficult to maintain and potentially does not work as expected, and
2. Help you get the most from role management with the least effort.

Let’s start by introducing topics:

• User – Users have usernames and passwords to gain access the system. A User can have one to many Roles. When a User logs in, they must choose one and only one Role.
• Role – Roles define that resources (windows, reports, forms, processes) are available to a User.
• Sub Role – same as a Role but nested under an existing Role. Roles inherit abilities from their Sub Roles.
• Role Data Access – Advanced tool that limits Roles can accessing tables, columns and records in the database.
• Menu – grouping of windows, reports, forms and processes in tree structure to help Users navigate. A Role is assigned a Menu. The User will see a specific Menu based on the Role the he/she chooses when they log into the system.
• Context – Advanced tool to limit what records appear in a window.

My recommendations are based on a DRY approach. DRY stand for Don’t Repeat Yourself. Adopting this approach helps limit mistakes and simplifies maintenance. Here are my recommendations:

1. Only use one Menu. Future maintenance of new windows, reports, forms and processes become a nightmare when you have multiple Menus. You will be inconsistent, and you will make a mistake. (Note: this is my opinion. There are others who prefer to manage access using different menus.)
2. Create a two-tier role structure. See below for a practical example.
   1. Tier 1 Summary Roles – Summary Roles are noun based, and they represent job titles or a group of people with similar abilities in the system. Tier 1 Roles do not have individual windows, forms, reports, and processes assigned to them. Instead, they are solely designed to collect Sub Roles.
   2. Tier 2 Ability Sub Roles – Ability Roles are verb based, and the represent actions. Keep all your allows in one role (example: Order Entry Ability). The allows or Abilities tell the system what the User can do.
3. Use the Role Data Access sparingly. Even though it is powerful, most people do not use this feature at all. You get into trouble here when you restrict access to something then forget why someone cannot see an order when others can.
4. Use Context any time you cannot solve a visibility issue with the above tools. There are times when hiding or showing a record is more complicated than just considering one’s Role. Context helps you solve complex record visibility challenges.

A practical application of the two-tier structure mentioned above includes Order Entry Clerk vs Order Entry Manager. The Order Entry Clerk is a Tier 1 Role. The Order Entry Manager is another Tier 1 Role. Both Tier 1 Roles get an Order Entry Ability Tier 2 Role. This tier 2 Role describes what order entry actions a user can do in the system.

As you can imaging, you can give the Order Entry Ability Tier 2 Role to many Tier 1 Roles (Customer Service, Service Managers, Warranty Managers, etc…).  You simply plug in the right actions to the right roles.

I hope this helps get you started in the right direction!! Let me know if I can be of further assistance.

Please note that ADempiere, iDempiere and Openbravo are forks or copies from Compiere. Therefore, they have similar abilities mentioned above. The biggest difference is that ADempiere and iDempiere are pure open source. There are no features held behind a commercial or paid license. This is especially true for open source manufacturing (MRP).