diff --git a/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md b/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md index ab04efc7f..2e74aef4e 100644 --- a/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md +++ b/docu/Concepts/BusinessRequirements/UC_Send_Contribution.md @@ -2,6 +2,18 @@ Die Idee besteht darin, dass ein Administrator eine Contribution mit all seinen Attributen und Regeln im System erfasst. Dabei kann er unter anderem festlegen, ob für diese ein Link oder ein QR-Code generiert und über andere Medien wie Email oder Messenger versendet werden kann. Der Empfänger kann diesen Link bzw QR-Code dann über die Gradido-Anwendung einlösen und bekommt dann den Betrag der Contribution als Schöpfung auf seinem Konto gutgeschrieben. +## Ausbaustufen + +Die beschriebenen Anforderungen werden in mehrere Ausbaustufen eingeteilt. Damit können nach und nach die Dialoge und Businesslogik schrittweise in verschiedene Releases gegossen und ausgeliefert werden. + +### Ausbaustufe 1 + +Diese Ausbaustufe wird gezielt für die "Dokumenta" im Juni 2022 zusammengestellt. Details siehe weiter unten im speziellen Kapitel "Ausbaustufe 1". + +### Ausbaustufe 2 + +Diese Ausbaustufe wird gezielt für die Anforderungen für das Medidationsportal von "Abraham" zusammegestellt. Details siehe weiter unten im speziellen Kapitel "Ausbaustufe 2". + ## Logischer Ablauf Der logische Ablauf für das Szenario "Activity-Confirmation and booking of Creations " wird in der nachfolgenden Grafik dargestellt. Dabei wird links das Szenario der "interactive Confirmation and booking of Creations" und rechts "automatic Confirmation and booking of Creations" dargestellt. Ziel dieser Grafik ist neben der logischen Ablaufsübersicht auch die Gemeinsamkeiten und Unterschiede der beiden Szenarien herauszuarbeiten. @@ -28,11 +40,11 @@ Der Gültigkeitsstart wird als Default mit dem aktuellen Erfassungszeitpunkt vor Wie häufig ein User für diese Contribution eine Schöpfung gutgeschrieben bekommen kann, wird über die Auswahl eines Zyklus - stündlich, 2-stündlich, 4-stündlich, etc. - und innerhalb dieses Zyklus eine Anzahl an Wiederholungen definiert. Voreinstellung sind 1x täglich. -![Zyklus](./image/UC_Send_Contribution_Admin-new ContributionZyklus.png) +![img](./image/UC_Send_Contribution_Admin-new_ContributionZyklus.png) Ob die Contribution über einen versendeten Link bzw. QR-Code geschöpft werden kann, wird mittels der Auswahl "Versenden möglich als" bestimmt. -![send](./image/UC_Send_Contribution_Admin-new ContributionSend.png) +![img](./image/UC_Send_Contribution_Admin-new_ContributionSend.png) Für die Schöpfung der Contribution können weitere Regeln definiert werden: @@ -44,11 +56,11 @@ Für die Schöpfung der Contribution können weitere Regeln definiert werden: ![new](./image/UC_Send_Contribution_Admin-newContribution.png) -### Ausbaustufe-1: +## Ausbaustufe-1: -Die Ausbaustufe-1 wird gezielt auf die Anforderungen der "Dokumenta" im Juni 2022 abgestimmt. +Die Ausbaustufe-1 wird gezielt auf die Anforderungen der "Dokumenta" im Juni 2022 abgestimmt. -#### Contribution-Erfassungsdialog (Adminbereich) +### Contribution-Erfassungsdialog (Adminbereich) Es werden folgende Anforderungen an den Erfassungsdialog einer Contribution gestellt: @@ -64,14 +76,12 @@ Es werden folgende Anforderungen an den Erfassungsdialog einer Contribution gest | VersendenMöglich | - hier wird "als Link / QR-Code" voreingestellt | | alle weiteren Attribute | - entfallen für diese Ausbaustufe
- die GUI-Komponenten können optional schon im Dialog eingebaut und angezeigt werden
- diese GUI-Komponenten müssen wenn sichtbar disabled sein und dürfen damit keine Eingaben entgegen nehmen | - -#### Ablauflogik +### Ablauflogik Für die Ausbaustufe-1 wird gemäß der Beschreibung aus dem Kapitel "Logischer Ablauf" nur die "automatic Confirmation and booking of Creations" umgesetzt. Die interaktive Variante - sprich Ablösung des EloPage Prozesses - mit "interactive Confirmation and booking of Creations" bleibt für eine spätere Ausbaustufe aussen vor. Das Regelwerk in der Businesslogik wird gemäß der reduzierten Contribution-Attribute aus dem Erfassungsdialog, den vordefinierten Initialwerten und der daraus resultierenden Variantenvielfalt vereinfacht. - #### Kriterien "Dokumenta" * Es soll eine "Dokumenta"-Contribution im Admin-Bereich erfassbar sein und in der Datenbank als ContributionLink gespeichert werden. @@ -91,6 +101,45 @@ Das Regelwerk in der Businesslogik wird gemäß der reduzierten Contribution-Att * es erfolgt eine übliche Schöpfungstransaktion nach der Bestätigung der Contribution * die Schöpfungstransaktion schreibt den Betrag der Contribution dem Kontostand des Users gut +## Ausbaustufe-2 + +Die Ausbaustufe-2 wird gezielt auf die Anforderungen zur Anbindung des Meditationsportals von Abraham im Oktober 2022 abgestimmt. + +### Contribution-Erfassungsdialog (Adminbereich) + +Es werden folgende Anforderungen an den Erfassungsdialog einer Contribution gestellt: + +| Attribut | Beschreibung | +| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| GültigBis | - das Datum, wie lange die Contribution gültig und damit einlösbar ist
- für diese Ausbaustufe soll ein offenes Ende möglich sein, daher bleibt dieses Attribut leer | +| Zyklus | - Angabe wie häufig eine Contribution gutgeschrieben werden kann
- als Auswahlliste (Combobox) geplant, aber für diese Ausbaustufe nur mit dem Wert "täglich" vorbelegt | +| Wiederholungen | - Anzahl an Wiederholungen pro Zyklus
- für diese Ausbaustufe wird der Wert "1" vorbelegt -> somit gilt: ein User kann diese Contribution nur 1x täglich einlösen | +| alle weiteren noch nicht vorhandenen Attribute | - entfallen für diese Ausbaustufe
- die GUI-Komponenten können optional schon im Dialog eingebaut und angezeigt werden
- diese GUI-Komponenten müssen wenn sichtbar disabled sein und dürfen damit keine Eingaben entgegen nehmen | + +### Ablauflogik + +Für die Ausbaustufe-2 und der inzwischen umgesetzten Ablösung des "EloPage Contribution Erfassungsprozesses" wird gemäß der Beschreibung aus dem Kapitel "Logischer Ablauf" die "automatic Confirmation and booking of Creations" sowie die interaktive Variante "interactive Confirmation and booking of Creations" mit berücksichtigt. + +Das Regelwerk in der Businesslogik wird gemäß der noch nicht vollumfänglich geplanten Contribution-Attribute aus dem Erfassungsdialog, den vordefinierten Initialwerten und der daraus resultierenden Variantenvielfalt vereinfacht. + +#### Kriterien "Meditationsportal (Abraham)" + +* Es soll eine "GlobalMeditation"-Contribution nur im Admin-Bereich erfassbar sein und in der Datenbank als ContributionLink gespeichert werden. +* Es wird ein offenes Ende als Gesamtlaufzeit dieser Contribution benötigt, was durch ein leeres GültigBis-Datum ausgedrückt bzw. erfasst werden soll. +* Die "Meditationsportal"-Contribution kann von einem User maximal 1x täglich aktiviert werden. Dies wird über die Erfassung des Attributes "Zyklus" = täglich und des Attributes "Wiederholungen" = 1 ermöglicht. +* Ein User kann mit diesem Link nur die Menge an GDDs schöpfen, die in der Contribution als "Betrag" festgelegt ist +* Die "GlobalMeditation"-Contribution kann als Link / QR-Code erzeugt, angezeigt und in die Zwischenablage kopiert werden +* Jeder beliebige User kann den Link / QR-Code aktivieren +* der Link führt auf eine Gradido-Seite, wo der User sich anmelden oder registrieren kann +* mit erfolgreichem Login bzw. Registrierung wird der automatische Bestätigungs- und Schöpfungsprozess getriggert +* es erfolgt eine Überprüfung der definierten Contribution-Regeln für den angemeldeten User: + * Gültigkeit: liegt die Aktivierung im Gültigkeitszeitraum der Contribution + * Zyklus und WIederholungen: bei einem Zyklus-Wert = "täglich" und einem Wiederholungswert = 1 darf der User den Betrag dieser Contribution nur einmal am Tag schöpfen. Es gibt keine Überprüfung eines zeitlichen Mindestabstandes zwischen zwei Schöpfungen an zwei aufeinanderfolgenden Tagen. + * max. schöpfbarer Gradido-Betrag pro Monat: wenn der Betrag der Contribution plus der Betrag, den der User in diesem Monat schon geschöpft hat, den maximal schöpfbaren Betrag pro Monat von 1000 GDD übersteigt, dann wird die Schöpfung dieser Contribution abgelehnt +* mit erfolgreich durchlaufenen Regelprüfungen wird ein "besätigter" aber "noch nicht gebuchten" Eintrag in der "Contributions"-Tabelle erzeugt +* ein "bestätigter" aber "noch nicht gebuchter" "Contributions"-Eintrag stößt eine Schöpfungstransaktion für den User an +* es erfolgt eine übliche Schöpfungstransaktion mit automatischer Bestätigung der Contribution +* die Schöpfungstransaktion schreibt den Betrag der Contribution dem Kontostand des Users gut ## Datenbank-Modell @@ -100,34 +149,36 @@ Das nachfolgende Bild zeigt das Datenmodell vor der Einführung und Migration au ![Datenbankmodell](./image/DB-Diagramm_20220518.png) -### Datenbank-Änderungen +### Ausbaustufe-1 + +#### Datenbank-Änderungen Die Datenbank wird in ihrer vollständigen Ausprägung trotz Ausbaustufe-1 wie folgt beschrieben umgesetzt. -#### neue Tabellen +##### neue Tabellen -##### contribution_links - Tabelle +###### contribution_links - Tabelle | Name | Typ | Nullable | Default | Kommentar | | ------------------------------- | ------------ | :------: | :------------: | -------------------------------------------------------------------------------------------------------------------------------------- | | id | INT UNSIGNED | NOT NULL | auto increment | PrimaryKey | -| name | varchar(100) | NOT NULL | | unique Name | -| description | varchar(255) | | | | +| name | varchar(100) | NOT NULL | | unique Name | +| description | varchar(255) | | | | | valid_from | DATETIME | NOT NULL | NOW | | -| valid_to | DATETIME | | NULL | | -| amount | DECIMAL | NOT NULL | | | +| valid_to | DATETIME | | NULL | | +| amount | DECIMAL | NOT NULL | | | | cycle | ENUM | NOT NULL | ONCE | ONCE, HOUR, 2HOUR, 4HOUR, 8HOUR, HALFDAY, DAY, 2DAYS, 3DAYS, 4DAYS, 5DAYS, 6DAYS, WEEK, 2WEEKS, MONTH, 2MONTH, QUARTER, HALFYEAR, YEAR | | max_per_cycle | INT UNSIGNED | NOT NULL | 1 | | -| max_amount_per_month | DECIMAL | | NULL | | -| total_max_count_of_contribution | INT UNSIGNED | | NULL | | -| max_account_balance | DECIMAL | | NULL | | -| min_gap_hours | INT UNSIGNED | | NULL | | -| created_at | DATETIME | | NOW | | -| deleted_at | DATETIMEBOOL | | NULL | | -| code | varchar(24) | | NULL | | -| link_enabled | BOOL | | NULL | | +| max_amount_per_month | DECIMAL | | NULL | | +| total_max_count_of_contribution | INT UNSIGNED | | NULL | | +| max_account_balance | DECIMAL | | NULL | | +| min_gap_hours | INT UNSIGNED | | NULL | | +| created_at | DATETIME | | NOW | | +| deleted_at | DATETIMEBOOL | | NULL | | +| code | varchar(24) | | NULL | | +| link_enabled | BOOL | | NULL | | -##### contributions -Tabelle +###### contributions -Tabelle | Name | Typ | Nullable | Default | Kommentar | | --------------------- | ------------ | -------- | -------------- | -------------------------------------------------------------------------------- | @@ -145,9 +196,9 @@ Die Datenbank wird in ihrer vollständigen Ausprägung trotz Ausbaustufe-1 wie f | booked_at | DATETIME | | NULL | date, when the system has booked the amount of the activity on the users account | | deleted_at | DATETIME | | NULL | soft delete | -#### zu migrierende Tabellen +##### zu migrierende Tabellen -##### Tabelle admin_pending_creations +###### Tabelle admin_pending_creations Diese Tabelle wird im Rahmen dieses UseCase migriert in die neue Tabelle contributions... @@ -168,6 +219,14 @@ Diese Tabelle wird im Rahmen dieses UseCase migriert in die neue Tabelle contrib ...und kann nach Übernahme der Daten in die neue Tabelle gelöscht werden oder es erfolgen die Änderungen sofort auf der Ursprungstabelle. -### Zielmodell +#### Zielmodell ![Contributions-DB](./image/DB-Diagramm_Contributions.png) + +### Ausbaustufe-2 + +Für die Ausbaustufe-2 sind keine Datenbank-Änderungen notwendig. Gemäß dem Zielmodell sind alle nontwndigen Tabellen und Attribute schon vorhanden. + +#### Zielmodell + +![img](./image/DB-Diagramm_Contributions_Stufe_2.png) diff --git a/docu/Concepts/BusinessRequirements/image/DB-Diagramm_Contributions_Stufe_2.png b/docu/Concepts/BusinessRequirements/image/DB-Diagramm_Contributions_Stufe_2.png new file mode 100644 index 000000000..eee7fa23f Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/DB-Diagramm_Contributions_Stufe_2.png differ diff --git a/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionSend.png b/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionSend.png similarity index 100% rename from docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionSend.png rename to docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionSend.png diff --git a/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionZyklus.png b/docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionZyklus.png similarity index 100% rename from docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new ContributionZyklus.png rename to docu/Concepts/BusinessRequirements/image/UC_Send_Contribution_Admin-new_ContributionZyklus.png