Migration bestehender Einwilligungen führt zu Widerrufen

Alle consents_userconsents haben updated zeitstempel 10:41:45.

Migrationen wurden folgende ausgeführt:

69,providers,0008_verb_remove_providerschema_essential_verbs_and_more,2025-03-26 10:41:44.573375
70,consents,0005_remove_userconsents_provider_schema_and_more,2025-03-26 10:41:50.395621
71,consents,0006_alter_userconsents_verb_group,2025-03-26 10:41:51.087253
72,settings,0001_initial,2025-03-26 10:41:51.139965

Dies sieht in der Studierendenansicht falsch aus:

Alle Einwilligungen sind hier am 26.03.2025 widerrufen.

Ich weiß nicht, wie die Migrationen konzeptionell funktionieren soll, das Ergebnis ergibt für mich so aber wenig Sinn: Wurden hier alle nicht-eingewilligten Einträge widerrufen?

assigned to @benjaminLedel

changed title from Migration bestehender Einwilligungen führt zu widerrufen to Migration bestehender Einwilligungen führt zu Widerrufen

assigned to @LenDigLearn and unassigned @benjaminLedel

mentioned in commit f5e7091c

Ich habe die Migration nochmal durchgesehen - dass da das Datum der Migration beim Widerruf steht, lag daran, dass das Model über model.save() gespeichert wurde. Habe das nun in ein SQL Statement umgeschrieben, damit Django uns da nicht die Daten verändert.

Ansonsten ändern wir den consented-Status des Objekts eigentlich fast nie, vor allem nicht in der Migration, insofern wundert es mich, dass durch die Migration daran etwas verändert worden sein soll.

@martin.ulrich.breuer hast du deine Daten von vor der Migration noch und kannst du sie mit dem aktuellen Code nochmal darauf ausführen? Evtl. wäre es auch hilfreich, vorher und nachher in der DB stichprobenartig bei consents_userconsents-Einträgen zu gucken, ob sich die consented-Spalte verändert.

@LenDigLearn am 17.02 hatte ich dir schonmal einen Dump geschickt - das dürfte die gleiche DB sein. Würdest du es bei dir mit dem Dump testen?

Ansonsten habe ich von der DB auch tägliche Backups der letzten 2 Wochen (und noch etwas ältere)

Ich habe deine DB eingespielt und zunächst die Anzahl der zugestimmten Einträge gezählt: SELECT COUNT(*) from consents_userconsents WHERE consented=1

Dies ergab eine Anzahl von 115 Zeilen. Nach dem Ausführen der Migrationen waren es immer noch 115. In der Oberfläche sieht es dann recht ähnlich aus, wie in deinem Screenshot:

Dass hier so viele Einträge als "widerrufen" dargestellt werden, liegt letztendlich daran, dass sie vermutlich über das alte Interface (also den alten Wizard) abgelehnt wurden - hier hat sich das Verfahren und Wording ja leicht geändert.

Aktuell und zukünftig gilt eine Zustimmung nur dann, wenn ein Consent-Eintrag für das entsprechende Verb vorliegt und bei diesem sowohl consented als auch active 1 sind. Wenn consented 0 ist, wird dies nun immer als abgelehnt interpretiert, mit dem Update-Datum des Eintrags als Referenz.

Ich würde sagen, die Frage ist, wie viele Daten dieser Art (also alte Ablehnungen, die jetzt inakkurat als "Widerruf" dargestellt werden würden) es in den relevanten Produktivsystemen gibt. Wenn diese besondere Situation nur ältere Testdaten betrifft, würde ich nichts großartig unternehmen.

Wenn es auch "echte" Zustimmungen / Ablehnungen betreffen sollte, sehe ich zwei Möglichkeiten:

1. Wir ändern das Wording dahingehend, dass wir z.B. "du hast [...] widerrufen / abgelehnt" schreiben
2. Wir passen die Migration an, sodass alle Einträge, bei denen consented 0 ist, gelöscht werden

Betrifft das nur Ablehnungen, oder auch nicht-Zustimmungen. Also wenn man einfach gar keine Interaktion mit den Gruppen/Verben hatte? Falls ja: Bei 1. müsste vorher eine Einwilligung da gewesen sein, damit es widerrufen sein kann.

Falls 2 keine Probleme verursacht sehe ich es als bessere variante. Kann inhaltlich unterschieden werden, ob consented 0 ist, oder ein Widerruf stattgefunden hat?

Bei uns zumindest gibt es keine Ablehnungen in Produktivsystemen. @CeEmBe ?