From b9c73c2cf77f2445c2bd86ef6efdce8ad2377e36 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Claus-Peter=20H=C3=BCbner?= Date: Tue, 18 Oct 2022 23:12:27 +0200 Subject: [PATCH] first draft --- docu/RoadMap_2022-2023.md | 137 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 docu/RoadMap_2022-2023.md diff --git a/docu/RoadMap_2022-2023.md b/docu/RoadMap_2022-2023.md new file mode 100644 index 000000000..8a29fcbb5 --- /dev/null +++ b/docu/RoadMap_2022-2023.md @@ -0,0 +1,137 @@ +# Roadmap 2022 / 2023 + +## unsortierte Sammlung von Themen + +1. backend access layer + + - Refactoring der Resolver-Klassen + - Daten-Zugriffschicht zur Kapselung der DB-Schicht + - Transfer-Datenmodel zum Austausch von Daten zwischen den Schichten + - technisches Transaktion-Handling und Lösung von Deadlocks + - Konzept in Arbeit +2. capturing alias + + - Konzept fertig + - Änderungen in Register- und Login-Prozess +3. Passwort-Verschlüsselung + + - Konzept fertig + - Unabhängigkeit von Email erzeugen + - Änderung der User-Email ermöglichen + - Versionierung der verwendeten Verschlüsselungslogik notwendig +4. 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 + + - **einfacher Ansatz:** innerhalb der existierenden Community gibt es Untergruppierungen, sprich SubCommunities + + - 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 + - **komplexer Ansatz** + + - DB-Migration + + - Community-Tabelle mit Eintrag für Haupt-Community + - Community-User Zuordnungstabelle + - Account-Tabelle + - Account-User Zuordnungstabelle + - SubCommunity-Verwaltung + + - Neuanlage + - Änderungen + - Berechtigungen (Admin, Moderator, User, ...) + - Konten für 2te und 3te Schöpfung + - User-Community-Verwaltung + + - Zuordnung zu einer SubCommunity bei Register bzw Login + - Umzug in andere SubCommunity + - Eindeutigkeit Community-übergreifend? + - User-Account-Verwaltung + + - Berechtigung auf Accounts anderer User (Treuhander) + - Transaktions- und Schöpfungslogik auf Multi-Community anpassen +7. User-Beziehungen und Favoritenverwaltung + + - User-User-Zuordnung + - aus Tx-Liste die aktuellen Favoriten ermitteln + - Verwaltung von Zuordnungen + - Auswahl + - Berechtigungen + - Gruppierung + - Community-übergreifend + - User-Beziehungen +8. technische Ablösung der Email und Ersatz durch GradidoID +9. 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 + - Berechnung der möglichen Schöpfungen muss somit auf dem TargetDate der Schöpfung ermittelt werden! + - Kann es vorkommen, dass das TargetDate der Contribution vor dem CreationDate der TX liegt? + - Contribution-Link aktiviert in Tokyo am Locale: 01.11.2022 07:00:00+09:00 = TargetDate = Zieldatum der Schöpfung + - Gebucht wird die TX mit creationDate=31.10.2022 22:00:00 UTC, + - die Schöpfung hat creationDate=31.10.2022 22:00:00 UTC und contributionDate=01.11.2022 07:00:00 und neu contributionOffset=+09:00 + - **Prüfung auf -12h <= ClientRequestTime <= +12h** + - original ClientRequestTime in DB speichern + - 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 !!! + - 31.10.2022 22:00 +09:00 => 10.2022 + - 01.11.2022 07:00 +09:00 => 11.2022 +10. Layout +11. Manuelle User-Registrierung für Admin + + 1. 10.12.2022 Tag bei den Galliern +12. Dezentralisierung / Federation + + 1. Hyperswarm + 2. + +## Priorisierung + +1. capturing alias +2. Manuelle User-Registrierung für Admin (10.12.2022) **Konzeption!!**! +3. Zeitzone +4. User-Beziehungen und Favoritenverwaltung +5. Layout +6. Passwort-Verschlüsselung +7. +8. Subgruppierung / Subcommunities (einfacher Ansatz) +9. Contribution-Categories +10. +11. backend access layer +12. +13. Statistics / Analysen +14. +15. technische Ablösung der Email und Ersatz durch GradidoID +16. +17. Dezentralisierung / Federation + +## Zeitleiste