Introduction
The following documentation first describes different organisational structures in with increasing levels of complexity. We describe the advantages and disadvantages of each structures structure and offer design question questions to help in the choice. Firstly we will describe the default permissions applied to files during upload.
...
Manual permissions
For manual permissions, the set of the groups consists of the internal groups of which the uploading user is a member of. Internal
means only groups belonging to the same organisation as the user. This is opposed to external
external
which means groups belonging to a different organisation. The rights come from the default rights configured for the group as indicated in the figure below.
...
Examples: City of Zottegem on the shared cloud
Group | Example | View | Edit | Download | Note |
---|---|---|---|---|---|
everyone | iedereen | ✓ | ✗ | ✗ | |
public | publiek | ✗ | ✗ | ✗ | Default no rights, manually grant rights. Typically you only grant read rights. |
<organisation> | ✓ | ✓ | ✓ |
Extended
1 organisation
2 standard groups (everyone, public)
1 extra group for every department
Examples: City of Ghent with departments: toerisme, stadsbibliotheek, brandweer, politie, ...
Group | Example | View | Edit | Download | Note |
---|---|---|---|---|---|
everyone | iedereen | ✓ | ✗ | ✗ | |
public | publiek | ✗ | ✗ | ✗ | |
<department #1> | toerisme | ✓ | ✓ | ✓ | Only for files belonging that department |
<department #2> | stadsbibliotheek | ✓ | ✓ | ✓ | Only for files belonging that department |
<department #3> | brandweer | ✓ | ✓ | ✓ | Only for files belonging that department |
Multi-tenant
multiple organisations
per organisation 3 groups: everyone, public and organisation
Example: VideoHouse, Shared cloud
Group | Example | View | Edit | Download |
---|---|---|---|---|
everyone (organisation A) | everyone (prime) | ✓ | ✗ | ✗ |
public (organisation A) | no public access | ✗ | ✗ | ✗ |
<organisation A> (organisation A) | prime | ✓ | ✓ | ✓ |
everyone (organisation B) | everyone (sbs) | ✓ | ✗ | ✗ |
public (organisation B) | no public access | ✗ | ✗ | ✗ |
<organisation B> (organisation B) | sbs | ✓ | ✓ | ✓ |
Multi-tenant with shared groups
multiple organisations but one central / primary organisation
per organisation 3 groups: everyone, public and <organisation>
additional groups in the primary organisation for sharing content across organisations
Example: Viaa
Group | View | Edit | Download | Note |
---|---|---|---|---|
everyone (organisation: viaa) | ✓ | ✗ | ✗ | |
public (organisation: viaa) | ✗ | ✗ | ✗ | |
viaa-config (organisation: viaa) | ✗ | ✗ | ✗ | Used for sharing profiles, filters |
viaa-share (organisation: viaa) | ✓ | ✗ | ✗ | Used sharing files between all tenants |
viaa-admin (organisation: viaa) | ✓ | ✓ | ✓ | Used for providing the viaa administrator access to all content |
sbs (organisation: sbs) | ✓ | ✓ | ✓ | |
everyone (organisation: sbs) | ✓ | ✗ | ✗ | Used to provide all users of sbs access to its content |
public (organisation: sbs) | ✗ | ✗ | ✗ | |
vrt (organisation: vrt) | ✓ | ✓ | ✓ | |
everyone (organisation: sbs) | ✓ | ✗ | ✗ | Used to provide all users of vrt access to its content |
public (organisation: sbs) | ✗ | ✗ | ✗ |
Pros & Cons
Form | Pro | Cons |
---|---|---|
Basic |
|
|
Extended |
|
|
Multi-Tenant |
|
|
Multi-Tenant with sharing |
|
|
Design
Consider a new entity (e.g. a tourism department within a city) for whom we determine the most optimal form from the above 4 forms . List the defining properties of the new entity: e.g. own metadata model, separate configuration of facets, strong ownership of the content, etc. For each defining property evaluate how it fits within each of the 4 described forms.
...