[FEATURE]: Authorization #376

Closed
opened 2026-01-27 13:23:37 +01:00 by simon · 1 comment
Owner

Description

Implement permission-based access control for groups, ensuring only administrators can manage groups while all users with member read permission can view them.

Estimated effort: 1-2h

Acceptance criteria

  • Groups added to all permission sets (read access for all, manage for admins only)
  • Authorization policies implemented for Group resource
  • UI permission checks implemented (hide create/edit/delete buttons for non-admins)
  • Only admins can create groups
  • Only admins can edit groups
  • Only admins can delete groups
  • All users with member read permission can view groups
  • Permission enforcement tested

External or internal Dependencies

  • All previous issues (Feature must be functional)
## Description Implement permission-based access control for groups, ensuring only administrators can manage groups while all users with member read permission can view them. **Estimated effort:** 1-2h ## Acceptance criteria - [ ] Groups added to all permission sets (read access for all, manage for admins only) - [ ] Authorization policies implemented for Group resource - [ ] UI permission checks implemented (hide create/edit/delete buttons for non-admins) - [ ] Only admins can create groups - [ ] Only admins can edit groups - [ ] Only admins can delete groups - [ ] All users with member read permission can view groups - [ ] Permission enforcement tested ## External or internal Dependencies - All previous issues (Feature must be functional)
simon added this to the Optional: I can group members milestone 2026-01-27 13:23:37 +01:00
simon added the
enhancement
S
labels 2026-01-27 13:23:37 +01:00
simon added this to the Sprint 11: 08.01-29.01 project 2026-01-27 13:23:37 +01:00
simon self-assigned this 2026-01-28 10:52:40 +01:00
simon modified the project from Sprint 11: 08.01-29.01 to Sprint 12: 29.01.- 19.02 2026-01-29 11:16:40 +01:00
Owner

Done in #404
But I decided for now to manage group via normal_user role (write access for member editing) because groups are a similar concept like CustomFieldValues for member filtering. We can talk in our next meeting if this make sense.

Done in https://git.local-it.org/local-it/mitgliederverwaltung/issues/404 But I decided for now to manage group via normal_user role (write access for member editing) because groups are a similar concept like CustomFieldValues for member filtering. We can talk in our next meeting if this make sense.
Sign in to join this conversation.
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: local-it/mitgliederverwaltung#376
No description provided.