Organisational Structures (Outdated)

Refer to https://mediahaven.atlassian.net/wiki/spaces/CS/pages/3938746383 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

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

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

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

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

Form

Pro

Cons

Basic

  • Simplicity

  • Only 3 layers: private, public and shared

Extended

  • Simplicity

  • Additional groups of ownership

  • Becomes unhandy when the number of departments increases

  • No specifically branded web site for each department

Multi-Tenant

  • Organisation specific features such as web sites and indices

  • Concepts such as profiles need configuration separately for each tenant

  • Not possible for a user to be member of two organisations => Use sharing

  • Becomes unhandy when the number of organisations increases

Multi-Tenant with sharing

  • Organisation specific web sites

  • Centralization of concepts such as metadata, indexation, profiles and filters

  • Complexity

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?