This would be a really useful addition @PGijsbers, especially once permissions start being managed for teams rather than just individual users.

Before jumping into implementation, it might be good to align on what a minimal first version of user groups should look like, and how it fits with the broader permissions work tracked in #449.

A few thoughts/questions to kick off discussion:
-Would it make sense to introduce a simple Group concept first (name + members), without going straight into complex hierarchies?
-On the permissions side, my assumption is that a user’s effective permissions would just be the union of:
a. permissions granted directly to the user, and
b. permissions granted to any groups they belong to.
-Should groups be able to own assets themselves, or just be used as a way to grant access to assets owned elsewhere?
-From an API perspective, maybe starting small with endpoints to create groups, manage membership, and assign permissions would be enough for a first pass.

It feels like this could be introduced incrementally (core permission logic first, anything UI-related later), without affecting existing user-level permissions.

Happy to help think through a concrete data model or permission flow if that’s helpful before moving toward an implementation.

Extend the permission system with user groups #660

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions