Andrea PavlovicPermissons
To explain basic permissioning (ignoring workflows), we will use a helpdesk example. This is the basic table structure of our example:
There are three groups of users:
- employees
- customers
- accounting
The setup designed to make sure customers only see their own tickets, empoyees to have private comments and the accountants to have a set of departments (which are a tree) they are able to do actions for.
In the following text, we will distinguish between "list" and "join" rights. Both are basically "read" rights, but if a user does not have any transitions defined on an entity, a listing of that entity will always return an empty list.
Nevertheless, it may be permitted to be joined to another table which references it, so that an instance can always be retrieved with all it's dependencies. Here, the permission on the main entry basically gets inherited by instances it references.
See [Category] for an example.
Tickets
Apart from read, create, edit and delete actions, there is an additional "set_department" action which will set the value of the cost_bearing_department of a ticket. Here is a quick overview of who can do which action:
list join on create edit delete set_department
-------------------------------------------------------------------
employee all [private,public] yes all all -
customer own [public] yes own own -
accounting all - - - only own departments
-------------------------------------------------------------------An employee can create a ticket on behalf of a different user. A customer can only create tickets for herself.
A delete will automatically cascade to referenced instances, regardless of permissions on the referenced instances.
Category
The category table has no explicit permission set at all. But, to enable the creating of a ticket, where it is a required field, full read access is granted to anyone who can create tickets:
list join on create edit delete
-------------------------------------------------
employee all [ticket] - - -
customer all [ticket] - - -
accounting - [ticket] - - -
--------------------------------------------------Accounting has no direct read access but can still join any category which is being referenced in the ticket table by tickets. This is restricted to those tickets a role has list rights on.
Public Comments
Public comments can be written by customers and employees, only the ticket creator can edit or delete a ticket.
list join on create edit delete
-------------------------------------------------
employee created [ticket] created created created
customer created [ticket] created created created
accounting - - - - -
-------------------------------------------------Because the binding of the actions on this table is the "creating_client", a listing of this entity will returned only those owned by the user.
Nevertheless, joining this table on ticket will work and return any instances that reference a ticket a user has rights to.
So, in our case, an employee has access to all tickets and will therefore be able to join all public comments.
A customer will be able to join her own and any other user's comments onto her own tickets.
Private Comments
Public comments are not accessable to customers.
list join on create edit delete
-------------------------------------------------
employee all [ticket] all all all
customer - - - - -
accounting - - - - -
-------Because customers have no actions defined on this entity and it's not referenced by any other entity (they have access to), they do not see it at all.