Entity Relationship Diagram#

Business Logic#

Image

The key entities are:

  • Person: represents a human user of the system
  • Space: represents the project workspace that groups its objects
  • Organization: an entity that can own a number of spaces
  • Collaborator: the privilege a person has on a space
  • DirectoryEntry: a branch or leaf in a directory tree representing the file system structure of a space
  • TrashEntry: a branch or leaf in a directory tree representing a file in the trash area of a space
  • Metadata: the manifest of a blob

A person can be a collaborator on a space, granting it privileges to administer it, write to it, or read files. Since persons are not managed here, the foreign key is stored only.

A space is owned by an organization and is bound to its contracted feature set and quota. The organization is not managed here, only is unique ID and contract enforcement parameters are stored.

The implementation of metadata and chunks is repository dependent.

Use cases#

Collaborators and spaces#

Image

  • An organization creates a space and becomes its owner. The person requesting the space-creation becomes a collaborator with 'admin' status.
  • An admin-collaborator can invite other persons to join the space with specific privileges. Alternatively a person can request to join a space.
  • An admin-collaborator can transfer admin-status to another collaborator, losing the admin-status himself in the process.
  • Future use: An admin-collaborator can configure the space to be all-admins.
  • An admin-collaborator can update and revoke the privileges of other collaborators.
  • A collaborator can use the space and leave it.
  • The organization can add or remove collaborators at will.
  • The organization can destroy the space, removing all collaborators and ordering the deletion of all stored data.

Enforcing the quota on the spaces-side#

Quotas are set on the organizational level. They are derived from the active contract (if there is one). It is assumed that contractual changes are rare.

The quota shall be enforced at upload/write time.

SpaceVolume = SUM(filesize of each file-version stored in a space)
OrganizationVolume = SUM(SpaceVolume of all spaces belonging to one organization)
NewVolume = size of upload
iff (OrganizationVolume + NewVolume > OrganizationQuota) then
    reject upload
else
    accept upload
    recalculate SpaceVolume
endif

Since the volume calculations are done inside the spaces-backend, it must be aware of the OrganizationQuota. Querying the skalio-id service for each request is to be avoided. This is uncritical, since contractual changes are rare: A contract change must be communicated to the spaces-backend, where the necessary preparations can be made.

Consequences:

  • The spaces-backend shall be aware of the relationship between space and organization. Since it is not the authoritative source of this information, it must be informed about changes to it.
  • The spaces-backend shall be aware of the (current, latest) OrganizationQuota as well as the current volume of each space.