Admin kann Nutzer inaktiv schalten (kein Login mehr, Daten bleiben vollstaendig erhalten) und wieder aktivieren

lena commented

2026-09-29 08:53:40 +02:00

Collaborator

Story: Nutzer voruebergehend deaktivieren statt loeschen

As a Admin,
I want to einen Nutzer in der Nutzeruebersicht auf "inaktiv" schalten und spaeter wieder auf "aktiv" zuruecksetzen koennen,
so that ich einem Nutzer den Zugang sperren kann, als waere sein Konto geloescht - ohne dass dabei irgendwelche Daten verloren gehen, falls er spaeter wieder Zugang bekommen soll.

Wortlaut des Nutzers: "Ich moechte als Admin in der Lage sein, einen User als "inaktiv" zu schalten, d.h. der User kann sich nicht mehr einloggen / es ist, als waere sein account geloescht. Man kann ihn aber wieder "aktiv" schalten und seine Daten sind vollstaendig erhalten."

Hintergrund: Die Admin-Nutzeruebersicht mit endgueltiger Loeschung gibt es seit #206, das Zuruecksetzen des Passworts durch den Admin seit #210. Fuer das sofortige Abmelden auf allen Geraeten gibt es bereits einen Mechanismus (SessionsRevokedBeforeUtc, wird von #210 genutzt) - der soll hier wiederverwendet werden.

Acceptance criteria:

In der Admin-Nutzeruebersicht hat jeder Nutzer eine Aktion "Inaktiv schalten" bzw. - wenn er bereits inaktiv ist - "Wieder aktivieren". Der aktuelle Status ist in der Uebersicht sichtbar (z. B. Badge "inaktiv").
Inaktiv schalten fragt vorher nach einer Bestaetigung.
Ein inaktiver Nutzer kann sich nicht einloggen - weder mit Passwort noch ueber eine gespeicherte Anmeldung ("angemeldet bleiben"). Bestehende Sitzungen auf allen Geraeten enden sofort beim Inaktiv-Schalten.
Ein inaktiver Nutzer kann auch "Passwort vergessen" nicht nutzen, um sich wieder Zugang zu verschaffen.
Beim fehlgeschlagenen Login verhaelt sich die App fuer einen inaktiven Nutzer so, als gaebe es das Konto nicht (gleiche Meldung wie bei unbekanntem Konto/falschem Passwort) - kein Hinweis, dass das Konto existiert.
Ein inaktiver Nutzer bekommt keine E-Mails und keine Push-Benachrichtigungen mehr.
Beim Inaktiv-Schalten wird nichts geloescht oder veraendert: eigene Listen, Mitgliedschaften, Eintraege, Kommentare, Zuweisungen, Einstellungen und Avatar bleiben vollstaendig erhalten.
Nach "Wieder aktivieren" kann sich der Nutzer mit seinem bisherigen Passwort wieder einloggen und findet alles so vor wie vorher.
Ein Admin kann weder sich selbst noch ein anderes Admin-Konto inaktiv schalten (gleiche Schutzregel wie beim Loeschen in #206).
Das Inaktiv-/Aktiv-Schalten ist serverseitig nur fuer Admins erlaubt.

Out of scope for this story:

Automatisches Inaktiv-Schalten (z. B. nach laengerer Nichtnutzung).
Ein Grund-/Notizfeld zum Inaktiv-Schalten.

Open questions: (escalate to human if unanswered)

Was sehen andere Nutzer, die mit dem inaktiven Nutzer Listen teilen? Vorschlag PO: Geteilte Listen, die dem inaktiven Nutzer gehoeren, bleiben fuer die anderen Mitglieder normal nutzbar; der inaktive Nutzer bleibt in Mitgliederlisten/Zuweisungen sichtbar (evtl. mit Hinweis "inaktiv"), damit beim Reaktivieren nichts neu verknuepft werden muss. Er kann nicht neu eingeladen oder neu zugewiesen werden, solange er inaktiv ist.

Als Backlog-Item vom Nutzer eingereicht (per Chat, nicht im laufenden Loop-Zyklus geclaimt).

## Story: Nutzer voruebergehend deaktivieren statt loeschen **As a** Admin, **I want to** einen Nutzer in der Nutzeruebersicht auf "inaktiv" schalten und spaeter wieder auf "aktiv" zuruecksetzen koennen, **so that** ich einem Nutzer den Zugang sperren kann, als waere sein Konto geloescht - ohne dass dabei irgendwelche Daten verloren gehen, falls er spaeter wieder Zugang bekommen soll. Wortlaut des Nutzers: "Ich moechte als Admin in der Lage sein, einen User als "inaktiv" zu schalten, d.h. der User kann sich nicht mehr einloggen / es ist, als waere sein account geloescht. Man kann ihn aber wieder "aktiv" schalten und seine Daten sind vollstaendig erhalten." Hintergrund: Die Admin-Nutzeruebersicht mit endgueltiger Loeschung gibt es seit #206, das Zuruecksetzen des Passworts durch den Admin seit #210. Fuer das sofortige Abmelden auf allen Geraeten gibt es bereits einen Mechanismus (`SessionsRevokedBeforeUtc`, wird von #210 genutzt) - der soll hier wiederverwendet werden. **Acceptance criteria:** - [ ] In der Admin-Nutzeruebersicht hat jeder Nutzer eine Aktion "Inaktiv schalten" bzw. - wenn er bereits inaktiv ist - "Wieder aktivieren". Der aktuelle Status ist in der Uebersicht sichtbar (z. B. Badge "inaktiv"). - [ ] Inaktiv schalten fragt vorher nach einer Bestaetigung. - [ ] Ein inaktiver Nutzer kann sich nicht einloggen - weder mit Passwort noch ueber eine gespeicherte Anmeldung ("angemeldet bleiben"). Bestehende Sitzungen auf allen Geraeten enden sofort beim Inaktiv-Schalten. - [ ] Ein inaktiver Nutzer kann auch "Passwort vergessen" nicht nutzen, um sich wieder Zugang zu verschaffen. - [ ] Beim fehlgeschlagenen Login verhaelt sich die App fuer einen inaktiven Nutzer so, als gaebe es das Konto nicht (gleiche Meldung wie bei unbekanntem Konto/falschem Passwort) - kein Hinweis, dass das Konto existiert. - [ ] Ein inaktiver Nutzer bekommt keine E-Mails und keine Push-Benachrichtigungen mehr. - [ ] Beim Inaktiv-Schalten wird **nichts** geloescht oder veraendert: eigene Listen, Mitgliedschaften, Eintraege, Kommentare, Zuweisungen, Einstellungen und Avatar bleiben vollstaendig erhalten. - [ ] Nach "Wieder aktivieren" kann sich der Nutzer mit seinem bisherigen Passwort wieder einloggen und findet alles so vor wie vorher. - [ ] Ein Admin kann weder sich selbst noch ein anderes Admin-Konto inaktiv schalten (gleiche Schutzregel wie beim Loeschen in #206). - [ ] Das Inaktiv-/Aktiv-Schalten ist serverseitig nur fuer Admins erlaubt. **Out of scope for this story:** - Automatisches Inaktiv-Schalten (z. B. nach laengerer Nichtnutzung). - Ein Grund-/Notizfeld zum Inaktiv-Schalten. **Open questions:** (escalate to human if unanswered) - Was sehen **andere** Nutzer, die mit dem inaktiven Nutzer Listen teilen? Vorschlag PO: Geteilte Listen, die dem inaktiven Nutzer gehoeren, bleiben fuer die anderen Mitglieder normal nutzbar; der inaktive Nutzer bleibt in Mitgliederlisten/Zuweisungen sichtbar (evtl. mit Hinweis "inaktiv"), damit beim Reaktivieren nichts neu verknuepft werden muss. Er kann nicht neu eingeladen oder neu zugewiesen werden, solange er inaktiv ist. --- Als Backlog-Item vom Nutzer eingereicht (per Chat, nicht im laufenden Loop-Zyklus geclaimt).

lena added the

priority/should

type/feature

labels

2026-09-29 08:53:40 +02:00

lena self-assigned this

2026-09-29 09:56:50 +02:00

lena added the

status/claimed

label

2026-09-29 09:56:50 +02:00

lena commented

2026-09-29 09:56:51 +02:00

Author

Collaborator

Claimed by the autonomous loop (go-cycle 2026-09-29). Design first; the open question about what other members see, plus a few further scope decisions, will be asked to the human up front before implementation starts.

lena commented

2026-09-29 10:23:55 +02:00

Author

Collaborator

Decisions by the human (2026-09-29, asked up front):

Other members: the inactive user stays visible in member lists and on existing assignments, with an "inaktiv" hint next to the name; lists owned by them stay fully usable for the others.
Assignment: inactive users are hidden from the assignment picker and the server rejects new assignments to them; existing assignments stay.
API keys: blocked while inactive, kept stored, work again after reactivation.
Emails: no mail on deactivation; one short mail on reactivation ("you can log in again"). Otherwise no mails/pushes while inactive.

Decisions by the human (2026-09-29, asked up front): - Other members: the inactive user stays visible in member lists and on existing assignments, with an "inaktiv" hint next to the name; lists owned by them stay fully usable for the others. - Assignment: inactive users are hidden from the assignment picker and the server rejects new assignments to them; existing assignments stay. - API keys: blocked while inactive, kept stored, work again after reactivation. - Emails: no mail on deactivation; one short mail on reactivation ("you can log in again"). Otherwise no mails/pushes while inactive.