diff --git a/docu/Concepts/BusinessRequirements/BenutzerVerwaltung.md b/docu/Concepts/BusinessRequirements/BenutzerVerwaltung.md new file mode 100644 index 000000000..0e7fb5d9e --- /dev/null +++ b/docu/Concepts/BusinessRequirements/BenutzerVerwaltung.md @@ -0,0 +1,31 @@ +# Benutzer-Verwaltung + + + +Benutzer + +* * + * natürliche Person = TRUE (Flag für Schöpfungserlaubnis Human) + * Vorname + * Nachname + * natürliche Person = FALSE (Flag für Schöpfungserlaubnis Human) + * Projekt/Firmenname/Organisation/Verein... + * Benutzername + * Emailadresse + * Konto + * Trustlevel (Zukunft) + + +## Anwendungsfälle + +### neuen Benutzer anlegen + +### Benutzer bearbeiten + +### Benutzer löschen + +### Benutzer authentifizieren + +### Benutzer authorisieren + +### Benutzer bekanntgeben diff --git a/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md b/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md new file mode 100644 index 000000000..abe97afc0 --- /dev/null +++ b/docu/Concepts/BusinessRequirements/CommunityVerwaltung.md @@ -0,0 +1,246 @@ +# Verwaltung der Communities + +Diese Konzept beschreibt den Begriff "Community" im Kontext von Gradido, welche Eingenschaften eine Community hat und was man mit einer Community alles machen kann. + +## Die Bedeutung des Begriffs Community + +Eine Community bedeutet im Kontext von Gradido eine Gemeinschaft von Personen, die sich nach der Philosophie von Gradido zu einer gemeinsamen Gruppierung zusammenschließen. Unter dem gemeinsamen Zusammenschluß folgen sie der Natürlichen Ökonomie des Lebens. Die Community dient dabei als Rahmen für die Gruppe von Personen, um ihnen den geregelten Zugang zu ermöglichen. Unter dem Begriff "Zugang zur Community" wird die Registrierung eines Benutzerkontos für eine Person verstanden. Dabei erfolgt eine Autentifizierung der Person, um einen personenspezifischen Zugriff auf die Community-Funktionalitäten zu ermöglichen. Denn eine Community bietet einer Person eine Vielzahl an Funktionalitäten, die ein Community-Mitglied nutzen kann. So steht die Verwaltung und das Handeln mit Gradido-Geld als die Hauptfunktionalität einer Community im Vordergrund. Doch sind auch weitere Funktionalitäten, wie eine Selbstdarstellung über Benutzerprofile oder ein sich Vernetzen mit Community-Mitgliedern, aber auch ein Community übergreifendes Vernetzen als soziale Netzewerke möglich. So können aus kleinen Communities über Vertrauensverhältnisse Zusammenschlüsse mehrere eigenständigen Communities entstehen oder auch eine Hierarchie von Communities als Parent-Child-Verbindung aufgebaut werden (siehe weiter unten "Community-Modelle"). + +Innerhalb der Community erfolgt die Umsetzung und Verwaltung des "lebendigen Geldes". Soll heißen hier werden die Mechanismen zur Dreifachen-Schöpfung vollzogen, die das geschöpfte Geld nach den Community-Regeln auf die drei Arten von Empfängerkonten (Benutzerkonto, Gemeinwohlkonto und Ausgleichs- und Umweltkonto) verteilt. Ein Community-Mitglied kann über seinen Community-Zugang auf sein persönliches Benutzerkonto zugreifen und darüber sein Gradido-Geld verwalten. Neben der Einsicht auf seinen aktuellen Kontostand kann er u.a. seine regelmäßig geschöpften Gradido einsehen, mit vorhandenen Gradido bezahlen oder einem anderen Mitglied Gradido überweisen. Die Geldbewegungen werden als eine Liste von Transaktionen geführt und die Vergänglichkeit der Gradidos immer aktuell zur Anzeige gebracht. + +Nach der Bedeutung des Begriffs Community werden nun die Eigenschaften einer Community detailliert beschrieben, damit all die zuvor erwähnten Möglichkeiten der Community abbildbar sind. + +## Eigenschaften einer Community + +Hier werden die Eigenschaften einer Community beschrieben, die notwendig sind, um die oben erwähnten Möglichkeiten der Community zu erfüllen. Es geht dabei um verschiedene Themen und ihre dazu notwendigen Prozesse, die wiederum unter Verweiß in anderen Dokumenten detailter beschrieben sind. + +### Anzeige und -Darstellung + +Da es also mehrere Communities geben wird, benötigt jede Community ihren eigenen Namen und gar ein Symbol oder Bild, um eine optische Unterscheidung bei der Anzeige in den Systemen sicherzustellen. Für eine Aussendarstellung wäre eine Beschreibung der Community und ihre eigene Philosopie, was die Community auszeichnet hilfreich. Diese Werte müssen vom Community-Administrator gepflegt werden können. + +### Mitgliederverwaltung + +Für die Verwaltung von Community-Mitgliedern werden entsprechende Verwaltungsprozesse wie Registrierung, Login mit Autentifizierung, eine Benutzerverwaltung für neue, bestehende und ausscheidende Mitgleider benötigt. Die Benutzerverwaltung stellt zusätzlich die Anforderung, dass ein Community-Mitglied eindeutig identifizierbar ist und das Community übergreifend. Das bedeutet es kann eine Person immer nur einmal existieren und darf auch niemals in mehreren Communities gleichzeitig Mitglied sein. Denn es muss sichergestellt werden, dass eine Person sich keine unerlaubte Vorteil durch zum Beispiel mehrfache Geldschöpfung in mehreren Communities verschafft. Die Details der Mitgliederverwaltung werden beschrieben im Dokument [BenutzerVerwaltung](.\BenutzerVerwaltung.md). + +### Community-Vernetzung + +Für die Community-Vernetzung sind Verwaltungsprozesse zwischen den Communities und auch den Community-Mitgliedern notwendig, um entsprechende Vertrauensverhältnisse aufzubauen. Diese müssen den notwendigen Sicherheitsansprüchen genügen, da darauf aufbauend dann später die Geld-Flüsse abgewickelt werden. Entsprechend den Community-Modellen (siehe im folgenden Unterkapitel **Community Modelle**) wird ein Prozess benötigt, der die Hierarchie bzw. das Vertrauensverhältnis zwischen zwei eigenständigen Communities aufbaut und daraus dann die möglichen Funktionalitätserweiterungen für die Mitglieder bzw. den Communities freischaltet bzw. unterstützt. Zusätzlich wird auch der jeweilige umgekehrte Prozess benötigt, der eine bestehende Hierarchie bzw. ein bestehendes Vertrauensverhältnis zwischen zwei Communities auflöst und löscht, sowie die daraus resultierenden Funktionseinschränkungen für die Mitglieder und die betroffenen Communities. + +Zum besseren Verständnis der Community-Vernetzung erfolgt hier eine Beschreibung der möglichen Konstellationen, wie sich Communities miteinander verbinden können. + +#### Community Modelle + +Bei Gradido werden verschiedene Modelle von Community-Abhängigkeiten unterstützt. Dabei soll unterschieden werden zwischen: + +* eigenständige Community +* sich gegenseitig vertrauende Communities +* von einander abhängige (vererbende) Communities +* Mischung aus den vorherigen Modellen + +Das nachfolgende Bild zeigt einen ersten Eindruck über die unterschiedlichen Community-Modelle: + +![CommunityModell](./image/CommunityModell.png) + + + +##### Eigenständige Community + +Eine eigenständige Community zeichnet sich darin aus, dass sie keine Beziehung zu einer anderen Community aufgebaut hat. Das heißt sie hat weder eine vertrauenswürdige Verknüpfung mit einer zweiten Community, noch hat sie eine Verbindung zu einer Parent-Community und besitzt auch selbst keine Verbindung zu einer Child-Community. Somit kann diese Community für ihre Mitglieder nur Community intern wirksame Prozesse anbieten. Das heißt es ist kein Community übergreifender Handel bzw. Austausch von Gradido möglich. Andererseits werden in dieser Community die Prozesse freigeschaltet, dass ein Aufbau eines vertrauenswürdiges Verhältnis zu einer anderen Community erlaubt, der Aufbau einer Parent-Beziehung und auch der Aufbau einer Child-Beziehung ermöglicht. Die zugehörigen Abbau-Prozesse dagegen sind nicht freigeschalten. Der Community übegreifende Überprüfungsprozess bei der Mitglieder-Registrierung zur eindeutigen Identifikation in der Mitglieder-Verwaltung zählt dabei nicht als vertrauenswürdige Verbindung zwischen Communities. + +##### Gegenseitig vertrauende Communities + +*Hier soll beschrieben werden, was den Unterschied auszeichnet zu einer "Eigenständigen Community", wie man das gegenseitige Vertrauen (sprich Verknüpfung) zwischen zwei oder mehreren Communities auf- und wieder abbaut, was bedarf es an Vorraussetzungen für einen Vertrauens-Auf/Abbau und welche Konsequenzen der Auf- und Abbau des gegenseitigen Vertrauens haben soll.* + +Das Modell der sich "gegenseitig vertrauenden Communities" entspringt der Idee des sich miteinander Vernetzens und damit das Handeln und Agieren mit Gradido-Mitgliedern, die nicht in der eigenen Community als Mitglied registriert sind. Um dies zu ermöglichen bedarf es einem Aufbau-Prozess zwischen zwei Communities, die sich zukünftig gegenseitig ein enges Vertrauen schenken. Auf der Basis dieses Vertrauens tauschen die beiden Communities Informationen untereinander aus, so dass für die Mitglieder beider Communities die Funktionalitäten auf der Gradido-Plattform so transparent erscheinen, als ob sie alle Mitglied einer Community wären. Das würde sich beispielsweise bei der Suche nach einem bestimmten Community-Mitglied auswirken, da nun alle Mitgleider beider Communities in einer Liste zu Anzeige gebracht werden können. Oder der Transfer von Gradidos von einem Mitglied zu einem anderen Mitglied ist über dieses Community-Verhältnis nun auch Community übergreifend möglich. Auch weitere Angebote, die bisher nur in einer Community zur Verfügung standen, sind nun auch den Mitgliedern der anderen Community zugänglich. + +Während des Aufbau-Prozesses werden neben den eigentlichen Security relevanten Informationen für den Aufbau und die Sicherstellung des Vertrauensverhältnisses auch fachliche Informationen ausgetauscht. Unter fachlichen Informationen sind die nun freigeschaltenen Angebote beider Communities gemeint. Somit werden in der einen Community nun auch die fachlichen Prozesse und Angebote der anderen Community zugänglich und freigeschalten und umgekehrt. Wie feingranular die Prozesse und Angebote dabei ausgetauscht und freigeschaltet werden unterliegt einer administrativen Konfiguration der jeweiligen Community. Das heißt der Administrator jeder Community kann im Vorfeld selektiv konfigurieren welche Angebote und Prozesse beim Aufbau-Prozess für ein Vertrauensverhältnis mit einer anderen Community übertragen und freigeschaltet werden. Diese Konfiguration sollte zuvor Community intern abgestimmt sein, um nicht schon zu Beginn der Zusammenarbeit der beiden Communities irgendwelche Missstimmungen unter den Mitgliedern zu verursachen. Die Details des "Vertrauensverhältnis Aufbau-Prozesses" sind weiter unten im Kaptiel Anwendungsfälle beschrieben. + +##### Abhängige Communities + +*Hier soll beschrieben werden, was den Unterschied zu eigenständigen und sich gegenseitig vertrauenden Communities zu den hier abhängigen (sprich vererbten) Communities auszeichnet, welche Vorraussetzungen bedarf der Auf/Abbau einer abhängigen Community und welche Konsequenzen hat der Auf- und Abbau von abhängigen Communities.* + +Parent-Child Beziehung aufbauen: + +keine Änderung der Schöpfungsprozesse + +- jede Community schöpft für ihre Benutzer die 3 Empfängerkonto die jeweils 1000 GDD + +eine Child-Community kann immer nur zu einer Parent-Community gehören + +ein Benutzer kann immer nur zu einer Community gehören + +Schöpfen kann immer nur eine natürliche Person + +Projekt-Konto entspricht "nicht natürliche Person" und kann nicht schöpfen + +Benutzerkonto kann von einer Community in eine andere Community wechseln + +Gradido-ID als Ersatz für Email-Adresse : server/nutzername + +Nutzername ist pro server eindeutig + +Nutzerprofil mit Bild und persönlichen Angeboten + +##### Mischung aus den vorherigen Modellen + +*Hier soll beschrieben werden welche möglichen Mischungen von Modellen erlaubt sind und welche nicht, was hat eine Mischungsvariante an Konsequenzen, wie wird eine Mischungsvariante auf/abgebaut, welche Vorraussetzungen bedarf es für den Auf/Abbau einer Mischungsvariante.** + +### Geldschöpfung + +Eine Community stellt die Mechanismen für die Dreifache-Geldschöpfung bereit. Dazu müssen zuerst die Verteilungsschlüssel auf die drei Kontoarten definiert bzw. konfigurierbar sein. Diese Konfigurationswerte werden vom Community-Administrator gepflegt. Sie dienen als Grundlage für die Höhe der regelmäßig geschöpften Beträge auf die drei Empfängerkonto-Typen. Die regelmäßige Geldschöpfung läuft automatisiert im Hintergrund und muss den Regeln der Nartürlichen Ökonomie des Lebens folgen. Die Details der Dreifachen Geldschöpfung sind in dem Dokument [RegelnDerGeldschoepfung](./RegelnDerGeldschoepfung.md) beschrieben. + +### Konto-Verwaltung + +Durch die Dreifach-Geldschöpfung verwaltet die Community auch die drei Arten von Konten: Benutzerkonto, Gemeinwohlkonto und Ausgleichs- und Umweltkonto(AUF). + +Für jedes Mitglied der Community wird also ein eigenes Benutzerkonto verwaltet, auf das ein Drittel der monatlichen Geldschöpfung fließt. Das Gemeinwohlkonto und das AUF-Konto existieren pro Community einmal und auf jedes der beiden Konten fließen monatlich die beiden anderen Drittel der Geldschöpfung. + +Somit muss also eine Community für jede Kontoart die entsprechenden Kontoverwaltungsprozesse anbieten. Einmal in Verbindung pro Mitglied für das Benutzerkonto und dann jeweils eine Verwaltung für das Gemeinwohlkonto und eine Verwaltung für das AUF-Konto. Die Berechtigungen für die Zugriffe auf die drei Kontoarten müssen ebenfalls in der Community gepflegt und kontrolliert werden. Das bedeutet die Community muss ihren Mitgliedern auf ihre eigenen Benutzerkonten Zugriffsrechte erteilen und diese auch kontrollieren, so dass keine unerlaubten Zugriffe stattfinden können. Dann müssen in der Community bestimmte Mitglieder Sonderberechtigungen erhalten, um die Verwaltung des Gemeinwohlkontos und des AUF-Kontos durchführen zu können. Die Verwaltung der Berechtigungen ist wiederum alleine dem Community-Administrator erlaubt. Die Details der Kontenverwaltung ist im Dokument [KontenVerwaltung](.\KontenVerwaltung.md) beschrieben. + +### Berechtigungsverwaltung + +Die Community muss für die verschiedenen Eigenschaften und Prozesse eine eigene Berechtigungsverwaltung zur Verfügung stellen. Für die verschiedenen Berechtigungen muss ein Rollen- und Rechte-Konzept administrierbar sein, so dass für die verschiedenen Mitglieder der Community die Zugriffe feingranular definiert, gesteuert und kontrolliert werden können. Allein der Administrator hat die Rechte auf die Berechtigungsverwaltung zuzugreifen. Das System muss diese hinterlegten Rollen und Rechte dann auf die verwalteten Mitglieder abbilden und für jeden Zugriff auf die Community entsprechend kontrollieren, freigeben oder verhindern. + +### Attribute einer Community + +In diesem Kapitel werden die Attribute beschrieben, die in einer Community zu speichern sind. + +#### Name + +Das Attribut Name dient zur möglichst eindeutigen Benennung der Community. Er wird als Menschen lesbare Anzeige und als Unterscheidungskriterium bei mehreren Communities eingesetzt. Nur der Community Administrator kann diesen setzen und verändern. + +#### Bild + +Das Attribut Bild wird für die Anzeige einer Community verwendet und kann nur vom Community-Administrator gesetzt werden. + +#### Beschreibung + +Das Attribut Beschreibung ist ein Text, der die Philosophie der Community ausdrücken soll. Hier können sich die Community-Mitglieder eine gemeinsame Formulierung ausdenken, die nach ihrer Vorstellung den Kern und die Grundregeln ihrer Gemeinschaft am besten ausdrücken. Dies könnte wie eine Art Aussendarstellung für neue Mitglieder dienen. Aber nur der Community-Administrator hat die Schreib-Rechte für dieses Attribut. + +#### Serverzuordnung + +Das Attribut Serverzuordnung ist technisch motiviert und dient zusammen mit dem Attribut Name der eindeutigen Identifikation einer Community. Bei der Gründung einer neuen Community muss festgelegt werden auf welchem Server diese Community gehostet wird - auf einem schon vorhandenen Server oder ein extra für diese Community neu aufgesetzter Server. Das Attribut Serverzuordnung muss aber für eine Virtualisierung und technische Skalierung auf mehrere Server-Instanzen vorbereitet sein, sodass keine direkte physische Hardware-Serverzuordnung hierdurch fixiert ist. Aber auch ein eventueller Umzug der Community von einem Server auf einen anderen Server muss möglich sein. Der Community-Administrator hat alleiniges Zugriffrecht auf dieses Attribut. + +#### Liste von Benutzer + +Dieses Listenattribut beinhaltet Benutzer-Elemente, die erfolgreich als Mitglied der Community registriert sind. Die Details eines Benutzer-Elements werden in dem Dokument [BenutzerVerwaltung](./BenutzerVerwaltung.md) beschrieben. + +#### Gemeinwohlkonto + +Das Attribut Gemeinwohlkonto dient als ein Konto-Element, das den Kontotyp Gemeinwohlkonto repräsentiert. Alle Kontobewegungen, wie Geldschöpfung, Geldtransfers, etc., die das Gemeinwohl dieser Community betreffen, werden über dieses Attribut abgewickelt. Details zu Kontobewegungen werden im Dokument [KontenVerwaltung](KontenVerwaltung.md) beschrieben und die Regeln und Vorgänge der Geldschöpfung sind im Dokument [RegelnDerGeldschoepfung](RegelnDerGeldschoepfung.md) zu finden. Auf dieses Attribut haben nur Mitglieder mit entsprechenden Zugriffsrechten die Erlaubnis und Möglichkeiten darauf Einsicht zu nehmen und Prozesse auszulösen. + +#### Ausgleichs- und Umweltkonto AUF-Konto + +Das Attribut Ausgleichs- und Umweltkonto dient als ein Konto-Element, das den Kontotyp AUF-Konto repräsentiert. Alle Kontobewegungen, wie Geldschöpfung, Geldtransfers, etc., die das AUF-Konto dieser Community betreffen, werden über dieses Attribut abgewickelt. Details zu Kontobewegungen werden im Dokument [KontenVerwaltung](KontenVerwaltung.md) beschrieben und die Regeln und Vorgänge der Geldschöpfung sind im Dokument [RegelnDerGeldschoepfung](RegelnDerGeldschoepfung.md) zu finden. Auf dieses Attribut haben nur Mitglieder mit entsprechenden Zugriffsrechten die Erlaubnis und Möglichkeiten darauf Einsicht zu nehmen und Prozesse auszulösen. + +#### Verteilungsschlüssel der Dreifachen-Schöpfung + +Im Attribut Verteilungsschlüssel der Dreifach-Schöpfung werden die für die Community festgelegten Verteilschlüssel konfiguriert. Diese Werte dienen als Grundlage für die Geldschöpfung dieser Community. Nut der Administrator hat Zugriffrechte auf diese Attribut. + +#### Parent + +Das Attribut Parent dient für den hierarchischen Aufbau von Communities. Es enthält den Bezug auf die Community, die für diese Community als Eltern-Community eingerichtet ist. Eine Child-Community kann maximal eine Parent-Community haben. Durch diesen Bezug zu der Parent-Community werden einzelne Prozesse zwischen der Parent- und der Child-Community freigeschalten. Damit ergeben sich erweiterte Möglichkeiten u.a. für die Community-Mitglieder beider Communities, wie beispielsweise das Community übergreifende Handeln zwischen den Community-Mitgliedern oder eine veränderte Verteiltung der Gemeinwohl- und AUF-Schöpfung, etc.. Die Administration dieses Attributes erfolgt implizit über die fachlichen Prozesse, die den Auf- und Abbau einer Parent-Child-Beziehung zwischen zwei Communities steuern. Diese können nur durch den Adminitrator und seiner Berechtigung ausgelöst werden. Die Beschreibung dieser Prozesse ist weiter unten im Kapitel **Anwendungsfälle auf einer Community** zu finden. + +#### Liste Children + +Das Attribut Liste Children dient ebenfalls dem hierarchischen Aufbau von Communities. Es enthält die Bezüge auf die Communities, die für diese Community als Child-Community eingerichtet sind. Eine Parent-Community kann mehrere Child-Communities haben. Durch diesen Bezug zu den Child-Communities werden einzelne Prozesse zwischen der Parent- und den Child-Communities freigeschalten. Damit ergeben sich erweiterte Möglichkeiten u.a. für die Community-Mitglieder beider Communities, wie beispielsweise das Community übergreifende Handeln zwischen den Community-Mitgliedern oder eine veränderte Verteiltung der Gemeinwohl- und AUF-Schöpfung, etc.. Die Administration dieses Attributes erfolgt implizit über die fachlichen Prozesse, die den Auf- und Abbau einer Parent-Child-Beziehung zwischen zwei Communities steuern. Diese können nur durch den Adminitrator und seiner Berechtigung ausgelöst werden. Die Beschreibung dieser Prozesse ist weiter unten im Kapitel **Anwendungsfälle auf einer Community** zu finden. + +#### Liste Trusted Communities + +Das Attribut Liste Trusted Communities dient dem Aufbau von gleichberechtigten Community-Gruppierungen. Es enthält die Bezüge auf die Communities, die für diese Community als vertrauenswürdige Communities eingerichtet sind. Eine vertrauenswürdige Community-Gruppierung kann mehrere gleichberechtigte Communities haben. Durch diesen Bezug zu den vertrauenswürdigen Communities werden einzelne Prozesse zwischen den sich gegenseitig vertrauenden Communities freigeschalten. Damit ergeben sich erweiterte Möglichkeiten u.a. für die Community-Mitglieder beider Communities, wie beispielsweise das Community übergreifende Handeln zwischen den Community-Mitgliedern, etc.. Die Administration dieses Attributes erfolgt implizit über die fachlichen Prozesse, die den Auf- und Abbau einer vertrauenswürdigen Beziehung zwischen zwei Communities steuern. Diese können nur durch den Adminitrator und seiner Berechtigung ausgelöst werden. Die Beschreibung dieser Prozesse ist weiter unten im Kapitel **Anwendungsfälle auf einer Community** zu finden. + +Verteilung (automatische Tx) von unten nach oben an Parent Community für zukünftig angedacht + +keine Verteilung zwischen TrustedCommunities + +Transaktionen auf Gemeinwohlkonto und AUF-Konto + +Menschkonto (HumanAccount, PersonalAccount) vs Sachkonto (ItemAccount, ImpersonalAccount ) + +## Anwendungsfälle auf einer Community + +Die nachfolgenden Anwendungsfälle beschreiben die fachlichen Vorraussetzungen, den fachlichen Ablauf und die fachlichen Veränderungen bzw. den fachlichen Status, der am Ende des erfolgreich abgeschlossenen Anwendungsfalles erreicht wird. Desweiteren erfolgt die fachliche Beschreibung der möglichen Fehlerfälle, in die ein Anwendungsfall münden kann und welcher fachlicher Status am Ende des Anwendungsfalles herrschen soll. + +### Neue Community erstellen + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle + +### Community bearbeiten + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle + +### Community löschen + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle + +### Community-Verknüpfen erstellen + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle + +### Community-Verknüpfung löschen + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle + +### Community-Vererbung erstellen + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle + +### Community-Vererbung löschen + +*Allgemeine fachliche Beschreibung des Anwendungsfalles.* + +#### Vorraussetzungen + +#### Ablauf + +#### Ende Status + +#### Fehlerfälle diff --git a/docu/Concepts/BusinessRequirements/GraDiDoTransaktionen.md b/docu/Concepts/BusinessRequirements/GraDiDoTransaktionen.md new file mode 100644 index 000000000..be0ba9e61 --- /dev/null +++ b/docu/Concepts/BusinessRequirements/GraDiDoTransaktionen.md @@ -0,0 +1,99 @@ +# GraDiDo-Transaktionen + +Im Kontext von GraDiDo gibt es unterschiedliche Arten von Transaktionen: + +* das Schöpfen von GraDiDo (GDD) +* das Übertragen von GDD +* die Vergänglichkeit von GDD +* das Schöpfen von GraDiDo-Transform (GDT) +* das Übertragen von GDT +* das Umwandeln von GDT in GDD + +Dieses Konzept beschreibt für jede Art der Transaktion ihre fachliche Bedeutung, die notwendigen Vorraussetzungen, der fachliche Ablauf und den Ende-Status nach erfolgreicher Transaktionsbearbeitung. Desweiteren werden für jede Transaktionsart alle fachlich möglichen Fehlerfälle aufgeführt und welchen Endstatus die abgebrochene Transaktion dann hinterläßt. + +## Schöpfen von GDD + +*Hier erfolgt die fachliche Beschreibung der Transaktion* + +### Vorraussetzungen + +### Ablauf + +### Ende Status + +### Fehlerfälle + +## Übertragen von GDD + +*Hier erfolgt die fachliche Beschreibung der Transaktion* + +### Vorraussetzungen + +### Ablauf + +### Ende Status + +### Fehlerfälle + +## Vergänglichkeit von GDD + +*Hier erfolgt die fachliche Beschreibung der Transaktion* + +### Vorraussetzungen + +### Ablauf + +### Ende Status + +### Fehlerfälle + +## Schöpfen von GDT + +*Hier erfolgt die fachliche Beschreibung der Transaktion* + +Das Schöpfen von Gradido-Transform wird aktuell (07.2021) über die Plattform Elopage abgewickelt. Das heißt ein auf Elopage registriertes Mitglied zahlt dort eine Summe von Euros auf sein Konto ein. Diese Transaktion in Elopage wird vom GDT-Server abgegriffen und in der GDT-Datenbank gespeichert. + +Folgende Transaktions-Konstellationen können fachlich zwischen Elopage und dem GDT-Server auftreten bzw. müssen von den beteligten Systemen abgewickelt werden: + +![Elopage-GDT-Transaktionen](./image/Elopage-GDT-Transaktionen.png) + +In Variante 1 ist zu sehen, dass die 21%-Transaktion vor der Übertragung der Elopage-Transaktion stattgefunden hat und die Berechnung des GDT-Kontostandes davon unberührt bleibt. + +In Variante 2 taucht nun die Frage auf, wie man mit offenen Transaktionen aus Elopage umgeht. Sollen diese in der 21%-Transaktion mitberücksichtigt werden, dann hätte das eine Änderung der Kontostandsberechnung gegenüber Variante 1 zur Folge. Sollen diese offenen Transaktionen nicht mitberücksichtigt werden, dann wäre kein Unterschied gegenüber Variante 1. + +In Variante 3 ist aber zu sehen, dass ein nicht berücksichtigen der offenen Transaktion einen weiteren Effekt nach sich zieht. Denn eine offene Transaktion könnte ja auch nicht erfolgreich committet, sondern könnte aus welchem Grund auch immer gecancelt werden. Das würde bedeuten, dass die 21%-Transaktion erst abgeschlossen werden kann, sobald die offene Transaktion erfolgreich beendet ist. + + + + +### Vorraussetzungen + +### Ablauf + +### Ende Status + +### Fehlerfälle + +## Übertragen von GDT + +*Hier erfolgt die fachliche Beschreibung der Transaktion* + +### Vorraussetzungen + +### Ablauf + +### Ende Status + +### Fehlerfälle + +## Umwandeln von GDT in GDD + +*Hier erfolgt die fachliche Beschreibung der Transaktion* + +### Vorraussetzungen + +### Ablauf + +### Ende Status + +### Fehlerfälle diff --git a/docu/Concepts/BusinessRequirements/KontenVerwaltung.md b/docu/Concepts/BusinessRequirements/KontenVerwaltung.md new file mode 100644 index 000000000..e59adf4e3 --- /dev/null +++ b/docu/Concepts/BusinessRequirements/KontenVerwaltung.md @@ -0,0 +1,12 @@ +# GraDiDo-Kontoverwaltung + + +## Anwendungsfälle + +### GDD-Konto neuanlegen + +### GDD-Konto bearbeiten + +### GDD-Konto löschen + +### GDD-Konto ent/sperren diff --git a/docu/Concepts/BusinessRequirements/RegelnDerGeldschoepfung.md b/docu/Concepts/BusinessRequirements/RegelnDerGeldschoepfung.md new file mode 100644 index 000000000..0cdd811d3 --- /dev/null +++ b/docu/Concepts/BusinessRequirements/RegelnDerGeldschoepfung.md @@ -0,0 +1 @@ +# Regeln der Geldschöpfung diff --git a/docu/Concepts/BusinessRequirements/graphics/CommunityModell.drawio b/docu/Concepts/BusinessRequirements/graphics/CommunityModell.drawio new file mode 100644 index 000000000..775c958cc --- /dev/null +++ b/docu/Concepts/BusinessRequirements/graphics/CommunityModell.drawio @@ -0,0 +1,151 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/docu/Concepts/BusinessRequirements/graphics/Elopage-GDT-Transaktionen.drawio b/docu/Concepts/BusinessRequirements/graphics/Elopage-GDT-Transaktionen.drawio new file mode 100644 index 000000000..66fa7c3e3 --- /dev/null +++ b/docu/Concepts/BusinessRequirements/graphics/Elopage-GDT-Transaktionen.drawio @@ -0,0 +1,297 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/docu/Concepts/BusinessRequirements/image/CommunityModell.png b/docu/Concepts/BusinessRequirements/image/CommunityModell.png new file mode 100644 index 000000000..141df43a5 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/CommunityModell.png differ diff --git a/docu/Concepts/BusinessRequirements/image/Elopage-GDT-Transaktionen.png b/docu/Concepts/BusinessRequirements/image/Elopage-GDT-Transaktionen.png new file mode 100644 index 000000000..55fe58ea7 Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/Elopage-GDT-Transaktionen.png differ diff --git a/docu/Concepts/BusinessRequirements/image/my_gradido.png b/docu/Concepts/BusinessRequirements/image/my_gradido.png new file mode 100644 index 000000000..c5131678e Binary files /dev/null and b/docu/Concepts/BusinessRequirements/image/my_gradido.png differ diff --git a/docu/Concepts/TechnicalRequirements/Transactions/Transaktionen.md b/docu/Concepts/TechnicalRequirements/Transactions/Transaktionen.md new file mode 100644 index 000000000..85bd1a53b --- /dev/null +++ b/docu/Concepts/TechnicalRequirements/Transactions/Transaktionen.md @@ -0,0 +1,40 @@ +# GraDiDo-Transactions + +## General Description + +The GraDiDo-System offers the business processes "CreateGraDiDo" and "TransferGraDiDo". Both processes need data, which has to be transferred between the involved different systems, especially between the internal GraDiDo servers and the external "BlockChain"-Service - currently (07.2021) IOTA is in use. + +The main topic for the GraDiDo-Transactions is to ensure a misusage of money creation and keep all changes on an account consistent. + +The basic requirements on this transfer data should be encapsulated in a base type and the business details for the different processes should be extended in separated types, which inherited the basics from the base type. + +## Transaction Processes + +In this chapter the two business processes are described to understand the different requirements, which leads to the transaction model following below. + +### CreateGraDiDo + +The creation of GraDiDo-money has to fulfill the following business rules: + +* it can only be create for an account of a human being +* the account of the human being belongs to one group ***- what about group-hierarchy and the dependencies for group and fund recipients?*** +* per month + * maximal 1.000 GDD for the private account + * maximal 1.000 GDD for the group account the human being belongs to + * maximal 1.000 GDD for the compensation and environmental fund of the group + * use the configured group specific triple-amount for the three recipients ***- what about group-hierarchy and the dependencies for group and fund recipients?*** +* the target month of creation must not be older than 3 month + +### TransferGraDiDo + +## Type of Transactions + +For the two business processes there are two different types of transactions necessary. + +### Create-Transaction + +The Create-Transaction is used to create GDDs for + +### Transfer-Transaction + +## Transaction-Model diff --git a/docu/Concepts/Testfallkatalog/ReadMe-Testkatalog.md b/docu/Concepts/Testfallkatalog/ReadMe-Testkatalog.md new file mode 100644 index 000000000..75a2eb1bc --- /dev/null +++ b/docu/Concepts/Testfallkatalog/ReadMe-Testkatalog.md @@ -0,0 +1,52 @@ +# Testfall-Katalog + +Der Testfall-Katalog wird in dem Verzeichnis *Testfallkatalog* angelegt. Er wird zu den verschiedenen fachlichen Themen durch Unterverzeichnisse gegliedert. In den jeweiligen Unterverzeichnissen sind die zugehörigen Testfälle als einzelne Dateien definiert. + +## Namenskonventionen + +Als **Themen** sind beispielsweise + +* CommunityVerwaltung +* BenutzerVerwaltung +* Schöpfung/Vergänglichkeit +* u.a. + +vorgesehen, die als Unterverzeichnisse mit folgenden Nameskonventionen angelegt sind: + +* Prefix-Pattern: "T", zweistellige laufende Nr, "-", Themenbezeichnung +* Beispiel: T01-CommunityVerwaltung + +Die **Testfälle** selbst werden in einzelnen Dateien beschrieben. Die Namen der Testfall-Dateien folgen dem Namenspattern: + +* Prefix-Pattern: "C", dreistellige laufende Nr, "-", zweistellig laufende Nr, "-", Testfallbezeichnung +* Beispiel: C001-01-Benutzerregistrierung +* die dreistellige Nummer wird mit der Testfallbezeichnung in Bezug gesetzt +* die zweistellige Nummer dient als optionale Untergliederung für einen Testfall +* Beispiel: + * C001-01-Benutzerregistrierung: Schritt 1 - Registrierungslink + * C001-02-Benutzerregistrierung: Schritt 2 - Datenerfassung + * C001-03-Benutzerregistrierung: Schritt 3 - ... + +Um Dialog-Masken als **Bilder** in die Testfallbeschreibungen einzubinden, gibt es das Verzeichnis Testfallkatalog/image. Dieses enthält alle Bilder aller Testfälle nach folgenden Konventionen: + +* Die Bild-Dateien werden so benannt, wie die Testfalldatei, die sie einbindet. +* Sollten mehrere Bilder pro Testfall-Beschreisbung notwendig sein, dann wird am Ende des Dateinamens, aber vor der Extension eine laufende Nummer vergeben. +* In der Testfall-Beschreibung können diese Bilder mit folgender Notation eingebunden werden: + * `![alternativer Text](../image/)` +* Wie man direkt DrawIO-Bilder einhängen kann, ist noch nicht klar (notfalls muss eben ein PNG-Bild davon gemacht werden) + + +## Testfall-Vorlage + +Im Verzeichnis Testfallkatalog liegt eine Testfall-Vorlage, die als Kopie für das Anlegen eines neuen Testfalles herangezogen werden kann. Die Kopie der Testfallvorlage im Test-Thema-Verzeichnis ist dann gemäß den oben beschriebenen Namenskonventionen für die Testfall-Datei umzubenennen. + +In der Testfall-Vorlage sind die Gliederungen und Themen benannt, was eine Testfallbeschreibung beinhalten sollte. + +## Ziel des Testfall-Katalogs + +1. Erfassung aller Testfälle für die bisher vorhandene Software + 1. Schrittweise werden die Testfall-Dateien auf Basis von Test-Sessions erstellt und mit Inhalt gefüllt. +2. Testfall-Erfassung als Grundlage **VOR** der Entwicklung! + 1. Bei der Erstellung eines Tickets für Software-Entwicklung/Änderung wird das "Test-Thema" und der "Testfall" definiert, der als Anforderung für das Ticket dann vom Ticket-Owner in Form einer Testfall-Datei beschrieben wird. + 2. Der Link der Testfall-Datei wird im Ticket hinterlegt + 3. Ein Ticket OHNE Testfall-Datei darf weder beim Review abgenommen noch für ein Release geschlossen werden. diff --git a/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-01-LoginMaske.md b/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-01-LoginMaske.md new file mode 100644 index 000000000..2fa9e35ee --- /dev/null +++ b/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-01-LoginMaske.md @@ -0,0 +1,112 @@ +# Testfall: "C001-01-LoginMaske" + +## Thema: "Benutzerverwaltung" + +## Beschreibung: + +*Welche(n) Anwendungsschritt/Oberfläche/Logik ist durch den Testfall betroffen?* + +Es wird die Anzeige der Login-Maske geprüft auf: + +* Vorhandensein aller geforderten Elemente gemäß Entwurf: + +![Login Maske](../image/C001-01-LoginMaske.png) + +* Layoutprüfung der statischen und dynamischen Elemente +* formelle Validierung von Eingaben in die Eingabefelder mit entsprechenden Fehlermeldungen +* Funktionsprüfung der Mehrsprachigkeit +* Funktionsprüfung der Footer-Links + +**Nicht enthalten in diesem Testfall:** + +* die Funktion hinter dem Button "Anmelden"; siehe dazu Testfall: [C001-02-LoginMaske]() +* die Funktion hinter dem Link "Passwort vergessen"; siehe dazu Testfall: [C001-03-LoginMaske]() + +## Vorraussetzungen: + +*Welche Vorraussetzungen (Daten/Anwendungschritte, etc.) müssen erfüllt sein, um den Testfall durchführen zu können?* + +Es wird die URL + +* Testumgebung: https://stage1.gradido.net/vue/login +* Produktionsumgebung: https://gradido.net/vue/login + +aufgerufen und die Login-Maske wird angezeigt. + + +## Testfall-Schritte: + +*Welche Schritte müssen zur Durchführung des Testfalles getätigt werden? (Dateneingaben/ Navigationen/ Link- o Button-Klicks/ Schritte der Anwendungslogik/ etc.)* + +1. Prüfung auf korrekte Anzeige der Statischen Elemente: + + 1. Text, Rechtschreibung und Layout von: + 1. Maskenüberschrift "Gradido" + 2. Maskentext "Tausend Dank, weil du bei uns bist" + 3. Eingabeüberschrift "Anmeldung" + 4. Label "Email" + 5. Default-Text "Email" bei ungefülltem Eingabefeld + 6. Label "Passwort" + 7. Default-Text "Passwort" bei ungefülltem Eingabefeld + 8. Button-Text "Anmeldung" + 9. Linktext "Passwort vergessen" + 10. Sprachauswahltexte + 11. Footer Copyright + 12. Footer Links: + 1. "Gradido-Akademie" + 2. "App-Version" + 3. "Impressum" + 4. "Datenschutzerklärung" + 5. "Mitgliederbereich" + 6. "Whitepaper" + 7. "Support" +2. Prüfung der Eingabedynamik in der Login-Maske: + + 1. Eingabefeld Email: + 1. valide Emailadresse gemäß Pattern: "name"@"domain"."ländercode" + 2. maximale Länge einer Email-Adresse? + 2. Eingabefeld Passwort: + 1. mindestens ein Zeichen + 2. maximale Länge eines Passwortes? + 3. Sichtbarschaltung und Verdeckung des eingegebenen Passwortes + 3. Sprachauswahl: + 1. entsprechen alle angezeigten Text der aktuell eingestellten Sprache? + 2. Umstellung der Sprache über die Sprachauswahl-Box + 3. Wiederholung von Schritt 2.3.1 und 2.3.2 bis alle verfügbaren Sprachen geprüft sind + 4. Footer-Links: + 1. "Gradido-Akademie" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de" + 2. "App-Version" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://github.com/gradido/gradido/releases/latest" + 3. "Impressum" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/impressum/" + 4. "Datenschutzerklärung" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/datenschutz/" + 5. "Mitgliederbereich" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://elopage.com/s/gradido/sign_in?locale=de" + 6. "Whitepaper" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://docs.google.com/document/d/1jZp-DiiMPI9ZPNXmjsvOQ1BtnfDFfx8BX7CDmA8KKjY/edit?usp=sharing" + 7. "Support"reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/contact/" + + +## Ende-Bedingungen: + +*Welche Bedingungen werden am Ende des Testfalles bei positivem Ergebnis erwartet? (Daten/ GUI/ Zustände/ etc)* + +Die Login-Maske wird wie erwartet angezeigt. + +Die Texte und Layouts entsprechen den Vorgaben. + +Die Format-Validierungen der Eingabefelder erfüllen die vorgegebenen Regeln + +Alle Links reagieren gemäß den Vorgaben + +Die Eingabefelder sind mit validen Inhalten gefüllt, so dass der Button "Anmeldung" betätigt werden könnte. Dies ist aber Teil des nächsten Testfalls unter [C001-02-LoginMaske]() + + +## erwartete Fehlerfälle: + +*Welche Fehlerfälle können auftreten und wie ist das erwartete Verhalten/ Rückgabewerte/ Fehlercode?* + +Eingabefeld "Email": + +* kein Inhalt -> Fehlermeldung "Email ist ein Pflichtfeld" +* ungültige Email-Adresseingabe -> Fehlermeldung "Email muss eine gültige E-Mail-Adresse sein" + +Eingabefeld "Passwort": + +* kein Inhalt -> Fehlermeldung "Passwort ist ein Pflichtfeld" diff --git a/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-02-LoginMaske.md b/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-02-LoginMaske.md new file mode 100644 index 000000000..8ca76bd88 --- /dev/null +++ b/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-02-LoginMaske.md @@ -0,0 +1,59 @@ +# Testfall: "C001-02-LoginMaske" + +## Thema: "Benutzerverwaltung" + +## Beschreibung: + +*Welche(n) Anwendungsschritt/Oberfläche/Logik ist durch den Testfall betroffen?* + +Es wird in der Login-Maske die Funktion des Buttons "Anmeldung"geprüft: + +![Login Maske](../image/C001-01-LoginMaske.png) + + +**Nicht enthalten in diesem Testfall:** + +* die Anzeige, Layout und Validierung der Login-Maske; siehe dazu Testfall: [C001-01-LoginMaske](file::./C001-01-LoginMakse.md) +* die Funktion hinter dem Link "Passwort vergessen"; siehe dazu Testfall: [C001-03-LoginMaske](C001-03-LoginMaske.md) + +## Vorraussetzungen: + +*Welche Vorraussetzungen (Daten/Anwendungschritte, etc.) müssen erfüllt sein, um den Testfall durchführen zu können?* + +Die Eingabefelder Email und Passwort sind mit validen Inhalten gefüllt. + + +## Testfall-Schritte: + +*Welche Schritte müssen zur Durchführung des Testfalles getätigt werden? (Dateneingaben/ Navigationen/ Link- o Button-Klicks/ Schritte der Anwendungslogik/ etc.)* + +Prüfung auf korrekten Funktionsweise des Buttons "Anmeldung": + +1. In beiden Eingabefeldern Email und Passwort sind gültige und schon registrierte Anmeldedaten eines Mitglieds eingetragen +2. Mit Betätigen des Buttons "Anmeldung" wird der Login-Prozess gestartet + 1. *Gibt es noch weitere Prüfschritte (LOG-Ausgaben auf Login-, Community-Server o.ä.) die hier überprüft werden sollten?* +3. Bei erfolgreichem Login wird die URL angezeigt + * Testumgebung: "https://stage1.gradido.net/vue/overview" + * Produktionsumgebung: "https://gradido.net/vue/overview" +4. Bei fehlerhaftem Login wird eine entsprechend aussagekräftige Fehlermeldung angezeigt und die Anzeige verbleibt auf der Login-Maske. + + + +## Ende-Bedingungen: + +*Welche Bedingungen werden am Ende des Testfalles bei positivem Ergebnis erwartet? (Daten/ GUI/ Zustände/ etc)* + +Der Login-Prozess wurde erfolgreich durchlaufen. + +Alle zu überprüfende Schritte des Login-Prozesses sind erfolgreich abgeschlossen. + +Es wird die Übersichtseite des angemeldeten Mitglieds angezeigt. + + +## erwartete Fehlerfälle: + +*Welche Fehlerfälle können auftreten und wie ist das erwartete Verhalten/ Rückgabewerte/ Fehlercode?* + +nicht registrierte Nutzerdaten in Eingabefeld "Email" und/oder "Passwort": + +* ungültiger Login -> Fehlermeldung "Leider konnten wir keinen Account finden mit diesen Daten!" diff --git a/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-03-LoginMaske.md b/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-03-LoginMaske.md new file mode 100644 index 000000000..69472625a --- /dev/null +++ b/docu/Concepts/Testfallkatalog/T02-Benutzerverwaltung/C001-03-LoginMaske.md @@ -0,0 +1,181 @@ +# Testfall: "C001-03-LoginMaske" + +## Thema: "Benutzerverwaltung" + +## Beschreibung: + +*Welche(n) Anwendungsschritt/Oberfläche/Logik ist durch den Testfall betroffen?* + +Es wird in der Login-Maske die Funktion des Links "Passwort vergessen?"geprüft: + +![Login Maske](../image/C001-01-LoginMaske.png) + +**Nicht enthalten in diesem Testfall:** + +* die Anzeige, Layout und Validierung der Login-Maske; siehe dazu Testfall: [C001-01-LoginMaske](./C001-01-LoginMakse.md) +* die Funktion hinter dem Link "Passwort vergessen"; siehe dazu Testfall: [C001-02-LoginMaske](C001-02-LoginMaske.md) + +## Vorraussetzungen: + +*Welche Vorraussetzungen (Daten/Anwendungschritte, etc.) müssen erfüllt sein, um den Testfall durchführen zu können?* + +Es wird die URL + +* Testumgebung: https://stage1.gradido.net/vue/login +* Produktionsumgebung: https://gradido.net/vue/login + +aufgerufen und die Login-Maske wird angezeigt. + +## Testfall-Schritte: + +*Welche Schritte müssen zur Durchführung des Testfalles getätigt werden? (Dateneingaben/ Navigationen/ Link- o Button-Klicks/ Schritte der Anwendungslogik/ etc.)* + +* Prüfung auf korrekten Funktionsweise des Links "Passwort vergessen?" +* keine sonstigen Eingaben bzw. Vorraussetzungen notwendig +* Mit Betätigen des Links "Passwort vergessen?" wird der Passwort-Zurücksetzen-Prozess gestartet und unter + * der Testumgebung: https://stage1.gradido.net/vue/password + * der Produktionsumgebung: https://gradido.net/vue/password +* folgende Maske angezeigt: + +![1te Passwort zurücksetzen Maske](../image/C001-03-LoginMaske1.png) + +1. **Prüfung der Anzeige-Elemente, Layout und Eingabevalidierungen des Eingabefeldes, Text, Rechtschreibung und Layout von:** + +* Maskenüberschrift "Passwort zurücksetzen" +* Maskentext "Wenn du dein Passwort vergessen hast, kannst du es hier zurücksetzen" +* Label "Email" +* Default-Text "Email" bei ungefülltem Eingabefeld +* Button-Text "Jetzt senden" +* Linktext "zurück" +* Sprachauswahltexte +* Footer Copyright +* Footer Links: + 1. "Gradido-Akademie" + 2. "App-Version" + 3. "Impressum" + 4. "Datenschutzerklärung" + 5. "Mitgliederbereich" + 6. "Whitepaper" + 7. "Support" + +2. **Prüfung der Eingabedynamik in der 1ten Passwort-Zurücksetzen-Maske:** + + 1. Eingabefeld Email: + 2. valide Emailadresse gemäß Pattern: "name"@"domain"."ländercode" + 3. maximale Länge einer Email-Adresse? + 4. Sprachauswahl: + + 1. entsprechen alle angezeigten Texte der aktuell eingestellten Sprache? + 2. Umstellung der Sprache über die Sprachauswahl-Box + 3. Wiederholung von Schritt 2.4.1 und 2.4.2 bis alle verfügbaren Sprachen geprüft sind + 5. Link "Zurück" ist aktiv und landet auf URL + + 1. Testumgebung: https://stage1.gradido.net/vue/Login + 2. Produktionsumgebung: https://gradido.net/vue/Login + 6. Footer-Links: + + 1. "Gradido-Akademie" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de" + 2. "App-Version" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://github.com/gradido/gradido/releases/latest" + 3. "Impressum" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/impressum/" + 4. "Datenschutzerklärung" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/datenschutz/" + 5. "Mitgliederbereich" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://elopage.com/s/gradido/sign_in?locale=de" + 6. "Whitepaper" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://docs.google.com/document/d/1jZp-DiiMPI9ZPNXmjsvOQ1BtnfDFfx8BX7CDmA8KKjY/edit?usp=sharing" + 7. "Support"reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/contact/" +3. **Prüfung des eigentlichen Passwort-Zurücksetzen Prozesses** + + 1. Eingabe einer bekannten und validen Email.Adresse, auf die man Zugriff hat. + 2. Mit Betätigen des Links "Passwort zurücksetzen" wird der Passwort-Zurücksetzen Prozess gestartet + 3. *Gibt es noch weitere Prüfschritte (LOG-Ausgaben auf Login-, Community-Server o.ä.) die hier überprüft werden sollten?* + 4. Sobald der Prozess die Zurücksetzen-Email abgeschickt hat, wird die folgende Maske angezeigt: + +![Email-Versandmakse](../image/C001-03-LoginMaske2.png) + +5. **In dem angegebenen Email-Postfach wird eine Email empfangen, die ein Zurücksetzen-Link enthält:** + 1. Testumgebung: https://stage1.gradido.net/vue/reset/'erzeugter rest-code' + 2. Produktionsumgebung: https://gradido.net/vue/reset/'erzeugter reset-code' +6. **Mit Betätigen des Reset-Links bzw. Aufruf des Rest-Links im Browser wird folgende Maske angezeigt:** + +![2te Passwort zurücksetzen Maske](../image/C001-03-LoginMaske3.png) + + + +7. **Prüfung der Anzeige-Elemente, Layout und Eingabevalidierungen der Eingabefelder** + +1. Text, Rechtschreibung und Layout von: + * Maskenüberschrift "Passwort zurücksetzen" + * Maskentext "Jetzt kannst du ein neues Passwort speichern, mit dem du dich zukünftig in der Gradido-App anmelden kannst." + * Label "neues Passwort" + * Label "neues Passwort wiederholen" + * Default-Text "neues Passwort" bei ungefüllten Eingabefeldern + * Button-Text "Passwort zurücksetzen" + * Linktext "zurück" + * Sprachauswahltexte + * Footer Copyright + * Footer Links: + * "Gradido-Akademie" + * "App-Version" + * "Impressum" + * "Datenschutzerklärung" + * "Mitgliederbereich" + * "Whitepaper" + * "Support" + + + + +8. **Prüfung der Eingabedynamik in der 2ten Passwort-Zurücksetzen-Maske:** + + 1. Eingabefeld "Neues Passwort": + + 1. mindestens ein Zeichen + 2. maximale Länge eines Passwortes? + 3. Sichtbarschaltung und Verdeckung des eingegebenen Passwortes + 2. Eingabefeld "Neues Passwort wiederholen": + + 1. mindestens ein Zeichen + 2. maximale Länge eines Passwortes? + 3. Sichtbarschaltung und Verdeckung des eingegebenen Passwortes + 3. Sprachauswahl: + + 1. entsprechen alle angezeigten Texte der aktuell eingestellten Sprache? + 2. Umstellung der Sprache über die Sprachauswahl-Box + 3. Wiederholung von Schritt 8.3.1 und 8.3.2 bis alle verfügbaren Sprachen geprüft sind + 4. Link "Zurück" ist aktiv und landet auf URL + + 1. Testumgebung: https://stage1.gradido.net/vue/Login + 2. Produktionsumgebung: https://gradido.net/vue/Login + 5. Footer-Links: + + 1. "Gradido-Akademie" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de" + 2. "App-Version" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://github.com/gradido/gradido/releases/latest" + 3. "Impressum" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/impressum/" + 4. "Datenschutzerklärung" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/datenschutz/" + 5. "Mitgliederbereich" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://elopage.com/s/gradido/sign_in?locale=de" + 6. "Whitepaper" reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://docs.google.com/document/d/1jZp-DiiMPI9ZPNXmjsvOQ1BtnfDFfx8BX7CDmA8KKjY/edit?usp=sharing" + 7. "Support"reagiert und landet je nach aktuell eingestellter Sprache auf URL "https://gradido.net/de/contact/" + + +Bei erfolgreichem Passwort-Reset wird eine Email an der die URL angezeigt + +* Testumgebung: "https://stage1.gradido.net/vue/overview" +* Produktionsumgebung: "https://gradido.net/vue/overview" + +Bei fehlerhaftem Login wird eine entsprechend aussagekräftige Fehlermeldung angezeigt und die Anzeige verbleibt auf der Login-Maske. + +## Ende-Bedingungen: + +*Welche Bedingungen werden am Ende des Testfalles bei positivem Ergebnis erwartet? (Daten/ GUI/ Zustände/ etc)* + +Der Login-Prozess wurde erfolgreich durchlaufen. + +Alle zu überprüfende Schritte des Login-Prozesses sind erfolgreich abgeschlossen. + +Es wird die Übersichtseite des angemeldeten Mitglieds angezeigt. + +## erwartete Fehlerfälle: + +*Welche Fehlerfälle können auftreten und wie ist das erwartete Verhalten/ Rückgabewerte/ Fehlercode?* + +nicht registrierte Nutzerdaten in Eingabefeld "Email" und/oder "Passwort": + +* ungültiger Login -> Fehlermeldung "Leider konnten wir keinen Account finden mit diesen Daten!" diff --git a/docu/Concepts/Testfallkatalog/Testfall-Vorlage.md b/docu/Concepts/Testfallkatalog/Testfall-Vorlage.md new file mode 100644 index 000000000..14a971911 --- /dev/null +++ b/docu/Concepts/Testfallkatalog/Testfall-Vorlage.md @@ -0,0 +1,27 @@ +# Testfall: "*Dateiname*" + +## Thema: "*Name des Verzeichnisses*" + +## ## Beschreibung: + +*Welche(n) Anwendungsschritt/Oberfläche/Logik ist durch den Testfall betroffen?* + + +## Vorraussetzungen: + +*Welche Vorraussetzungen (Daten/Anwendungschritte, etc.) müssen erfüllt sein, um den Testfall durchführen zu können?* + + +## Testfall-Schritte: + +*Welche Schritte müssen zur Durchführung des Testfalles getätigt werden? (Dateneingaben/ Navigationen/ Link- o Button-Klicks/ Schritte der Anwendungslogik/ etc.)* + + +## Ende-Bedingungen: + +*Welche Bedingungen werden am Ende des Testfalles bei positivem Ergebnis erwartet? (Daten/ GUI/ Zustände/ etc)* + + +## erwartete Fehlerfälle: + +*Welche Fehlerfälle können auftreten und wie ist das erwartete Verhalten/ Rückgabewerte/ Fehlercode?* diff --git a/docu/Concepts/Testfallkatalog/image/C001-01-LoginMaske.png b/docu/Concepts/Testfallkatalog/image/C001-01-LoginMaske.png new file mode 100644 index 000000000..632f58f8a Binary files /dev/null and b/docu/Concepts/Testfallkatalog/image/C001-01-LoginMaske.png differ diff --git a/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske1.png b/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske1.png new file mode 100644 index 000000000..59bd2fd03 Binary files /dev/null and b/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske1.png differ diff --git a/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske2.png b/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske2.png new file mode 100644 index 000000000..2ef79ec60 Binary files /dev/null and b/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske2.png differ diff --git a/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske3.png b/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske3.png new file mode 100644 index 000000000..a3f069fa9 Binary files /dev/null and b/docu/Concepts/Testfallkatalog/image/C001-03-LoginMaske3.png differ