mirror of
https://github.com/IT4Change/gradido.git
synced 2025-12-13 07:45:54 +00:00
#751 Änderungen auf Federation und Community-Erstellprozess
This commit is contained in:
Claus-Peter Hübner
parent
4a6dc733a4
commit
1cd35feb80
@ -4,66 +4,89 @@ Diese Konzept beschreibt den Begriff "Community" im Kontext von Gradido, welche
|
||||
|
||||
## 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").
|
||||
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 also einerseits gemäß der Gradido-Philosophie der *Natürlichen Ökonomie des Lebens* und andererseits ihrer ursprünglichen Idee eine Gemeinschaft zu bilden.
|
||||
|
||||
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.
|
||||
Als Gradido System-Komponente beinhaltet die *Community* die grundlegenden Funktionalitäten und Prozesse zur Verwaltung der Gruppenmitglieder, ihrer Registrierungs- und Systemzugriffe, die Konten- und Geldverwaltung einerseits und andererseits die Funktionalitäten und Prozesse zur Vernetzung und Kommunikation von mehreren Communities untereinander .
|
||||
|
||||
Innerhalb der Community-Komponente 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 (AktivesGrundeinkommenkonto, 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.
|
||||
Hier werden die Eigenschaften einer Community beschrieben, die notwendig sind, um die oben erwähnten Möglichkeiten der Komponente zu erfüllen. Es geht dabei um verschiedene Themen und ihre dazu notwendigen Prozesse, die wiederum unter Verweiß in anderen Dokumenten detailter beschrieben sind.
|
||||
|
||||
### Währung
|
||||
|
||||
In einer Community werden die Prozesse der 3-fachen-Geldschöpfung, sowie der Transfer von Geld in der *Gradido-Währung* ablaufen. Mit dem Erstellen einer neuen Community wird technisch gesehen gleichzeitig auch eine eigene *Community-Gradido* Währung bei der Schöpfung erzeugt.
|
||||
|
||||
Ziel dieser Community eigenen Währung ist für die Gemeinschaft über ein Währungs-Branding sich marketingstechnisch hervorheben zu können. Zum Beispiel könnte eine Community aus der Region "Liebliches Taubertal" sich über den *Community-Gradido* den sogenannten "Taubertäler" erzeugen, den die Mitglieder dann aber auch überregional mit anderen Communities in Umlauf bringen und somit Werbung für ihre Region machen.
|
||||
|
||||
Andererseits soll aber, wenn eine Community sich bei der Geldschöpfung nicht an die Regel der *Gradido-Philosopie* hält, eine technische Möglichkeit geschaffen sein, dass diese Community in ihrer weiteren Geldschöpfung und dem Handel *ihrer* Währung sanktioniert werden kann.
|
||||
|
||||
Aber grundsätzlich bleibt bei allen *Community-Gradido*-Währungen die Vergänglichkeit als Sicherungsmechanismus des Geldvolumens und der 1:1 Umtausch zwischen verschiedenen *Community-Gradidos* bestehen.
|
||||
|
||||
#### Schutz vor Falschgeld
|
||||
|
||||
- Blacklisting
|
||||
- Bereinigung durch Bezahlen nach Priorisierung
|
||||
- 1. GDD von der Community des Empfängers
|
||||
2. GDD von anderen Communities nach Menge von wenig nach viel
|
||||
3. GDD von der eigenen Community
|
||||
4. geblacklistete werden gar nicht verwendet und vergehen
|
||||
|
||||
* Vergänglichkeitsbereinigung
|
||||
* 1. GDD anderer Communities nach Menge von wenig nach viel
|
||||
|
||||
Bezahl-Vorbereitung
|
||||
|
||||
- Austausch von Blacklist zw. Teilnehmer
|
||||
- ggf. Übersteuern der Balcklist falls gewünscht
|
||||
-
|
||||
|
||||
### 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.
|
||||
Da es also mehrere Communities geben wird, benötigt jede Community ihren eigenen Namen und gar ein Symbol oder Bild, um eine optische Unterscheidung oder gar eigenes Branding 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).
|
||||
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 Vorteile durch zum Beispiel mehrfache Geldschöpfung in mehreren Communities verschafft. Die Details der Mitgliederverwaltung werden beschrieben im Dokument [BenutzerVerwaltung](.\BenutzerVerwaltung.md).
|
||||
|
||||
### Community-Vernetzung
|
||||
### Community-Netzwerk
|
||||
|
||||
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.
|
||||
Ein grundlegender Ansatz des Gradido-Systems beinhaltet die Einstufung aller beteiligten Gradido-Communities als gleichberechtigte Einheiten. Diese bilden unterneinander ein Kommunikations-Netzwerk zum Austausch an Informationen, aber auch zum Aufbau eines gemeinsamen Verbundes weiterer Aktivitäten.
|
||||
|
||||
Zum besseren Verständnis der Community-Vernetzung erfolgt hier eine Beschreibung der möglichen Konstellationen, wie sich Communities miteinander verbinden können.
|
||||
#### Vernetzung
|
||||
|
||||
#### Community Modelle
|
||||
Die Vernetzung der Gradido-Communities erfolgt automatisch über eine Channel-Infrastruktur.
|
||||
|
||||
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 bedeutet mit dem Aufsetzen und Inbetriebnehmen einer neuen Community erfolgt eine automatisierte Vernetzung der neuen Community mit den schon existierenden Communities über einen dedizierten Kommunikationskanal. Dies dient in aller erster Linie dazu, dass sich alle Gradido-Communities untereinander kennen lernen. Das dadurch entstehende Netzwerk von Gradido-Communities benötigt somit keinen zentralen Knoten, der die Verwaltung der dem Netzwerk beigetretenen Instanzen übernehmen müsste.
|
||||
|
||||
Das nachfolgende Bild zeigt einen ersten Eindruck über die unterschiedlichen Community-Modelle:
|
||||
|
||||
|
||||
|
||||
Alle späteren Aktivitäten wie u.a. das gemeinsame Handeln oder Gradido-Transfer erfolgen dann in direkter Kommunikation zwischen zwei Communities. Dabei lauschen die Communities an nach fachlichen Themen separierte Kommunikationskanäle. Sobald eine direkt an eine Community adressierte oder auch wenn eine für eine Community interessante Nachricht empfangen wird, erfolgt die weitere Verarbeitung dieser Nachricht in direktem Austausch der beiden betroffenen Communities. Durch die Teilnahme einer Community an spezifischen fachlichen Kommunikationskanäle lernen sich die Communities untereinander an ihren spezifischen Interessen besser kennen bzw. können auch durch aktives Propagieren die engere Vernetzung zwischen den Communities beschleunigen.
|
||||
|
||||
##### 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.
|
||||
#### Ausfallsicherheit
|
||||
|
||||
##### Gegenseitig vertrauende Communities
|
||||
Ein weiterer wichtiger Aspekt der Community-Vernetzung ist die Sicherstellung der Ausfallsicherheit. Dabei erfolgt im Community-Netzwerk die Verteilung von Community eigenen Daten auf Knoten anderer Communities. Dadurch kann jederzeit bei einem Ausfall eines Netzwerkknotens und den damit betroffenen Communities einerseits ein online Fail-Over-Szenario betrieben werden und/oder andererseits der Wiederaufbau eines neuen Knotens mit den verlorenen Community-Daten und aus dem Netzwerk wiederhergestellten Daten erfolgen.
|
||||
|
||||
*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.*
|
||||
#### Eindeutige Mitgliedschaft
|
||||
|
||||
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 zur 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.
|
||||
Durch das Community-Netzwerk erfolgt auch der sehr wichtige Prozess der Sicherstellung, dass eine natürliche Person sich nur einmal bei einer Community im gesamten Community-Netzwerk registrieren darf. Dazu erfolgt ein Informationsaustausch über einen bestimmten Kommunikationskanal zwischen allen Communities untereinander. Das dazu notwendige Protokoll und die benötigten Daten werden im technischen Konzept definiert. Die Entscheidung, ob die Überprüfung der eindeutigen Mitgliedschaft direkt mit dem eigentlichen Registrierungsprozess eines Mitglieds gekoppelt werden kann oder ob diese nachträglich asynchron im Hintergrund stattfinden muss, findet erst bei der technischen Konzeption ggf. durch ein technisches Proof-of-Concept statt.
|
||||
|
||||
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 Kapitel **Anwendungsfälle** beschrieben.
|
||||
### Hirarchische Community
|
||||
|
||||
##### 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.*
|
||||
|
||||
Das Modell der *abhängigen Communities* findet seinen Ursprung den Föderalismus von Deutschland in einer Community-Struktur abbilden zu können. Das bedeutet, dass eine baumartige Struktur von Communities aufgebaut werden kann, wie nachfolgendes Bild schemenhaft zeigt:
|
||||
Um die Vision Gradido als Währung nicht nur in Communities als gemeinsame Interessensgemeinschaften zu etablieren, sondern auch für ganze Communen, Bundesländer, Nationen oder gar weltweit, bedarf es einer Strukturierung von Communities. Dazu dient das Konzept der *hierarchischen Community*, seinen Ursprung in der Abbildung des Föderalismus von Deutschland findet. Das bedeutet, dass eine baumartige Struktur von Communities aufgebaut werden kann, wie nachfolgendes Bild schemenhaft zeigt:
|
||||
|
||||
|
||||
|
||||
Es wird somit zwischen zwei Communities aus benachbarten Ebenen eine Parent-Child-Beziehung erzeugt. Dadurch gehen diese beiden Communities eine besondere Beziehung untereinander ein, die zu folgenden veränderten Eigenschaften und Verhalten der Parent- und der Child-Community führen:
|
||||
Es wird somit zwischen zwei Communities aus direkt benachbarten Ebenen eine Parent-Child-Beziehung erzeugt. Dadurch gehen diese beiden Communities eine besondere Beziehung untereinander ein, die zu folgenden veränderten Eigenschaften und Verhalten der Parent- und der Child-Community führen:
|
||||
|
||||
###### Parent-Community
|
||||
#### Parent-Community
|
||||
|
||||
* kann 1 bis n Child-Communities besitzen
|
||||
* verwaltet keine Mitglieder mit AGE-Konto
|
||||
@ -73,14 +96,14 @@ Es wird somit zwischen zwei Communities aus benachbarten Ebenen eine Parent-Chil
|
||||
* bedarf spezieller Administrationsprozesse zur Verwaltung der Parent-Aufgaben:
|
||||
* Auf- und Abbau der Parent-Child-Beziehung
|
||||
* Verschiebung aller Mitglieder von der Parent- in die Child-Community
|
||||
* Stoppen des Sicherstellungsprozesses, dass eine *natürliche Person* nur Mitglied einer einzigen Community ist, sobald die erste Child-Beziehung aufgebaut ist und alle Mitglieder dahin verschoben sind
|
||||
* Stoppen des Sicherstellungsprozesses, dass eine *natürliche Person* nur Mitglied einer einzigen Community ist, sobald die erste Child-Beziehung aufgebaut ist und alle Mitglieder dorthin verschoben sind
|
||||
* Prozess zur Aufnahme der geschöpften Allgemeinwohl- und AUF-Gelder aus den Child-Communities
|
||||
* stoppt den Schöpfungsprozess sobald eine Child-Beziehung aufgebaut ist
|
||||
* startet den Schöpfungsprozess sobald die letzte Child-Beziehung aufgelöst ist
|
||||
* Aufnahmeprozess von Mitgliedern aus einer Child-Community, bevor dessen Beziehung aufgelöst wird
|
||||
* starten des Sicherstellungsprozesses, dass eine *natürliche Person* nur Mitglied einer einzigen Community ist, sobald die letzte Child-Beziehung aufgelöst ist
|
||||
|
||||
###### Child-Community
|
||||
#### Child-Community
|
||||
|
||||
* besitzt genau eine Parent-Community
|
||||
* **sofern es eine Community der untersten Ebene ist:**
|
||||
@ -94,32 +117,32 @@ Es wird somit zwischen zwei Communities aus benachbarten Ebenen eine Parent-Chil
|
||||
* hier läuft der Prozess zur Sicherstellung, dass eine *natürliche Person* nur Mitglied einer einzigen (Child)-Community ist
|
||||
*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
##### 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.
|
||||
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 teilweise 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 die Dreifach-Geldschöpfung verwaltet die Community drei Arten von Konten: das AktiveGrundeinkommen-Konto pro Mitglied, das Community-eigene Gemeinwohlkonto und das Community-eigene 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.
|
||||
Für jedes Mitglied der Community wird also ein eigenes AktiveGrundeinkommen-Konto verwaltet, auf das ein Drittel der monatlichen Geldschöpfung unter Einhaltung der AGE-Regeln 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.
|
||||
Somit muss also eine Community für jede Kontoart die entsprechenden Kontoverwaltungsprozesse anbieten. Einmal in Verbindung pro Mitglied für das AGE-Konto 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 AGE-Konten 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.
|
||||
|
||||
### Tätigkeitsverwaltung
|
||||
|
||||
Hier handelt es sich um eine Verwaltung von Tätigkeitsbeschreibungen, die von den Community-Mitgliedern als akzeptierte und berechtigte Leistungen zur Geldschöpfung als *Aktives Grundeinkommen* angesehen werden. Das heißt die Community muss unter den Mitgliedern eine Liste erarbeiten, die alle Tätigkeiten enthält, aus denen sich ein Mitglied dann eine oder mehrere auswählen kann, um sich sein Aktives Grundeinkommen damit zu decken. Die einzelnen Tätigkeiten sollen auch fachlich strukturierbar sein z.B. Kunst, Soziales, Gesundheit, Produktion, etc. . Die Menge und Definition der einzelnen Tätigkeiten und Strukturen unterliegt einer stetigen Anpassung nach den Bedürfnissen der Community-Mitglieder, um den natürlichen Veränderungen des miteinander Lebens gerecht werden zu können. Ob zu einer Tätigkeitsbeschreibung auch gleich eine Wertigkeit definiert werden soll, ist noch offen. Man kann aber sicherlich sagen, dass manche Tätigkeiten dem Gemeinwohl dienlicher sind als andere. Aber auch das ist wiederum eine Ansichtsache und muss unter den Community-Mitgliedern vereinbart werden.
|
||||
|
||||
Zu der Liste der Tätigkeiten gibt es einen weiteren Prozess, der in dem Dokument [RegelnDerGeldschoepfung](./RegelnDerGeldschoepfung.md) näher beschrieben ist. Hier kann soviel erst einmal gesagt werden, dass die Tätigkeitenliste als Grundlage dient, damit ein Mitglied für seine erbrachten Leistungen für das Allgemeinwohl dann sein monatliches *Aktives Grundeinkommen* gutgeschrieben bekommt. Dieses Gutschreiben des AGEs unterliegt noch einer vorherigen Bestätigung von anderen Community- oder auch Community übergreifenden Mitgliedern. Somit erfolgt dadurch eine implizite Vernetzung der Mitglieder durch dieses aktive Bestätigen anderer Leistungen, was gleichzeitig wieder Vorraussetzung ist, um sein eigenes AGE zu erhalten.
|
||||
|
||||
### 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.
|
||||
|
||||
### Vernetzung und Vertrauensbildung
|
||||
|
||||
Mit der Vernetzung der Communities und dem gemeinsamen Handel zwischen Community-Mitgliedern innerhalb des gesamten Netzwerks entsteht automatisch ein Vertrauensverhältnis zwischen den verschiedenen Communities und auch zwischen den Community-Mitgliedern. Diese sich dynamisch verändernde Vertrauensverhältnisse können als Graph aufbereitet und zu weiteren Auswertungen bzw. Priorisierungen von fachlichen Prozessen herangezogen werden. Da in dem Gradido-Netzwerk der Mensch und das gegenseitige Vertrauen im Mittelpunkt steht, benötigt er für seine Bewertungen und Entscheidungen von Handel und Austausch mit anderen Communities bzw. anderen Mitgliedern ein Werkzeug, das ihm diese Informationen liefern kann. Das bedeutet in der Gradido-Anwendung werden statistische Werte über die Kommunikation zwischen Communities und zwischen Mitgliedern erhoben, die als Grundlage für den Vertrauensgraphen dienen.
|
||||
|
||||
### Attribute einer Community
|
||||
|
||||
In diesem Kapitel werden die Attribute beschrieben, die in einer Community zu speichern sind.
|
||||
@ -166,27 +189,39 @@ Das Attribut *Parent* dient für den hierarchischen Aufbau von Communities. Es e
|
||||
|
||||
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 Administrator 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 Referenzen 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.. Zwischen zwei *Trusted Communities* erfolgt keine Verteilung gemäß einem Verteilungsschlüssel von geschöpftem Geld das für das Allgemeinwohl- bzw. AUF-Konto bestimmt ist. Dies bleibt Eigentum jeder Community trotz vertrauenswürdiger Beziehung untereinander.
|
||||
|
||||
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 im nachfolgenden Kapitel **Anwendungsfälle auf einer Community** zu finden.
|
||||
|
||||
|
||||
## 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.*
|
||||
Der Prozess *Neue Community erstellen* kann in zwei grundlegende Schritte untergliedert werden. Im ersten Schritt erfolgt der Aufbau und die Einrichtung der technischen Infrastruktur, die für den Betrieb der neuen Community benötigt wird. Im zweiten Schritt wird dann die eigentliche Inbetriebnahme der neuen Community durchgeführt, bei der die notwendigen Registrierungsschritte für den fachlichen Austausch an Informationen zwischen den schon bestehenden Communities und der neuen Community erfolgt. Der erste Schritt wird hier im Kapitel Vorraussetzungen beschrieben. Der zweite Schritt dieses Prozesse erfolgt als Ablaufbeschreibung der Registrierungsschritte im Kapitel Ablauf.
|
||||
|
||||
#### Vorraussetzungen
|
||||
|
||||
Um eine neue Community zu erstellen wird eine dafür speziell konzepierte Infrastruktur benötigt. Die technischen Details dieser Infrastruktur werden in der *technischen Infrastruktur Beschreibung* als eigenständiges Dokument dem Administrator der neuen Community zur Verfügung gestellt. Diese ist neben den Installationsskripten und Anwendungsdateien Teil des Auslieferungspaketes der Gradido-Anwendung.
|
||||
|
||||
Sobald der Administrator die geforderte Infrastruktur in Betrieb genommen und darauf die entsprechenden Installationsskripte ausgeführt hat erfolgt die eigentliche Erstellung und Registrierung der neue Community. Das heißt beim erstmaligen Start der Gradido-Anwendung wird automatisch der Prozess *Neue Community erstellen* gestartet.
|
||||
|
||||
#### Ablauf
|
||||
|
||||
Der Prozess *Neue Community erstellen* wird entweder automatisiert beim erstmaligen Start der Gradido-Anwendung auf einer neuen Infrastruktur gestartet oder manuell, wenn eine neue Community auf einer schon bestehenden Infrastruktur zusätzlich eingerichtet werden soll. Die nachfolgende Ablaufgrafik zeigt die logischen Schritte, die in dem Prozess durchlaufen werden:
|
||||
|
||||
|
||||
|
||||
#### Ende Status
|
||||
|
||||
1. Community-Infrastruktur ist installiert und aktiv
|
||||
2. neue Community ist erzeugt und Daten in der Community-DB gespeichert
|
||||
3. der Hintergrundprozess "Community-Vernetzung" ist am Laufen
|
||||
* die initiale "newCommunity-Msg" mit den eigenen Community-Daten ist in den Public-Channel versendet
|
||||
* ein Listener lauscht am Public-Channel auf Antworten (replyNewCommunityMsg) der schon existenten Communities
|
||||
* ein Listener lauscht am Public-CHannel auf initiale "newCommunity-Msg" anderer neuer Communities
|
||||
4. mit dem ersten Empfangen einer Reply-Msg einer anderen Community, wird der Community-Connection Prozess gestartet, der mit jedem Empfang von neuen Community-Daten eine P2P-Verbindung zu dieser Community aufbaut, um direkt detaillierte Daten auszutauschen
|
||||
5. die vordefinierte Tätigkeitsliste ist geladen
|
||||
6. die vordefinierten Berechtigungen sind aktiv
|
||||
7. optional sind schon Mitglieder erfasst und in der Datenbank gespeichert
|
||||
|
||||
#### Fehlerfälle
|
||||
|
||||
### Community bearbeiten
|
||||
@ -260,3 +295,72 @@ Die nachfolgenden Anwendungsfälle beschreiben die fachlichen Vorraussetzungen,
|
||||
#### Ende Status
|
||||
|
||||
#### Fehlerfälle
|
||||
|
||||
# Besprechung 19.08.2021 19:00 mit Bernd
|
||||
|
||||
## Kreis-Mensch-Sein-Community
|
||||
|
||||
Felix Kramer
|
||||
|
||||
noch keine eigene Währung, wollen gerne Gradido
|
||||
|
||||
haben auch aktives Grundeinkommen
|
||||
|
||||
passt aber nicht ganz zur Gradido Philosophie, weil Gemeinwohlleistung zu unterschiedlich bewertet werden.
|
||||
|
||||
-> Colored Gradido?
|
||||
|
||||
Community-Creation
|
||||
|
||||
GDD1 (gold) ist existent
|
||||
|
||||
Felix baut GGD2-Infrastruktur auf
|
||||
|
||||
* Frage: willst du GDD1(gold) oder eigene Währung?
|
||||
* Antwort: nein ich will eigene GDD2 (rot)
|
||||
* muss neue Währung erzeugen
|
||||
* Antwort: ja, dann Anfrage an GDD1, dass GDD2 auch Goldene GDD1 schöpfen darf?
|
||||
* Ja wird akzeptiert
|
||||
* dann bekommt GDD2 die Lizenz goldene GDD1 schöpfen kann
|
||||
|
||||
Kommt später heraus, dass GDD2 nicht mehr den goldenen Regeln entspricht, dann muss die Lizenz zum goldene GDD1 Schöpfen für GDD2 gesperrt werden.
|
||||
|
||||
Bisher geschöpfte goldene GDD2 beleiben aber erhalten.
|
||||
|
||||
Es darf keine Markierung des Bot-Mitglieds geben, da Missbrauch/Fehler möglich
|
||||
|
||||
Identität für ein Mitglied muss Human/Nichthuman enthalten
|
||||
|
||||
GDD2 muss mit Lizenzentzug wechseln auf eigene Währung um weiterschöpfen zu können.
|
||||
|
||||
Mitgliederwechsel in andere Community muss dann auch Währungswechsel berücksichtigen.
|
||||
|
||||
Bestcase: 1 Blockchain pro Währung
|
||||
|
||||
GDD1(gold) existent
|
||||
|
||||
GDD2(gold) soll gegründet werden
|
||||
|
||||
GDD2 baut Infrasturktur auf
|
||||
|
||||
Frage an GDD2, ob goldene oder andere?
|
||||
|
||||
### Tätigkeiten, die von der Community aktzeptiert werden
|
||||
|
||||
Nachweise für durchgeführte Tätigkeiten, bevor diese dem AGE-Konto gutgeschrieben werden?
|
||||
|
||||
Liste der Tätigkeiten muss von Community erstellt, bestätigt und verwaltet werden
|
||||
|
||||
Bei Tätigkeit von x Stunden für das AGE muss aus der Liste die passende Tätigkeit gewählt werden und per Nachweis (andere Mitglieder, Video, o.ä.)
|
||||
|
||||
Bei Krankheit o.ä. muss es aber möglich sein, dass dennoch Geld auf das AGE-Konto kommt.
|
||||
|
||||
Kontaktförderung durch gewichtete Tätigkeitsbestätigung ( bei mind. 2 Bestätigungen pro Tätigkeit muss mind. ein neues Mitglied dabei sein)
|
||||
|
||||
Liste von Mitgliedern, die ich bestätigt habe:
|
||||
|
||||
* Kontaktpflege
|
||||
* Gewichtung
|
||||
* Vernetzung
|
||||
|
||||
Ricardo Leppe Podcast Lern und Memotechniken
|
||||
|
||||
@ -1,3 +1,22 @@
|
||||
# Regeln der Geldschöpfung
|
||||
|
||||
*Hier werden die fachlichen Regeln der 3-fachen Schöpfung beschrieben*
|
||||
Nach der Gradido-Philosophie erfolgt pro Monat der Prozess der Dreifachen-Geldschöpfung. Das bedeutet, dass in einer Gradido-Community pro Mitglied, das eine *natürliche Person* ist, eine maximale Summe von 3.000 GDD geschöpft wird. Davon kann das Mitglied 1.000 GDD als *Aktives Grundeinkommen* durch Community nützige Leistungen auf sein persönliches AGE-Konto erhalten. 1.000 GDD werden auf das Gemeinwohlkonto der Community gutgeschrieben und weitere 1.000 GDD fließen auf das AUF-Konto der Community.
|
||||
|
||||
Um diese Schritte des Geldschöpfungsprozesses zu gewährleisten bedarf es einiger Vorraussetzungen, die im folgenden beschrieben werden.
|
||||
|
||||
# Vorraussetzungen
|
||||
|
||||
## Drei Kontenmodell
|
||||
|
||||
## Verteilungsschlüssel
|
||||
|
||||
## Tätigkeitsliste für Aktives Grundeinkommen
|
||||
|
||||
Die Tätigkeitsliste für das AGE dient als Grundlage der gemeinnützigen Leistungen, die ein Mitglied sich anrechnen lassen kann. Das heißt eine Community muss eine Sammlung von Tätigkeiten erfassen, die von den Community-Mitgliedern als gemeinnützig empfunden und bestätigt werden. D
|
||||
|
||||
Das heißt die Community muss unter den Mitgliedern eine Liste erarbeiten, die alle Tätigkeiten enthält, aus denen sich ein Mitglied dann eine oder mehrere auswählen kann, um sich sein Aktives Grundeinkommen damit zu decken. Die einzelnen Tätigkeiten sollen auch fachlich strukturierbar sein z.B. Kunst, Soziales, Gesundheit, Produktion, etc. . Die Menge und Definition der einzelnen Tätigkeiten und Strukturen unterliegt einer stetigen Anpassung nach den Bedürfnissen der Community-Mitglieder, um den natürlichen Veränderungen des miteinander Lebens gerecht werden zu können. Ob zu einer Tätigkeitsbeschreibung auch gleich eine Wertigkeit definiert werden soll, ist noch unklar. Man kann aber sicherlich sagen, dass manche Tätigkeiten dem Gemeinwohl dienlicher sind als andere. Aber auch das ist wiederum eine Ansichtsache und muss unter den Community-Mitgliedern vereinbart werden.
|
||||
|
||||
### Erstellung und Erfassung der Tätigkeiten
|
||||
|
||||
|
||||
# Prozess der Geldschöpfung
|
||||
|
||||
@ -0,0 +1,304 @@
|
||||
<mxfile>
|
||||
<diagram id="Lc_Wy6ZhKx3Be9Prl_QG" name="Page-1">
|
||||
<mxGraphModel dx="1088" dy="800" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1654" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0"/>
|
||||
<mxCell id="1" parent="0"/>
|
||||
<mxCell id="28" value="Community-Prozess" style="html=1;align=left;verticalAlign=top;absoluteArcSize=1;arcSize=18;dashed=0;spacingTop=10;spacingRight=30;strokeColor=#82b366;strokeWidth=2;fillColor=#d5e8d4;gradientColor=#97d077;fontColor=#000000;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="40" y="130" width="1220" height="910" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="27" value="Prozess: Community-Vernetzung" style="html=1;align=left;verticalAlign=top;absoluteArcSize=1;arcSize=18;dashed=0;spacingTop=10;spacingRight=30;strokeColor=#6c8ebf;strokeWidth=2;fillColor=#dae8fc;gradientColor=#7ea6e0;fontColor=#000000;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="610" y="264.5" width="640" height="555.5" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="30" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontColor=#000000;strokeColor=#000000;" parent="1" source="2" target="4" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="185" y="170"/>
|
||||
<mxPoint x="250" y="170"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="2" value="automatisch beim 1.Start der Anwendung" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="170" y="40" width="30" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="31" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;fontColor=#000000;strokeColor=#000000;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="3" target="4" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="250" y="210" as="targetPoint"/>
|
||||
<Array as="points">
|
||||
<mxPoint x="405" y="170"/>
|
||||
<mxPoint x="250" y="170"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="77" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="3" target="75">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="405" y="170"/>
|
||||
<mxPoint x="450" y="170"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="95" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.75;entryY=0;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="3" target="38">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="560" y="70"/>
|
||||
<mxPoint x="560" y="790"/>
|
||||
<mxPoint x="485" y="790"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="3" value="manuell durch Administrator" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="390" y="40" width="30" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="6" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#000000;" parent="1" source="4" target="5" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="4" value="Initialisiere Prozess <br>"Neue Community erstellen"" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="150" y="202.63" width="200" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="8" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#000000;" parent="1" source="5" target="7" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="5" value="Attribute der Community erfassen <br>bzw. aus Config lesen<br><div style="text-align: left"><span>- Name</span></div><div style="text-align: left"><span>- Icon / Bild (opt.)</span></div><div style="text-align: left"><span>- Beschreibung</span></div><div style="text-align: left"><span>- hosted Server / URL</span></div><div style="text-align: left"><span>- Währungsname (opt.)</span></div><div style="text-align: left"><span>- Währungskürzel (opt.)</span></div>" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="150" y="280" width="200" height="120" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="12" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;strokeColor=#000000;exitX=0.75;exitY=0;exitDx=0;exitDy=0;" parent="1" source="24" target="13" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="520" y="420" as="targetPoint"/>
|
||||
<Array as="points">
|
||||
<mxPoint x="425" y="451"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="51" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#1A1A1A;" edge="1" parent="1" source="7" target="50">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="7" value="erzeuge techn. Community-Keys:<br><div style="text-align: left"><span>- Community-ID</span></div><div style="text-align: left"><span>- Community-Currency-ID</span></div>" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="150" y="423.13" width="200" height="60" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="17" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#000000;" parent="1" source="13" target="16" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="70" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="13" target="72">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="785" y="364.5"/>
|
||||
<mxPoint x="785" y="364.5"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="74" value="Nein" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=14;fontColor=#000000;labelBackgroundColor=#B0E3E6;rounded=1;" vertex="1" connectable="0" parent="70">
|
||||
<mxGeometry x="-0.2906" y="-1" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="13" value="Community-Attribute: (Name, Community-ID, URL) vorhanden?" style="rhombus;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;align=center;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="690" y="410.5" width="190" height="80" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="19" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#000000;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="16" target="20" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="785" y="517.13" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="16" value="Sende Community-Attribute<br>auf public Channel" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="960" y="429.76" width="210" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="83" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="20" target="80">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="20" value="lausche an public Channel<br>auf<br>"replyNewCommuntiy-Msg"<br>"newCommuntiy-Msg"" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="960" y="511.62999999999994" width="210" height="65" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="25" value="" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#000000;entryX=0;entryY=0.5;entryDx=0;entryDy=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" parent="1" source="22" target="20" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="910" y="544"/>
|
||||
<mxPoint x="910" y="544"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="22" value="speichere empfangene<br>Community-Daten in<br>Community-DB" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="690" y="516.6299999999999" width="210" height="55" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="24" value="Starte Community-Vernetzung <br>als Hintergrundprozess" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="290" y="622.63" width="180" height="39.5" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="37" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;fontColor=#000000;strokeColor=#000000;" parent="1" source="34" target="36" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="34" value="Lade <br>Default-Tätigkeitsliste,<br>Standard-Berechtigungen,<br>etc." style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="130" y="607.38" width="140" height="70" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="46" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;fontColor=#000000;strokeColor=#000000;" parent="1" source="36" target="39" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="47" value="Ja" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontColor=#000000;rounded=1;labelBackgroundColor=#97D077;" parent="46" vertex="1" connectable="0">
|
||||
<mxGeometry x="0.24" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="48" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;fontColor=#000000;strokeColor=#000000;" parent="1" source="36" target="43" edge="1">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="49" value="Nein" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontColor=#000000;rounded=1;labelBackgroundColor=#97D077;" parent="48" vertex="1" connectable="0">
|
||||
<mxGeometry x="0.2056" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="36" value="neue Mitglieder<br>erfassen?" style="rhombus;whiteSpace=wrap;html=1;fontColor=#ffffff;strokeColor=#2D7600;strokeWidth=2;fillColor=#60a917;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="130" y="754.5" width="140" height="80" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="38" value="Community-Prozess" style="html=1;align=left;verticalAlign=top;absoluteArcSize=1;arcSize=18;dashed=0;spacingTop=10;spacingRight=30;strokeColor=#82b366;strokeWidth=2;fillColor=#d5e8d4;gradientColor=#97d077;fontColor=#000000;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="290" y="834.5" width="260" height="120" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="45" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontColor=#FFFFFF;strokeColor=#000000;" parent="1" source="39" target="43" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="510" y="990"/>
|
||||
<mxPoint x="200" y="990"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="39" value="Prozess <br>"Neuen Benutzer anlegen"" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="330" y="874.5" width="200" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="43" value="" style="ellipse;html=1;shape=endState;fillColor=#000000;strokeColor=#000000;labelBackgroundColor=#97D077;fontColor=#FFFFFF;rounded=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="185" y="1060" width="30" height="30" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="53" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0.514;entryDx=0;entryDy=0;entryPerimeter=0;strokeColor=#1A1A1A;" edge="1" parent="1" source="50" target="52">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="50" value="speichere Community-Daten <br>in Community-DB" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="150" y="503.13" width="200" height="39.5" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="54" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;strokeColor=#1A1A1A;exitX=0.374;exitY=0.232;exitDx=0;exitDy=0;exitPerimeter=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="52" target="24">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="302" y="596"/>
|
||||
<mxPoint x="380" y="596"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="55" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;strokeColor=#1A1A1A;exitX=-0.226;exitY=0.784;exitDx=0;exitDy=0;exitPerimeter=0;" edge="1" parent="1" source="52" target="34">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="52" value="" style="html=1;points=[];perimeter=orthogonalPerimeter;fillColor=#000000;strokeColor=none;rotation=90;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="250" y="480.13" width="5" height="185" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="62" value="newCommunity-Msg" style="html=1;shape=mxgraph.infographic.ribbonSimple;notch1=0;notch2=20;align=center;verticalAlign=middle;fontSize=14;fontStyle=0;fillColor=#d5e8d4;strokeColor=#82b366;fontColor=#000000;rounded=1;rotation=15;" vertex="1" parent="1">
|
||||
<mxGeometry x="1184.99" y="463.13" width="170" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="69" value="<font style="font-size: 12px">replyNewCommunity-Msg</font>" style="html=1;shape=mxgraph.infographic.ribbonSimple;notch1=20;notch2=0;align=left;verticalAlign=middle;fontSize=14;fontStyle=0;flipH=1;fillColor=#d5e8d4;strokeColor=#82b366;fontColor=#000000;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="1180.01" y="519.51" width="160" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="73" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;exitX=0;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="1" source="72" target="5">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="72" value="Fehlermeldung <br>wegen<br>fehlender Parameter" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;strokeColor=#2D7600;fillColor=#B0E3E6;fontColor=#000000;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="725" y="314.5" width="120" height="50" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="76" style="edgeStyle=orthogonalEdgeStyle;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" edge="1" parent="1" source="75" target="13">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="450" y="451"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="75" value="Starte Community-Vernetzung <br>als Hintergrundprozess" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#60a917;strokeColor=#2D7600;fontColor=#ffffff;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="360" y="202.63" width="180" height="39.5" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="79" value="<font style="font-size: 12px">newCommunity-Msg</font>" style="html=1;shape=mxgraph.infographic.ribbonSimple;notch1=20;notch2=0;align=left;verticalAlign=middle;fontSize=14;fontStyle=0;flipH=1;fillColor=#d5e8d4;strokeColor=#82b366;fontColor=#000000;rounded=1;rotation=0;" vertex="1" parent="1">
|
||||
<mxGeometry x="1180.01" y="546.39" width="160" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="81" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="80" target="22">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="82" value="Ja" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=14;fontColor=#000000;labelBackgroundColor=#7EA6E0;" vertex="1" connectable="0" parent="81">
|
||||
<mxGeometry x="-0.4267" y="2" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="85" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="80" target="84">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="80" value="replyNewCommunityMsg?" style="rhombus;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;align=center;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="970" y="588.76" width="190" height="47.87" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="93" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;exitX=0.499;exitY=0.966;exitDx=0;exitDy=0;exitPerimeter=0;" edge="1" parent="1" source="84" target="86">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="1065" y="717.8699999999999" as="sourcePoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="96" value="Ja" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=14;fontColor=#000000;labelBackgroundColor=#7EA6E0;" vertex="1" connectable="0" parent="93">
|
||||
<mxGeometry x="-0.2741" y="-1" relative="1" as="geometry">
|
||||
<mxPoint as="offset"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="84" value="NewCommunityMsg?" style="rhombus;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;align=center;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="970" y="650" width="190" height="47.87" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="94" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.25;entryY=1;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="86" target="22">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="86" value="Sende Community-Attribute<br>auf public Channel" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="960" y="730" width="210" height="40" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="89" value="replyNewCommunity-Msg" style="html=1;shape=mxgraph.infographic.ribbonSimple;notch1=0;notch2=20;align=left;verticalAlign=middle;fontSize=14;fontStyle=0;fillColor=#d5e8d4;strokeColor=#82b366;fontColor=#000000;rounded=1;rotation=-45;" vertex="1" parent="1">
|
||||
<mxGeometry x="1179.98" y="657.38" width="180.01" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="97" value="" style="group" vertex="1" connectable="0" parent="1">
|
||||
<mxGeometry x="1359.9950000000001" y="460.0049999999999" width="232.6199999999999" height="182.6300000000001" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="65" value="" style="shape=cylinder3;whiteSpace=wrap;html=1;boundedLbl=1;backgroundOutline=1;size=15;align=center;rotation=-90;strokeColor=#36393d;fillColor=#66B2FF;rounded=1;" vertex="1" parent="97">
|
||||
<mxGeometry x="24.99499999999989" y="-24.99499999999989" width="182.63" height="232.62" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="66" value="public Channel" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;fontColor=#000000;fontSize=14;rounded=1;" vertex="1" parent="97">
|
||||
<mxGeometry x="96.30500000000006" y="74.99500000000012" width="40" height="20" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="98" value="Prozess: Community-Connection" style="html=1;align=left;verticalAlign=top;absoluteArcSize=1;arcSize=18;dashed=0;spacingTop=10;spacingRight=30;strokeColor=#6c8ebf;strokeWidth=2;fillColor=#dae8fc;gradientColor=#7ea6e0;fontColor=#000000;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="610" y="834.5" width="640" height="185.5" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="106" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=1;entryY=0.5;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;fillColor=#ffffff;exitX=0.5;exitY=1;exitDx=0;exitDy=0;" edge="1" parent="1" source="99" target="105">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="99" value="stelle P2P-Verbindung zu <br>neuer Community her<br>und tausche detailiete Daten aus" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="974.99" y="881" width="210" height="67" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="102" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;" edge="1" parent="1" source="100" target="99">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="100" value="Daten einer neuen Community erhalten?" style="rhombus;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;align=center;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="637" y="874.5" width="190" height="80" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="101" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=0;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;exitX=0;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="1" source="22" target="100">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="670" y="544"/>
|
||||
<mxPoint x="670" y="790"/>
|
||||
<mxPoint x="732" y="790"/>
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="103" value="" style="shape=flexArrow;endArrow=classic;startArrow=classic;html=1;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;fillColor=#ffffff;" edge="1" parent="1">
|
||||
<mxGeometry width="100" height="100" relative="1" as="geometry">
|
||||
<mxPoint x="1190.01" y="914" as="sourcePoint"/>
|
||||
<mxPoint x="1340.01" y="914" as="targetPoint"/>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="104" value="neue Community" style="rounded=1;whiteSpace=wrap;html=1;labelBackgroundColor=none;fontSize=14;fontColor=#000000;fillColor=#B0E3E6;align=center;gradientColor=#97D077;" vertex="1" parent="1">
|
||||
<mxGeometry x="1359.99" y="840" width="240.01" height="160" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="107" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;fontSize=14;fontColor=#000000;strokeColor=#1A1A1A;fillColor=#ffffff;exitX=0;exitY=0.5;exitDx=0;exitDy=0;" edge="1" parent="1" source="105" target="100">
|
||||
<mxGeometry relative="1" as="geometry"/>
|
||||
</mxCell>
|
||||
<mxCell id="105" value="speichere empfangene<br>Community-Daten in<br>Community-DB" style="html=1;align=center;verticalAlign=top;absoluteArcSize=1;arcSize=10;dashed=0;fillColor=#b0e3e6;strokeColor=#0e8088;fontColor=#000000;rounded=1;" vertex="1" parent="1">
|
||||
<mxGeometry x="810" y="954.5" width="150" height="55" as="geometry"/>
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 273 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
docu/Concepts/BusinessRequirements/image/CommunityNetwork.png
Normal file
BIN
docu/Concepts/BusinessRequirements/image/CommunityNetwork.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 139 KiB |
Loading…
x
Reference in New Issue
Block a user