Organisational Structures (Outdated)
- Alexis Rombaut
Refer to Rights Management for improved documentation
Introduction
The following documentation first describes different organisational structures with increasing levels of complexity. We describe the advantages and disadvantages of each structure and offer design questions to help in the choice. Firstly we will describe the default permissions applied to files during upload.
Permissions
Manual permissions
For manual permissions, the set of groups consists of the internal groups of which the uploading user is a member.  Internal means only groups belonging to the same organisation as the user. This is opposed to externalwhich means groups belonging to a different organisation. The rights come from the default rights configured for the group as indicated in the figure below.
External permissions
Groups can be configured to have external organisations as shown in the figure below. When a new file is ingested for these configured organisations, this group will be added to the permissions with the rights (view, edit, download) from the same configuration in the figure below. External permissions are only applied if enabled in the settings of the pretranscoder, specifically the setting ADD_EXTERNAL_GROUPS.
Structures
Basic
1 organisation
3 groups
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.
Further questions
Does the new entity have (strong) ownership of the content?
Does the entity want (strict) separation of content?
Do these entities often share content?
Is the sharing global or bilateral?
Are some users member of multiple entities?