diff --git a/docu/RoadMap_2022-2023.md b/docu/RoadMap_2022-2023.md index 26a4ec41e..be3e197bd 100644 --- a/docu/RoadMap_2022-2023.md +++ b/docu/RoadMap_2022-2023.md @@ -13,49 +13,47 @@ - Konzept fertig - Änderungen in Register- und Login-Prozess -3. Passwort-Verschlüsselung +3. Passwort-Verschlüsselung: Refactoring - - Konzept fertig - - Unabhängigkeit von Email erzeugen - - Änderung der User-Email ermöglichen - - Versionierung der verwendeten Verschlüsselungslogik notwendig -4. Contribution-Categories + - Konzept aufteilen in Ausbaustufen + - Altlasten entsorgen + - Versionierung/Typisierung der verwendeten Verschlüsselungslogik notwendig + - DB-Migration auf encryptionType=EMAIL +4. Passwort-Verschlüsselung: Login mit impliziter Neuverschlüsselung + + * Logik der Passwortverschlüsselung auf GradidoID einführen + * bei Login mit encryptionType=Email oder OneTime triggern einer Neuverschlüsselung per GradidoID + * Unabhängigkeit von Email erzeugen + * Änderung der User-Email ermöglichen +5. Contribution-Categories - Bewertung und Kategorisierung von Schöpfungen: Was hat Wer für Wen geleistet? - Regeln auf Categories ermöglichen - Konzept in Arbeit -5. Statistics / Analysen -6. Subgruppierung / Subcommunities +6. Statistics / Analysen +7. Contribution-Link editieren +8. User-Tagging - - **einfacher Ansatz:** innerhalb der existierenden Community gibt es Untergruppierungen, sprich SubCommunities + - Eine UserTag dient zur einfachen Gruppierung gleichgesinnter oder örtlich gebundener User + - Motivation des User-Taggings: bilden kleinerer lokaler User-Gruppen und jeder kennt jeden + - Einführung einer UserTaggings-Tabelle und eine User-UserTaggings-Zuordnungs-Tabelle + - Ein Moderator kann im AdminInterface die Liste der UserTags pflegen - - Einführung eine Community-Tabelle - - In der Community-Tabelle gibt es zunächst eine Haupt-Community, die mehrere Sub-Communities haben kann - - ein User ist in der Haupt-Community unique, kann aber in mehreren SubCommunities sein - - Eine SubCommunity dient zur einfachen Gruppierung gleichgesinnter oder örtlich gebundener User - - Eine SubCommunity hat eigene Moderatoren - - Motivation einer SubCommunity: kleine lokale Gruppen und jeder kennt jeden - - **ToDos**: - - DB-Migration für Community-Tabelle, User-SubCommunity-Zuordnungen, UserRights-Tabelle - - Berechtigungen für SubCommunities - - Register- und Login-Prozess für SubCommunity-Anmeldung anpassen - - Auswahl-Box einer SubCommunity - - createUser mit Zuordnung zur ausgewählten SubCommunity - - Schöpfungsprozess auf angemeldete SubCommunity anpassen - - "Beitrag einreichen"-Dialog auf angemeldete SubCommunity anpassen - - "meine Beiträge zum Gemeinwohl" mit Filter auf angemeldete SubCommunity anpassen - - "Gemeinschaft"-Dialog auf angemeldete SubCommunity anpassen - - "Mein Profil"-Dialog auf SubCommunities anpassen - - Umzug-Service in andere SubCommunity - - Löschen der Mitgliedschaft zu angemeldeter SubCommunity (Deaktivierung der Zuordnung "User-SubCommunity") - - "Senden"-Dialog mit SubCommunity-Auswahl - - "Transaktion"-Dialog mit Filter auf angemeldeter SubCommunity - - AdminInterface auf angemeldete SubCommunity anpassen - - "Übersicht"-Dialog mit Filter auf angemeldete SubCommunity - - "Nutzersuche"-Dialog mit Filter auf angemeldete SubCommunity - - "Mehrfachschöpfung"-Dialog mit Filter auf angemeldete SubComunity - - Subject/Texte/Footer/... der Email-Benachrichtigungen auf angemeldete SubCommunity anpassen -7. User-Beziehungen und Favoritenverwaltung + - neues TAG anlegen + - vorhandenes TAG umbenennen + - ein TAG löschen, sofern kein User mehr diesem TAG zugeordnet ist + - Will ein User ein TAG zugeordnet werden, so kann dies nur ein Moderator im AdminInterface tun + - Ein Moderator kann im AdminInterface + + - ein TAG einem User zuordnen + - ein TAG von einem User entfernen + - wichtige UseCases: + + - Zuordnung eines Users zu einem TAG durch einen Moderator + - TAG spezifische Schöpfung + - User muss für seinen Beitrag ein TAG auswählen können, dem er zuvor zugeordnet wurde + - TAG-Moderator kann den Beitrag bestätigen, weil er den User mit dem TAG (persönlich) kennt +9. User-Beziehungen und Favoritenverwaltung - User-User-Zuordnung - aus Tx-Liste die aktuellen Favoriten ermitteln @@ -65,67 +63,104 @@ - Gruppierung - Community-übergreifend - User-Beziehungen -8. technische Ablösung der Email und Ersatz durch GradidoID +10. technische Ablösung der Email und Ersatz durch GradidoID - * APIs / Links / etc mit Email anpassen, so dass keine Email mehr verwendet wird - * Email soll aber im Aussen für User optional noch verwendbar bleiben - * Intern erfolgt aber auf jedenfall ein Mapping auf GradidoID egal ob per Email oder Alias angefragt wird -9. Zeitzone + * APIs / Links / etc mit Email anpassen, so dass keine Email mehr verwendet wird + * Email soll aber im Aussen für User optional noch verwendbar bleiben + * Intern erfolgt aber auf jedenfall ein Mapping auf GradidoID egal ob per Email oder Alias angefragt wird +11. Zeitzone - - User sieht immer seine Locale-Zeit und Monate - - Admin sieht immer UTC-Zeit und Monate - - wichtiges Kriterium für Schöpfung ist das TargetDate ( heißt in DB contributionDate) - - Berechnung der möglichen Schöpfungen muss somit auf dem TargetDate der Schöpfung ermittelt werden! **(Ist-Zustand)** - - Kann es vorkommen, dass das TargetDate der Contribution vor dem CreationDate der TX liegt? Ja - - Beispiel: User in Tokyo Locale mit Offest +09:00 + - User sieht immer seine Locale-Zeit und Monate + - Admin sieht immer UTC-Zeit und Monate + - wichtiges Kriterium für Schöpfung ist das TargetDate ( heißt in DB contributionDate) + - Berechnung der möglichen Schöpfungen muss somit auf dem TargetDate der Schöpfung ermittelt werden! **(Ist-Zustand)** + - Kann es vorkommen, dass das TargetDate der Contribution vor dem CreationDate der TX liegt? Ja + - Beispiel: User in Tokyo Locale mit Offest +09:00 - - aktiviert Contribution-Link mit Locale: 01.11.2022 07:00:00+09:00 = TargetDate = Zieldatum der Schöpfung - - die Contribution wird gespeichert mit + - aktiviert Contribution-Link mit Locale: 01.11.2022 07:00:00+09:00 = TargetDate = Zieldatum der Schöpfung + - die Contribution wird gespeichert mit - - creationDate=31.10.2022 22:00:00 UTC - - contributionDate=01.11.2022 07:00:00 - - (neu) clientRequestTime=01.11.2022 07:00:00+09:00 - - durch automatische Bestätigung und sofortiger Transaktion wird die TX gespeichert mit + - creationDate=31.10.2022 22:00:00 UTC + - contributionDate=01.11.2022 07:00:00 + - (neu) clientRequestTime=01.11.2022 07:00:00+09:00 + - durch automatische Bestätigung und sofortiger Transaktion wird die TX gespeichert mit - - creationDate=31.10.2022 22:00:00 UTC - - **zwingende Prüfung aller Requeste: auf -12h <= ClientRequestTime <= +12h** - - zur Analyse und Problemverfolgung von Contributions immer original ClientRequestTime mit Offset in DB speichern - - Beispiel für täglichen Contribution-Link während des Monats: + - creationDate=31.10.2022 22:00:00 UTC + - **zwingende Prüfung aller Requeste: auf -12h <= ClientRequestTime <= +12h** - - 17.10.2022 22:00 +09:00 => 17.10.2022 UTC: 17.10.2022 13:00 UTC => 17.10.2022 - - 18.10.2022 02:00 +09:00 => 18.10.2022 UTC: 17.10.2022 17:00 UTC => 17.10.2022 !!!! darf nicht weil gleicher Tag !!! - - Beispiel für täglichen Contribution-Link am Monatswechsel: + - Prüfung auf Sommerzeiten und exotische Länder beachten + - + - zur Analyse und Problemverfolgung von Contributions immer original ClientRequestTime mit Offset in DB speichern + - Beispiel für täglichen Contribution-Link während des Monats: - - 31.10.2022 22:00 +09:00 => 31.10.2022 UTC: 31.10.2022 15:00 UTC => 31.10.2022 - - 01.11.2022 07:00 +09:00 => 01.11.2022 UTC: 31.10.2022 22:00 UTC => 31.10.2022 !!!! darf nicht weil gleicher Tag !!! -10. Layout -11. Manuelle User-Registrierung für Admin + - 17.10.2022 22:00 +09:00 => 17.10.2022 UTC: 17.10.2022 13:00 UTC => 17.10.2022 + - 18.10.2022 02:00 +09:00 => 18.10.2022 UTC: 17.10.2022 17:00 UTC => 17.10.2022 !!!! darf nicht weil gleicher Tag !!! + - Beispiel für täglichen Contribution-Link am Monatswechsel: + + - 31.10.2022 22:00 +09:00 => 31.10.2022 UTC: 31.10.2022 15:00 UTC => 31.10.2022 + - 01.11.2022 07:00 +09:00 => 01.11.2022 UTC: 31.10.2022 22:00 UTC => 31.10.2022 !!!! darf nicht weil gleicher Tag !!! +12. Layout +13. Lastschriften-Link +14. Registrierung mit Redeem-Link: bei inaktivem Konto keine Buchung möglich + + 1. speichern des Links zusammen mit OptIn-Code + 2. +15. Manuelle User-Registrierung für Admin - soll am 10.12.2022 für den Tag bei den Galliern produktiv sein -12. Dezentralisierung / Federation +16. Dezentralisierung / Federation - Hyperswarm + + - funktioniert schon im Prototyp + - alle Instanzen finden sich gegenseitig + - ToDo: + - Infos aus HyperSwarm in der Community speichern + - Prüfung ob neue mir noch unbekannte Community hinzugekommen ist? + - Triggern der Authentifizierungs- und Autorisierungs-Handshake für neue Community - Authentifizierungs- und Autorisierungs-Handshake - Inter-Community-Communication + - **ToDos**: + + - DB-Migration für Community-Tabelle, User-Community-Zuordnungen, UserRights-Tabelle + - Berechtigungen für Communities + - Register- und Login-Prozess für Community-Anmeldung anpassen + + - Auswahl-Box einer Community + - createUser mit Zuordnung zur ausgewählten Community + - Schöpfungsprozess auf angemeldete Community anpassen + + - "Beitrag einreichen"-Dialog auf angemeldete Community anpassen + - "meine Beiträge zum Gemeinwohl" mit Filter auf angemeldete Community anpassen + - "Gemeinschaft"-Dialog auf angemeldete Community anpassen + - "Mein Profil"-Dialog auf Communities anpassen + + - Umzug-Service in andere Community + - Löschen der Mitgliedschaft zu angemeldeter Community (Deaktivierung der Zuordnung "User-Community") + - "Senden"-Dialog mit Community-Auswahl + - "Transaktion"-Dialog mit Filter auf angemeldeter Community + - AdminInterface auf angemeldete Community anpassen + + - "Übersicht"-Dialog mit Filter auf angemeldete Community + - "Nutzersuche"-Dialog mit Filter auf angemeldete Community + - "Mehrfachschöpfung"-Dialog mit Filter auf angemeldete Comunity + - Subject/Texte/Footer/... der Email-Benachrichtigungen auf angemeldete Community anpassen ## Priorisierung -1. capturing alias -2. Manuelle User-Registrierung für Admin (10.12.2022) **Konzeption!!**! -3. Zeitzone -4. User-Beziehungen und Favoritenverwaltung +1. Contribution-Link editieren (vlt schon im vorherigen Bugfix-Release Ende Okt. 2022 fertig) +2. Passwort-Verschlüsselung: Refactoring **Konzeption fertig!!**! +3. Manuelle User-Registrierung für Admin (10.12.2022) **Konzeption ongoing!!**! +4. Passwort-Verschlüsselung: implizite Login-Neuverschlüsselung **Konzeption fertig!!**! 5. Layout -6. Passwort-Verschlüsselung -7. Subgruppierung / Subcommunities (einfacher Ansatz) -8. Contribution-Categories -9. backend access layer -10. Statistics / Analysen -11. technische Ablösung der Email und Ersatz durch GradidoID -12. Dezentralisierung / Federation - -## Zeitleiste - - - - -![img](./graphics/RoadMap2022-2023.png) +6. Zeitzone +7. Dezentralisierung / Federation +8. capturing alias **Konzeption fertig!!**! +9. Registrierung mit Redeem-Link: bei inaktivem Konto keine Buchung möglich +10. Subgruppierung / User-Tagging (einfacher Ansatz) +11. backend access layer +12. technische Ablösung der Email und Ersatz durch GradidoID +13. User-Beziehungen und Favoritenverwaltung +14. Lastschriften-Link +15. Contribution-Categories +16. Statistics / Analysen