Skip to content

GitLab

Permissions · Changes

Page history
Edited online authored by Andrea Pavlovic's avatar Andrea Pavlovic
Hide whitespace changes
Inline Side-by-side
Permissions.md
View page @ c6ab23c2
......@@ -38,12 +38,12 @@ 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
-------------------------------------------------------------------
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
......@@ -55,6 +55,9 @@ 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].
## Category
The category table has no explicit permission set at all. But, to enable
......@@ -73,24 +76,25 @@ 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.
the user 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.
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 returned only those owned by the user.
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.
......@@ -114,7 +118,29 @@ accounting - - - - -
-------
```
Because customers have no actions defined on this entity and it's not referenced
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
\ No newline at end of file
## Departments
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:
![permissions_department.png](https://bitbucket.org/repo/5qjnRde/images/2305401363-permissions_department.png)
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.
We have four users with these assignements set:
* boss - global on Company
* head a - deligable on Department A
* head a.3 - deligable on Section A.3
* head a.1.2 - deligable on Section A.1.2
* Secretary a.1 - local on Section A.1
### global vs deligable vs local
\ No newline at end of file