In principle, there are two approaches to rights and role management in yuuvis RAD system.
create roles that fit 1-1 to user groups. Lots of rights are defined redundantly in each of roles. Each group gets its role and thats it.
create roles in strict sense, and assign multiple roles to a group, to obtain the desired level of control. If more than multiple roles define a certain right for a on object type, the resulting right is logical OR of individual rights (if RoleA gives Read right to Email, and RoleB gives Delete right to Email, UserX that has both roles will be able to Read and Delete the emails.)
Let us observe a highly simplified use case and two possible ways of creating and maintaining roles. Also for simplicity, let us assume that we only have Create, Read, Update, Delete rights (yuuvis RAD has more detailed right system, but the overall idea remains the same)
Use case description:
A company would like to manage the following document types:
Invoices
- Automatically imported in system, can be read by sales, accounting and management
- An accountant can edit an invoice with amount of up to 10,000e
- Only a member of management can act as senior accountant and edit an invoice with amount that is larger than 10,000e or delete an invoice
Vacation applications
- Can be created by anyone
- Can be read and edited by HR department or management
General purpose documents
- Can be created, edited, searched, read, etc. by everybody
The company has the following structure:
a) Sales
b) Marketing
c) HR
d) Management
e) Accounting
Let us see how do the roles look like according to these two approaches:
Straightforward approach is to create a role for each group and define rights for each document type within the group. Each group gets one role, done.
Roles would look like this:
SalesRole:
invoice: -
vacation: C
gen_document: CRUD
MarketingRole:
invoice: -
vacation: C
gen_document: CRUD
HRRole:
invoice: -
vacation: CRUD
gen_document: CRUD
ManagementRole:
invoice: CRUD
vacation: CRUD
gen_document: CRUD
AccountingRole:
invoice: CR, U where ammount <10000
vacation: C
gen_document: CRUD
This is quite convenient while a system is prototyped (usually it has a simple rights management), but gets quite difficult to manage once the real project starts and in particular if a company has a complex structure with lots of individual groups (one role for each group). The rights within roles are highly redundant and their management gets quite difficult and error prone if a business rule is changed: due to redundant rights within roles, all roles have to be edited and this process is error prone.
The same applies if a new document type is introduced - again, all roles have to be edited and changed, causing possible errors.
The second approach is to create roles in their strict sense, and to assign multiple roles to groups, as needed and necessary.
Keeping in mind that yuuvis RAD applies the logical OR function if a group (or person) has more than one role assigned, we can create the roles as following:
AllRole
invoice: -
vacation: C
gen_document: CRUD
HRRole
invoice: -
vacation: RUD
gen_document: -
AccountingRole
invoice: CR, U where ammount <10000
vacation: -
gen_document: -
SeniorAccountingRole
invoice: UD
vacation: -
gen_document: -
We can then assign roles to grops as follows:
a) default_suborganization: AllRole (thus everyone inherits it)
b) Marketing, Sales: -
c) HR: HRRole
d) Management: HRRole, AccountingRole, SeniorAccountingRole
e) Accounting: AccountingRole
Let us now imagine that after 6months of use, company decides to archive emails as well (CRUD for everybody) and introduces rule that only HR can create vacation applications if its duration is longer than 15 days.
In the first approach, that would mean adding new type to each role and adding CRUD rights to it. And then the same process for the Create right on vacation (adding a limiting clause for every role except HRRole).
In the second approach, only two roles are changed: AllRole gets CRUD rights to Emails and restricts Create right for vacation type. HRRole gets unconditional Create for vacation. Done.
To summarize, use the straightforward approach for prototypes or solutions with simple rights management system.
The second approach may be more difficult to set up at first since it requires a bit of planing, but it pays off as soon as system grows, gets new document types or if business case requires a change in rights system. This makes it preferred solution for projects with complex and/or frequently changing rights system.
