mirror of
https://github.com/IT4Change/gradido.git
synced 2025-12-13 07:45:54 +00:00
Ergebnisse aus Architekur-Mtg vom 25.10.2022
This commit is contained in:
Claus-Peter Hübner
parent
f0187c1301
commit
7dceb05424
@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user