Permissions

Permissons

Permissons

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.

This is a good example for showing the xml definitions for different agendas, so here is how it's done:

<transitions>
	<!-- custom transitions for customers - owner is set automatically and only some attributes may be set-->
	<transition name="add" description="create ticket" notification="" pre-state="" post-state="" type="create" binding-reference="owning_client">
		<transition-attribute name="subject" required="true"/>
		<transition-attribute name="category" required="true"/>
	</transition>
	<transition name="modify" description="edit ticket" notification="" pre-state="" post-state="" type="edit" binding-reference="owning_client">
		<transition-attribute name="subject" required="false"/>
		<transition-attribute name="category" required="false"/>
	</transition>
	<transition name="purge" description="delete ticket" notification="" pre-state="" post-state="" type="delete" binding-reference="owning_client">
	</transition>
    <!-- custom transition for accounting -->
	<transition name="set_department" description="pay the costs" notification="" pre-state="" post-state="" type="edit" binding-reference="cost_bearing_department">
		<transition-attribute name="cost_bearing_department" required="true"/>
	</transition>
</transitions>

<agenda name="customer" description="customer creates tickets" binding-module="system" binding-entity="client">
	<agenda-bindings>
		<!-- see definition of transitions above -->
		<agenda-binding module="helpdesk" entity="ticket" transition="add" />
		<agenda-binding module="helpdesk" entity="ticket" transition="modify" />
		<agenda-binding module="helpdesk" entity="ticket" transition="purge" />
	</agenda-bindings>
</agenda>
<agenda name="employee" description="en employee - can see all comments and tickets" binding-module="" binding-entity="">
	<!-- default transitions - full create/edit/delete rights -->
	<agenda-bindings>
		<agenda-binding module="helpdesk" entity="ticket" transition="create" />
		<agenda-binding module="helpdesk" entity="ticket" transition="edit" />
		<agenda-binding module="helpdesk" entity="ticket" transition="delete" />
	</agenda-bindings>
</agenda>
<agenda name="accounting" description="department bound accounting agenda" binding-module="helpdesk" binding-entity="department">
	<!-- see definition of transition above -->
	<agenda-bindings>
		<agenda-binding module="helpdesk" entity="ticket" transition="set_department" />
	</agenda-bindings>
</agenda>

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 certain 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.

In our example, this means that a customer deletes a ticket including the private comments made by employees.

The set_department transition for accounting will only allow those departments to be set which are whthin the user's permissions. See [Departments].

Public Comments

Public comments can be written by customers and employees, only the ticket creator can edit or delete a ticket. This ensures that even an employee can not edit or delete anyone else's comments.

             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 return only those comments 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 and accounting 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.

Departments

Quick permission overview:

             list       join on    create   edit  delete  
----------------------------------------------------------------            
employee       -       [ticket]      -        -      -     
customer       -       [ticket]      -        -      -
accounting   see tree  [ticket]      -        -      -
----------------------------------------------------------------

Departments have a "parent" attribute which may refer to an instance in the same entity. This means, that those instances can be represented as a tree and permission can be set on nodes of the tree and delegation of responsibilities is possible.

This is the example we're going to look at:

The headline is the name of the department and under it is a list of users "responsible" as well as "permitted" for it.

The colored dots point out where new people are being assigned.

global vs delegable vs local

Global and delegable assignment both travel down the defined tree. Local puts the assignement on one node only.

Global means that the permission is set independent of other people having an assignment set on a node.

Deleigable means that the assignment only works where no one else has been assigned. Otherwise, the rest of the tree is "cut off".