robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Geteilte Listen bleiben bei Kontoloeschung erhalten - Besitz geht automatisch an ein verbleibendes Mitglied #223

New issue
Closed
opened 2026-09-29 11:14:38 +02:00 by lena · 5 comments
lena commented 2026-09-29 11:14:38 +02:00
Collaborator
Copy link

Story: Automatische Besitz-Nachfolge statt Loeschung geteilter Listen

As a Mitglied einer geteilten Liste,
I want to dass die Liste erhalten bleibt, wenn das Konto ihres Besitzers geloescht wird (selbst oder durch den Admin), und automatisch ein verbleibendes Mitglied Besitzer wird,
so that eine gemeinsam genutzte Liste (z. B. die Familien-Einkaufsliste) nicht ohne Vorwarnung fuer alle verschwindet, nur weil eine Person ihr Konto loescht.

Hintergrund (Diskussion mit dem Menschen, 2026-09-29): Erwogen wurde, beim Teilen alle Mitglieder zu Admins zu machen. Verworfen zugunsten dieser Loesung, weil "alle sind Admins" jedem Mitglied das Loeschen der Liste fuer alle erlauben wuerde und das eigentliche Problem - Datenverlust beim Loeschen - trotzdem nicht loest. Diese Story aendert das Rechtemodell (ein Besitzer, sonst Mitglieder) nicht.

Ist-Stand: EraseUserAccountCommandHandler (gemeinsam genutzt von der eigenen Kontoloeschung und der Admin-Loeschung aus #206) loescht alle Listen, deren Besitzer der Nutzer ist - To-Do-Listen, Einkaufslisten (und damit die daran haengenden Vorratsschraenke) und Masterpacklisten - auch wenn sie mit anderen geteilt sind. Die anderen Mitglieder verlieren sie komplett.

Acceptance criteria:

  • Wird ein Konto geloescht (selbst oder durch den Admin), bleibt jede Liste, deren Besitzer es war und die noch mindestens ein weiteres Mitglied hat, erhalten; ein verbleibendes Mitglied wird automatisch Besitzer.
  • Gilt fuer alle Listentypen mit Besitzer: To-Do-Liste (inkl. priorisierte Liste), Einkaufsliste, Masterpackliste. Ein Vorratsschrank bleibt zusammen mit seiner verknuepften Einkaufsliste erhalten und geht mit ihr an denselben neuen Besitzer.
  • Neuer Besitzer wird das verbleibende Mitglied, das als erstes der Liste beigetreten ist. Dafuer wird ab jetzt bei jeder neuen Mitgliedschaft das Beitrittsdatum gespeichert (auch beim Anlegen der Liste und beim Annehmen einer Einladung).
  • Nur wenn sich das nicht ermitteln laesst - bestehende Mitgliedschaften von vor dieser Story haben kein Beitrittsdatum -, entscheidet das Alphabet: das Mitglied, dessen Anzeigename zuerst kommt (Gross-/Kleinschreibung egal; bei gleichem Namen das zuerst angelegte Konto).
  • Gemischter Fall: Mitglieder ohne Beitrittsdatum sind nachweislich vor allen Mitgliedern mit Datum beigetreten und gehen deshalb vor; untereinander entscheidet bei ihnen das Alphabet. Unter Mitgliedern mit Datum entscheidet das frueheste Datum.
  • Listen ohne weitere Mitglieder werden wie bisher geloescht.
  • Die Inhalte der Liste bleiben vollstaendig erhalten (Eintraege, Kategorien, Labels, Kommentare, Verlauf, Einladungen der anderen). Beitraege des geloeschten Nutzers bleiben stehen; wo sein Name angezeigt wurde, erscheint wie bereits heute "Ein ehemaliges Mitglied". Zuweisungen an den geloeschten Nutzer werden aufgehoben.
  • Der neue Besitzer wird per Benachrichtigung (In-App, und E-Mail/Push je nach seinen Einstellungen) informiert, dass er jetzt Besitzer der Liste ist.
  • Verbundene Mitglieder sehen den Besitzerwechsel ohne Fehler; die Liste verschwindet bei ihnen nicht.
  • Die Bestaetigungsdialoge bei der Kontoloeschung (eigene und Admin) sagen korrekt, was passiert: eigene, nicht geteilte Listen werden geloescht, geteilte Listen gehen an ein anderes Mitglied ueber.
  • Die Bestaetigungs-E-Mail an den geloeschten Nutzer formuliert das ebenfalls korrekt (nicht mehr "all associated data ... deleted", soweit geteilte Listen weiterbestehen).

Out of scope for this story:

  • Manuelles Weitergeben des Besitzes fuer Einkaufsliste/Vorratsschrank/Masterpackliste (bei To-Do-Listen existiert es bereits) - moegliche eigene Story ("Option 3" aus der Diskussion).
  • Mehrere Besitzer pro Liste bzw. einstellbares "alle sind Admins" ("Option 2" aus der Diskussion).
  • Nutzer inaktiv schalten (#221) - dort bleiben die Listen ohnehin erhalten.

Open questions: (escalate to human if unanswered)

  • Welches Mitglied wird neuer Besitzer? Entschieden vom Menschen (2026-09-29): immer das Mitglied, das als erstes beigetreten ist; nur wenn das nicht ermittelbar ist (Altbestand ohne Beitrittsdatum), das Alphabet - siehe Acceptance Criteria.

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

## Story: Automatische Besitz-Nachfolge statt Loeschung geteilter Listen **As a** Mitglied einer geteilten Liste, **I want to** dass die Liste erhalten bleibt, wenn das Konto ihres Besitzers geloescht wird (selbst oder durch den Admin), und automatisch ein verbleibendes Mitglied Besitzer wird, **so that** eine gemeinsam genutzte Liste (z. B. die Familien-Einkaufsliste) nicht ohne Vorwarnung fuer alle verschwindet, nur weil eine Person ihr Konto loescht. Hintergrund (Diskussion mit dem Menschen, 2026-09-29): Erwogen wurde, beim Teilen alle Mitglieder zu Admins zu machen. Verworfen zugunsten dieser Loesung, weil "alle sind Admins" jedem Mitglied das Loeschen der Liste fuer alle erlauben wuerde und das eigentliche Problem - Datenverlust beim Loeschen - trotzdem nicht loest. Diese Story aendert das Rechtemodell (ein Besitzer, sonst Mitglieder) nicht. Ist-Stand: `EraseUserAccountCommandHandler` (gemeinsam genutzt von der eigenen Kontoloeschung und der Admin-Loeschung aus #206) loescht **alle** Listen, deren Besitzer der Nutzer ist - To-Do-Listen, Einkaufslisten (und damit die daran haengenden Vorratsschraenke) und Masterpacklisten - auch wenn sie mit anderen geteilt sind. Die anderen Mitglieder verlieren sie komplett. **Acceptance criteria:** - [ ] Wird ein Konto geloescht (selbst oder durch den Admin), bleibt jede Liste, deren Besitzer es war und die noch mindestens ein weiteres Mitglied hat, erhalten; ein verbleibendes Mitglied wird automatisch Besitzer. - [ ] Gilt fuer alle Listentypen mit Besitzer: To-Do-Liste (inkl. priorisierte Liste), Einkaufsliste, Masterpackliste. Ein Vorratsschrank bleibt zusammen mit seiner verknuepften Einkaufsliste erhalten und geht mit ihr an denselben neuen Besitzer. - [ ] Neuer Besitzer wird das verbleibende Mitglied, das als erstes der Liste beigetreten ist. Dafuer wird ab jetzt bei jeder neuen Mitgliedschaft das Beitrittsdatum gespeichert (auch beim Anlegen der Liste und beim Annehmen einer Einladung). - [ ] Nur wenn sich das nicht ermitteln laesst - bestehende Mitgliedschaften von vor dieser Story haben kein Beitrittsdatum -, entscheidet das Alphabet: das Mitglied, dessen Anzeigename zuerst kommt (Gross-/Kleinschreibung egal; bei gleichem Namen das zuerst angelegte Konto). - [ ] Gemischter Fall: Mitglieder ohne Beitrittsdatum sind nachweislich vor allen Mitgliedern mit Datum beigetreten und gehen deshalb vor; untereinander entscheidet bei ihnen das Alphabet. Unter Mitgliedern mit Datum entscheidet das frueheste Datum. - [ ] Listen ohne weitere Mitglieder werden wie bisher geloescht. - [ ] Die Inhalte der Liste bleiben vollstaendig erhalten (Eintraege, Kategorien, Labels, Kommentare, Verlauf, Einladungen der anderen). Beitraege des geloeschten Nutzers bleiben stehen; wo sein Name angezeigt wurde, erscheint wie bereits heute "Ein ehemaliges Mitglied". Zuweisungen an den geloeschten Nutzer werden aufgehoben. - [ ] Der neue Besitzer wird per Benachrichtigung (In-App, und E-Mail/Push je nach seinen Einstellungen) informiert, dass er jetzt Besitzer der Liste ist. - [ ] Verbundene Mitglieder sehen den Besitzerwechsel ohne Fehler; die Liste verschwindet bei ihnen nicht. - [ ] Die Bestaetigungsdialoge bei der Kontoloeschung (eigene und Admin) sagen korrekt, was passiert: eigene, nicht geteilte Listen werden geloescht, geteilte Listen gehen an ein anderes Mitglied ueber. - [ ] Die Bestaetigungs-E-Mail an den geloeschten Nutzer formuliert das ebenfalls korrekt (nicht mehr "all associated data ... deleted", soweit geteilte Listen weiterbestehen). **Out of scope for this story:** - Manuelles Weitergeben des Besitzes fuer Einkaufsliste/Vorratsschrank/Masterpackliste (bei To-Do-Listen existiert es bereits) - moegliche eigene Story ("Option 3" aus der Diskussion). - Mehrere Besitzer pro Liste bzw. einstellbares "alle sind Admins" ("Option 2" aus der Diskussion). - Nutzer inaktiv schalten (#221) - dort bleiben die Listen ohnehin erhalten. **Open questions:** (escalate to human if unanswered) - ~~Welches Mitglied wird neuer Besitzer?~~ **Entschieden vom Menschen (2026-09-29): immer das Mitglied, das als erstes beigetreten ist; nur wenn das nicht ermittelbar ist (Altbestand ohne Beitrittsdatum), das Alphabet** - siehe Acceptance Criteria. --- Als Backlog-Item vom Nutzer eingereicht (per Chat, nicht im laufenden Loop-Zyklus geclaimt).
lena commented 2026-09-29 11:16:01 +02:00
Author
Collaborator
Copy link

Offene Frage vom Menschen beantwortet (2026-09-29): Neuer Besitzer wird das Mitglied, das am laengsten dabei ist. Acceptance Criteria entsprechend ergaenzt.

Offene Frage vom Menschen beantwortet (2026-09-29): Neuer Besitzer wird das Mitglied, das am laengsten dabei ist. Acceptance Criteria entsprechend ergaenzt.
lena commented 2026-09-29 11:19:50 +02:00
Author
Collaborator
Copy link

Regel geaendert durch den Menschen (2026-09-29): Neuer Besitzer wird das verbleibende Mitglied, dessen Anzeigename im Alphabet zuerst kommt (Gross-/Kleinschreibung egal, bei gleichem Namen das aeltere Konto). Ersetzt die vorherige Regel "am laengsten dabei" - damit entfaellt auch das Speichern eines Beitrittsdatums.

Regel geaendert durch den Menschen (2026-09-29): Neuer Besitzer wird das verbleibende Mitglied, dessen Anzeigename im Alphabet zuerst kommt (Gross-/Kleinschreibung egal, bei gleichem Namen das aeltere Konto). Ersetzt die vorherige Regel "am laengsten dabei" - damit entfaellt auch das Speichern eines Beitrittsdatums.
lena commented 2026-09-29 11:26:32 +02:00
Author
Collaborator
Copy link

Regel final festgelegt durch den Menschen (2026-09-29): Neuer Besitzer wird immer das Mitglied, das als erstes beigetreten ist (Beitrittsdatum wird ab jetzt gespeichert). Nur wenn das nicht ermittelbar ist - Mitgliedschaften aus der Zeit vor dieser Story haben kein Datum -, entscheidet das Alphabet des Anzeigenamens. Mitglieder ohne Datum gehen vor Mitgliedern mit Datum, da sie nachweislich frueher beigetreten sind. Ersetzt die beiden vorherigen Kommentare.

Regel final festgelegt durch den Menschen (2026-09-29): Neuer Besitzer wird immer das Mitglied, das als erstes beigetreten ist (Beitrittsdatum wird ab jetzt gespeichert). Nur wenn das nicht ermittelbar ist - Mitgliedschaften aus der Zeit vor dieser Story haben kein Datum -, entscheidet das Alphabet des Anzeigenamens. Mitglieder ohne Datum gehen vor Mitgliedern mit Datum, da sie nachweislich frueher beigetreten sind. Ersetzt die beiden vorherigen Kommentare.
lena self-assigned this 2026-09-30 09:11:38 +02:00
lena commented 2026-09-30 09:11:38 +02:00
Author
Collaborator
Copy link

Claimed (go-Lauf 2026-09-30). Plan: Beitrittsdatum auf allen Mitgliedschafts-Entitaeten (nullable, Migration ohne Backfill) -> Nachfolge-Auswahl nach der finalen Regel vom 2026-09-29 -> EraseUserAccountCommandHandler uebertraegt statt loescht, wenn weitere Mitglieder existieren -> Tests.

Claimed (go-Lauf 2026-09-30). Plan: Beitrittsdatum auf allen Mitgliedschafts-Entitaeten (nullable, Migration ohne Backfill) -> Nachfolge-Auswahl nach der finalen Regel vom 2026-09-29 -> EraseUserAccountCommandHandler uebertraegt statt loescht, wenn weitere Mitglieder existieren -> Tests.
lena commented 2026-09-30 10:43:35 +02:00
Author
Collaborator
Copy link

Erledigt (Commits 53887091, 98d99e37, e641abf2, 731e4f92, 7b53bd75; CI-Lauf 144 komplett gruen).

Umfang:

  • Wird ein Konto geloescht (selbst oder durch den Admin), bleiben Listen mit weiteren Mitgliedern erhalten - To-do-Listen (inkl. priorisierte), Einkaufslisten (samt ihrer Vorratsschraenke) und Masterpacklisten. Nur Listen ohne weitere Mitglieder werden wie bisher geloescht.
  • Nachfolge-Regel (ListOwnerSuccession) wie am 2026-09-29 entschieden: wer als erstes beigetreten ist; Mitgliedschaften ohne Datum zuerst, unter ihnen das Alphabet (Gross-/Kleinschreibung egal, bei gleichem Namen das aeltere Konto). Beitrittsdatum: neue Spalte JoinedAt fuer Einkaufs- und Masterpacklisten (ohne Backfill); To-do-Listen nutzen das seit #157 vorhandene CreatedAt (dessen Backfill-Zeitstempel fuer Altbestand fuehrt ueber den Gleichstand automatisch zum Alphabet).
  • Inhalte bleiben komplett (alle Nutzer-Verweise in Listeninhalten sind ON DELETE SET NULL): Beitraege des geloeschten Nutzers bleiben als "ehemaliges Mitglied", seine Zuweisungen werden aufgehoben.
  • Neuer Besitzer bekommt eine In-App-Benachrichtigung (neue Art BecameListOwner) plus Push; bei To-do-Listen zusaetzlich eine E-Mail, wenn er fuer diese Liste E-Mail-Benachrichtigungen aktiviert hat (die einzige existierende E-Mail-Einstellung - Einkaufs-/Packlisten haben keine). Die Sidebar des neuen Besitzers laedt die Listen beim Eintreffen der Benachrichtigung neu, damit die Besitzer-Optionen sofort erscheinen.
  • Beide Loesch-Dialoge (eigenes Konto, Admin) und die Bestaetigungs-E-Mail beschreiben jetzt korrekt, dass geteilte Listen weitergegeben werden.

Entscheidungen, die ueber die AC hinausgehen:

  • Aktive Mitglieder werden deaktivierten (#221) vorgezogen. Bleiben nur deaktivierte, geht die Liste trotzdem an einen von ihnen statt geloescht zu werden (reaktivierbar, Daten bleiben).
  • Der Benachrichtigungstext nennt den Namen des geloeschten Nutzers bewusst nicht (Loeschung soll ihn nicht in fremden Benachrichtigungen weiterleben lassen).

Nebenbei behoben:

  • 202359b1: Push fuer Einkaufs-/Vorrats-/Packlisten-Benachrichtigungen ist nie angekommen (Absturz bei fehlender To-do-Listen-ID) - fuer die neue Benachrichtigung noetig.
  • cd3802e6: Regression aus #220 - nach dem Aendern der Standardliste oeffnete der naechste Start noch die alte (liess die default-list-e2e in Lauf 142/143 flackern).

Tests: 8 Unit-Tests fuer die Nachfolge-Regel, 5 neue Handler-Tests (To-do mit Inhalten/Zuweisung/Kommentar, Einkaufsliste mit Vorratsschrank, Masterpackliste undatiert-vor-datiert, E-Mail nur bei aktivierter Einstellung, Bestaetigungs-E-Mail), Push-Test, Frontend-Tests fuer Dialoge und Listen-Neuladen, Regressionstest fuer die Standardliste. Zusaetzlich live im Review-Container geprueft (Mitglied B wird nach Loeschung von A Besitzer und erhaelt die Benachrichtigung). Security-Review ohne Befund.

Erledigt (Commits 53887091, 98d99e37, e641abf2, 731e4f92, 7b53bd75; CI-Lauf 144 komplett gruen). **Umfang:** - Wird ein Konto geloescht (selbst oder durch den Admin), bleiben Listen mit weiteren Mitgliedern erhalten - To-do-Listen (inkl. priorisierte), Einkaufslisten (samt ihrer Vorratsschraenke) und Masterpacklisten. Nur Listen ohne weitere Mitglieder werden wie bisher geloescht. - Nachfolge-Regel (`ListOwnerSuccession`) wie am 2026-09-29 entschieden: wer als erstes beigetreten ist; Mitgliedschaften ohne Datum zuerst, unter ihnen das Alphabet (Gross-/Kleinschreibung egal, bei gleichem Namen das aeltere Konto). Beitrittsdatum: neue Spalte `JoinedAt` fuer Einkaufs- und Masterpacklisten (ohne Backfill); To-do-Listen nutzen das seit #157 vorhandene `CreatedAt` (dessen Backfill-Zeitstempel fuer Altbestand fuehrt ueber den Gleichstand automatisch zum Alphabet). - Inhalte bleiben komplett (alle Nutzer-Verweise in Listeninhalten sind ON DELETE SET NULL): Beitraege des geloeschten Nutzers bleiben als "ehemaliges Mitglied", seine Zuweisungen werden aufgehoben. - Neuer Besitzer bekommt eine In-App-Benachrichtigung (neue Art `BecameListOwner`) plus Push; bei To-do-Listen zusaetzlich eine E-Mail, wenn er fuer diese Liste E-Mail-Benachrichtigungen aktiviert hat (die einzige existierende E-Mail-Einstellung - Einkaufs-/Packlisten haben keine). Die Sidebar des neuen Besitzers laedt die Listen beim Eintreffen der Benachrichtigung neu, damit die Besitzer-Optionen sofort erscheinen. - Beide Loesch-Dialoge (eigenes Konto, Admin) und die Bestaetigungs-E-Mail beschreiben jetzt korrekt, dass geteilte Listen weitergegeben werden. **Entscheidungen, die ueber die AC hinausgehen:** - Aktive Mitglieder werden deaktivierten (#221) vorgezogen. Bleiben nur deaktivierte, geht die Liste trotzdem an einen von ihnen statt geloescht zu werden (reaktivierbar, Daten bleiben). - Der Benachrichtigungstext nennt den Namen des geloeschten Nutzers bewusst nicht (Loeschung soll ihn nicht in fremden Benachrichtigungen weiterleben lassen). **Nebenbei behoben:** - 202359b1: Push fuer Einkaufs-/Vorrats-/Packlisten-Benachrichtigungen ist nie angekommen (Absturz bei fehlender To-do-Listen-ID) - fuer die neue Benachrichtigung noetig. - cd3802e6: Regression aus #220 - nach dem Aendern der Standardliste oeffnete der naechste Start noch die alte (liess die default-list-e2e in Lauf 142/143 flackern). **Tests:** 8 Unit-Tests fuer die Nachfolge-Regel, 5 neue Handler-Tests (To-do mit Inhalten/Zuweisung/Kommentar, Einkaufsliste mit Vorratsschrank, Masterpackliste undatiert-vor-datiert, E-Mail nur bei aktivierter Einstellung, Bestaetigungs-E-Mail), Push-Test, Frontend-Tests fuer Dialoge und Listen-Neuladen, Regressionstest fuer die Standardliste. Zusaetzlich live im Review-Container geprueft (Mitglied B wird nach Loeschung von A Besitzer und erhaelt die Benachrichtigung). Security-Review ohne Befund.
lena 2026-09-30 10:43:35 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear labels   
priority/could

   
priority/must

   
priority/should

   
priority/wont

   
status/blocked

   
status/claimed

   
status/done-migrated

   
type/bug

   
type/feature

   
type/infra

   
type/tech-debt
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lena
1 participant
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
robert/todo#223
No description provided.