In the IDempiere_Workshop_2014 we talked about some possibilities to restrict iDempiere. There are different usecases we want to cover:

Creating a demo with a small functional overview to not confuse new users
fast creation of a new client with some standard functionalities
dividing the functional areas of iDempiere into modules that can be activated during an installation

There was a discussion on irc if we begin by creating a "Tiny iDempiere" to get a system with a minimal functionality or by first defining functional areas and think how we define modules. We agreed that we have to begin somewhere and want to do it iterative.

technical base

We discussed in the workshop about using ASP and/or Master Roles (using Window Customizations) for that as the technical base. This discussion did not lead to a final decision for one or the other way. Some differences are:

Roles allow always to open a role to use the full functionality (or use the admin role to access everything). That can be a blessing or a curse...
ASP may be a better way if we want to switch off an functionality totally (like manufacturing in a trading company).
ASP allows to define "modules" and "levels". At the end you can give access to some of them, but only client based.

It seems that both things deal with the same issues and need a similar functional grouping. ASP is good on a low layer to let a user have

what is missing?

Some things seem to be missing in the code:

JIRA tickets that are connected to this project can be found [with this JIRA search term].

check if one of my roles allows something

At some points we want to limit access with a formula e.g. with a display logic like "#AD_Role = 1000001". I see two problems with this approach:

The ID of the role can change if we load the "System Master Roles" with 2pack.
We will create a hierarchical system of master roles. The display logic in our package will likely depend on a master role not on the given user's role

We need a way to ask "Do I have the rights of role 'blabla'". Two ideas to do that:

create an SQL query for that that works recursive through all my roles
allow a (master) role to set an special context variable. (This is a bit similar like the aktivation of accounting dimensions works.) A EventValidator at Login time could do that.

change where clause depending on role

It should be possible that we want some roles see only some of the records in a table. I would like to override the WHERE-clause of a table in the Windows Customizations.

While talking to a customer about "deleting things" in the database I wonder if it would be possible to create a user role that does not see any deactivated records and an admin role to see all records.

Any other ideas?!

deal with "crossing" of roles (dimensions of roles)

Lets say we have a module for a base and one for manufacturing. Now I want to use accounting. The accounting module is a third one. It opens the accounting functions of the base module. Now the question: what about the accounting of manufacturing?!? Is it a fourth module? Is it activated automatically?

And what if we want to add reporting? Do we need "base reporting", "accountant reporting", "manufacturing reporting" and "manufacturing accounting reporting"?

One of the most important crossing dimensions is "administration". MAny modules will have functions that we want to use regularly and some windows that are only needed to configure them.

wdyt?

Document Type Access

The configuration of the allowed actions for a document type can be much work. Because document types belong to the client it may be a problem to do that in System. Any ideas?

take back rights

What if a user says he wants the "accounting reports" but does not need one or two of them? Is it possible to take back a right only for one user? Or can one role take back the right that another role gives?

Modules

This list is only a first proposal and should work as a seed for further thinkings.

Base

Is there a base without an ERP? What if someone wants to use iDempiere to maintain his stamps collection in some self-created tables? Is this an abstract idea to help us finding the "inner core"?

Base ERP User

This allows to work with the smallest thinkable system. I see a small one-man company that wants to sell some services to some businesspartners. Accounting is not done in-house. Products can be sold but there is no inventory, warehouse, etc.

Is it part of this base to deal with incoming invoices? Or is this another module "Purchase"?

Is there a subrole for "Sales" too?

Base ERP Admin

Configuration of some minor used things like groups, categories, etc.

Setup of things that have to be set up only once like bank account, etc.

User Admin

A role that is needed to deal with users, roles and security

Open Items
Accounting
Inventory

IDempiere light

Contents