Stefan
8bcec409c5
- Introduced a new module for managing user groups (`usrgrp`) in the administration interface. - Implemented CRUD operations for user groups: list, create, rename, and delete. - Added authorization checks to ensure only users with appropriate permissions can manage groups. - Created corresponding frontend JavaScript and SCSS files for the new module. - Updated documentation to reflect the new group management functionality and its authorization model. - Added SQL stored procedures for group management operations. - Established a new login script for database access, ensuring proper security practices.
6.0 KiB
6.0 KiB
status, date, applyTo, supersededBy
| status | date | applyTo | supersededBy | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Accepted | 2026-09-16 |
|
0021 — User group management: new usrgrp module, close the missing intranet_admin gate on group writes
Context
The per-user "Gruppen" dialog in the usr module (0014,
0015) lets an admin toggle an existing user's
membership in each usergroup, but there was no UI anywhere to create, rename or delete a
usergroup itself — fis_usergroups could only be populated by running a raw SQL script by hand
(hlp/db/create user group.sql). The DB-layer proc fis_admin_setUserGroup (create/rename) and
the read-side fis_admin_getUserGroupList already existed but were wired to no controller
endpoint, mirroring the exact gap 0020 closed for
user accounts.
While wiring this up, three of the four fis_admin_* group-write procedures were found missing
the module's standard intranet_admin authorization check entirely (fis_admin_addGroupMember,
fis_admin_remGroupMember, fis_admin_delUserGroup) — a caller with fds_sys > 4 but no
intranet_admin setting could add/remove a user's group membership or delete a group outright,
the same real authorization hole 0020 fixed for fis_admin_delUserAccount. fis_admin_setUserGroup
already had the check.
Decision
- New standalone module,
fn=usrgrp(IntranetController.AdminGroups.cs,fis.usrgrp.js/fis.usrgrp_txt_de.js/fis.usrgrp.scss), added as a third entry in the existing "Administration" sidemenu dropdown alongside Benutzerverwaltung and Systemüberwachung — per 0015's own stated consequence that any future admin-only feature should default to its own module under that dropdown rather than be folded into an existing one. The dropdown itself already stays visible while any of its children is open, so switching between Gruppenverwaltung and Benutzerverwaltung needs no dedicated "back" control. - Same dual-authorization gate as every other module under this dropdown:
fds_sys > 4server-side (AdminMinAuthExclusive/GetSystemAdminAuthAsync, shared fromIntranetController.Admin.cs) gates whether the module is reachable/visible at all;fis_admin_getUserAuth(@authaccount) > 1(theintranet_adminsetting) independently gates every read/write thefis_admin_*procs perform. Both together are what "only admins can see and change groups" means in this codebase — see the Consequences below for why this is enforced in four places, not one. - New
idcases inDo_Process_AdminGroups:list→fis_admin_getUserGroupList,create/rename→fis_admin_setUserGroup(same proc;renamesupplies an existing@usergroup_id),delete→fis_admin_delUserGroup. No membership editing here — that stays in theusrmodule's existing per-user checkbox dialog, unchanged. - Closed the missing
intranet_admingate onfis_admin_addGroupMember,fis_admin_remGroupMemberandfis_admin_delUserGroupby adding the samefis_admin_getUserAuth(@authaccount) > 1guardfis_admin_setUserGroupalready had, following the same "no-op instead of error" style 0020 used forfis_admin_delUserAccount: a caller withoutintranet_admin >= 2gets an unmodified result set / afalsesuccess bit, not a SQL error, consistent with every otherfis_admin_*proc in this area. - Frontend mirrors
fis.usr.js's list+ribbon pattern (renderLst/eM/iMn): a card-style row list with a base ribbon button ("Anlegen") and a per-row ribbon ("Umbenennen"/"Löschen") on row selection, using$ocms.dlgformfor create/rename and aconfirm(...)guard (no dialog) for delete — the same choice 0020 made for deleting a user account.
Consequences
- Deleting a group does not guard against it still having members — its
fis_usergroups_membersrows simply stop being returned (the membership query already filters on the group's ownDateDeleted). No UI currently surfaces "this group has N members" before deletion; acceptable since deletion is a soft-delete and the group row can be recreated with the same effective membership restored viafis_admin_addGroupMemberif this turns out to matter in practice. - Four separate
fis_admin_*procs/functions now each independently re-checkintranet_admin > 1(getUserGroupList,setUserGroup,delUserGroup,addGroupMember,remGroupMember— five, in fact) rather than a single shared gate; this is the established style in this codebase (everyfis_admin_*object re-checks for itself, see 0014) and not something this change revisits. - Same operational note as 0014/0015/0020: an account needs both
fds_sys > 4andintranet_admin >= 2to actually manage groups, not obvious from the UI.
Alternatives considered
- Extend the existing per-user "Gruppen" dialog with an inline "new group" input and a delete icon per row, instead of a new module. Rejected per explicit user direction — the user asked for a dedicated sidemenu entry for group management, separate from the per-user dialog.
- Fold into the
usrmodule as a second ribbon button. Rejected for the same reason 0015 splitusroffadminin the first place: two unrelated concerns (managing individual user accounts vs. managing the group catalog) behind one button was already identified as a mistake once it happened once; the "own module under the dropdown" default from 0015 applies directly.