Decision: Nextcloud sharing

Status: Problem Clear
Assignee: Peter Mrkonjic
Date: 24.04.2026

Problem

When creating maps, users can select a base layer image from a predefined set. They can also upload their own base layer images and additional images to Nextcloud. Map collaborators should be able to access these images and upload their own.
Additionally, the PermaplanT team requires a dedicated Nextcloud structure for sharing internal files and documents that should not be accessible to other users.

Currently, the base layer images folder (incl. the base template files) is automatically created for each new user via the skeleton folder. However, this approach is not ideal, as it results in the duplication of the same folder structure and files for each newly created user. Additionally, any changes made to the skeleton folder (e.g. adding a new base layer image) will not be updated for existing users. Uploaded images are not shared among map collaborators, which leads to inconsistent access and unnecessary duplication of data.
The PermaplanT team currently uses a nextcloud circle to share documents internally, which appears to sometimes not be working as intended (e.g. some users need special rights to even see the folder).

Constraints

Users do not need to interact with Nextcloud manually.
Every user needs to have access to the default baselayer images.
Updates to the base layer images folder should be visible to all users.
Base layer images must be separated from other pictures/icons.
Shared images must only be available to other map collaborators.
Removed collaborators need their folder access removed.
Shared folders need specific subfolders.
- Needed to cleanly differentiate between different types of files.
- For example Map1/BaseLayerImages and Map1/Icons.
Skeleton folder only contains what is strictly needed.
The PermaplanT team requires a dedicated private folder for internal file sharing.
Needs to support 30.000 maps/users/folders.

Assumptions

The Nextcloud Team Folders (Group Folders) app is available, stable, and can be used in production.
Base layer images are relatively static and can be managed centrally.
Users may upload additional images that should remain scoped to map collaborators only.
Folder permissions (read/write) can be enforced reliably by Nextcloud.

Solutions

We will use the Team Folders (former Group Folders) app from Nextcloud to handle the public file sharing. A new team called Public will be created. Every existing and newly created user will be automatically added to the Public team via Keycloak configuration.
Team members will have read-only access to a new folder called Public. The folder will contain a subfolder called BaseLayerImages, that contains the template baselayer images. Other subfolders can be added as needed.

We will use the Team Folders (former Group Folders) app from Nextcloud to handle the dev team file sharing. A new team called Developer will be created. Every existing and future team member will be automatically added to the Developer team via Keycloak configuration.
Team members will have access to a new folder called PermaDev.

Alternative A: Team Folders App

Description
We will use the Team Folders (former Group Folders) app from Nextcloud to handle the file sharing between map collaborators. For each map a team incl. team folder will be created. The name of the team and team folder will be the same as the map name. Map collaborators can then just get added/removed from the team. When sharing a map publicly we will simply give the already existing Public team access to the new team folder.

Pros

Access is centrally managed.
No file duplication.
Supports 30.000 teams/folders.
- Tested locally with 10.000 users and 30.000 team folders.
Folders stay, even if owner gets deleted.
Permissions can be set.

Cons

Needs admin rights.
Team creation takes longer with each team.
- Locally team creation jumped from 468.8 ms (5 teams) to 4391.49 ms (30.000 teams)
Anything uploaded counts towards folder quota and not user quota.
- Folder has a set amount of available space (e.g. 5 MB).
- Anything uploaded inside the folder counts toward that space.
- It does not matter who uploads, the folder size will cap at the set limit.
Folder appears in root folder.

Description The folders will simply be directly shared between map collaborators. For each map a folder will be created. The name of the folder will be the same as the map name. Map collaborators can then just get added/removed from the direct share. When sharing a map publicly we will simply direct share with the already existing Public team.

Pros

Less admin overhead (all done by user).
No file duplication.
Supports 30.000 users/folders.
- Tested locally with 10.000 users and 30.000 shared folders
More flexible/lightweight.
- No need to create and manage teams or groups.
- Sharing can be configured directly per folder.
- Easier to add/remove collaborators dynamically.
Permissions can be set.
Anything uploaded counts towards owners quota.
Allows "Public Link" to share with outsiders.

Cons

No central management.
- No place to overview all map folders.
- Admin won't have access to folders, unless explicitly shared by users.
Folders get deleted, if owner gets deleted. (Note: Hannes didn't see it as con: If the owner gets deleted, their maps get deleted. And since image uploads to these maps only exist within the map, the collaborator isn't really impacted by this because the maps are only a part of a specific map.)
Folders can be reshared by other users (can be disabled in settings).

Decision

Rationale

Notes

Hannes wrote: I prefer B because it is much more privacy-focused (admin can't see uploaded images) and the pros vastly outweigh the cons. And since I as a user would hate to give admins access to my privately uploaded images, the con of "no place to overview all map folders" isn't a disadvantage at all - it gives users much more privacy.

The restrictions of A make a public base layer image folder unusable for users.