mirror of
https://github.com/IT4Change/gradido.git
synced 2026-02-06 09:56:05 +00:00
draft of technical usecase description
This commit is contained in:
parent
cf1a7adcd5
commit
3e4740bbe5
@ -36,8 +36,11 @@ Mit diesem Usecase soll es zukünftig möglich sein neben dem direkten *synchron
|
||||
|
||||
* **asynchrones Senden online**: Es wird im ersten Schritt "nur" ein asynchrones Senden mit Internet-Verbindung (online) unterstützt. Dadurch ist es möglich die zusendenden Daten auf einen einfachen Identifier zu reduzieren. Der Empfänger der Daten muss zur Überprüfung der erhaltenen Daten online sein, da mit dem einfachen Identifier dann erst die eigentlichen fachlichen Daten der Transaktion ausgelesen und angezeigt werden.
|
||||
* **asynchrones Senden offline**: Beim asynchronen Senden ohne Internet-Verbindung (offline) müssen die notwendigen fachlichen Daten der Transaktion (Sender, Betrag und ggf. Verwendungszweck) in das Ausgabe-Medium kodiert werden, das dann asynchron vom User über ein anderes Transportmedium ausserhalb der Gradido-Anwendung an den Empfänger übertragen wird. Somit kann der Empfänger auch offline den Inhalt des erhaltenen Mediums mit entsprechenden Tools (noch zu konzipieren) überprüfen. Der Empfänger wird nicht schon wie üblich beim Erfassen der Transaktionsdaten bestimmt, sondern dies erfolgt in einem nachgelagerten Schritt des Übertragungsprozesses zum Beispiel in einem Messenger o.ä. in Eigenverantwortung des Users.
|
||||
* **Ausgabe-Medium als Link** : die Kodierung der Transaktionsdaten in einen Link eröffnen dem User eine Vielzahl an möglichen Übertragungswege. Der Link kann in Emails, Messages und für ihn sonstige verfügbare Medien kopiert werden, wo er dann in Eigenverantwortung aus seinen persönlichen Kontakten den Empfänger bestimmt.
|
||||
* **Ausgabe-Medium als QR-Code** : die Kodierung der Transaktionsdaten in einen QR-Code ist lediglich die Formatierung in Bildformat statt wie der Link in Text-Format. Der User kann auch den QR-Code in Emails, Messages und für ihn sonstige verfügbare Medien kopieren und übertragen. Letztendlich muss der Empfänger ein optischen QR-Scan mit einem ihm verfügbarem Medium wie beispielsweise Handy-, Tablet- oder PC-Kamera durchführen, um den Inhalt des Codes lesen zu können und um daraus wieder den eigentlichen Prozess der Weiterverarbeitung zu starten.
|
||||
|
||||
|
||||
* **Ausgabe-Medium als Link** : die Kodierung der Transaktionsdaten in einen Link eröffnen dem User eine Vielzahl an möglichen Übertragungswege. Der Link kann in Emails, Messages und für ihn sonstige verfügbare Medien kopiert werden, wo er dann in Eigenverantwortung aus seinen persönlichen Kontakten den Empfänger bestimmt.
|
||||
* **Ausgabe-Medium als QR-Code** : die Kodierung der Transaktionsdaten in einen QR-Code ist lediglich die Formatierung in Bildformat statt wie der Link in Text-Format. Der User kann auch den QR-Code in Emails, Messages und für ihn sonstige verfügbare Medien kopieren und übertragen. Letztendlich muss der Empfänger ein optischen QR-Scan mit einem ihm verfügbarem Medium wie beispielsweise Handy-, Tablet- oder PC-Kamera durchführen, um den Inhalt des Codes lesen zu können und um daraus wieder den eigentlichen Prozess der Weiterverarbeitung zu starten.
|
||||
|
||||
|
||||
#### Auswahl des Übertragungsweges
|
||||
|
||||
@ -45,7 +48,7 @@ Es stellt sich nun die Frage der User-Experience, ob schon bei der Navigation ü
|
||||
|
||||
**Menü-Auswahl**
|
||||
|
||||
Wenn die Auswahl des Übertragungsweges ob synchron, asynchron per Link oder asynchron per QR-Code schon über das Menü stattfinden soll, dann hat das aber auch die Konsequenz, dass für die asynchrone Übertragung ein eigener neuer Erfassungsdialog erstellt werden muss.
|
||||
Wenn die Auswahl des Übertragungsweges ob synchron, asynchron, per Link oder per QR-Code schon über das Menü stattfinden soll, dann hat das aber auch die Konsequenz, dass für die asynchrone Übertragung ein eigener neuer Erfassungsdialog erstellt werden muss.
|
||||
|
||||
**Dialogänderung**
|
||||
|
||||
|
||||
40
docu/Concepts/TechnicalRequirements/UC_X-Com-Tx_per_Link.md
Normal file
40
docu/Concepts/TechnicalRequirements/UC_X-Com-Tx_per_Link.md
Normal file
@ -0,0 +1,40 @@
|
||||
# UseCase: Cross Community Transactions per Link
|
||||
|
||||
With the feature X-Com-Transactions to send an amount of gradidos to an user of a foreign community the requirement to support this X-Com gradido transfer per link will become more significance.
|
||||
|
||||
The focus of this document is to describe the technical aspects from the recipient point of view. To get information about this topic from the sender point of view please take a look in the document [UseCase Send Users Gradido](https://github.com/gradido/gradido/blob/master/docu/Concepts/BusinessRequirements/UC_Send_Users_Gradido.md).
|
||||
|
||||
## Disbursement process
|
||||
|
||||
The following picture gives a first impression how the disbursement process will be started by activation of a redeem-link:
|
||||
|
||||

|
||||
|
||||
### Redeem-Link Validation
|
||||
|
||||
After a user has created a `redeem-Link` to send an other user an amount of gradidos the recipient of this link can activate it during the next 14 days after creation day. The redeem-link is build with several technical details following the pattern: `community-url of sender-community`/redeem/`code`
|
||||
|
||||
example: `https://gdd.gradido.net`/redeem/`3a5839be29f1`
|
||||
|
||||
In consequence how the transaction-link is created the recipient will be routed on activation to the community of the sender.
|
||||
|
||||
With receiving a redeem-link request the payload of this link will be validated. If the code of this link exists in database, the associated transaction is still open and the expiration time is not exceeded, the community will start the _disbursement process_.
|
||||
|
||||
### Identification of the recipient
|
||||
|
||||
At this point of time the recipient of the redeem-link is totaly unkown, which means it is not clear if he will be a user of the same community as the sender or be a user of a foreign community, if the recipient still has a gradido account or if he still have to register as a new gradido user.
|
||||
|
||||
In consequence the first page the user will see must offer a community-selection. This UI-component will present a list of all known, verified and authenticated communities the sender's home-community is connected over the federation.
|
||||
|
||||
With the selection of a community from this list the user must confirm his selection and will be routed on a following page for login or registration. But before this next-page-routing the system will check the community-selection if the recipient-community will be the same as the sender-community or a foreign-community.
|
||||
|
||||
In case of the same community there are no additional system actions for processing the transaction as a local send-coin-transaction necessary.
|
||||
|
||||
In case the user has selected a foreign community the system will create a new token, which contains all necessary information to start a _disbursement process_ from the foreign community after the user has done a successful login or registration there. The payload of this token must contain
|
||||
|
||||
* the url of the sender-community
|
||||
* the community-uuid of the sender-community
|
||||
* the gradidoID of the sender
|
||||
* the code of the redeem-link
|
||||
|
||||
The whole token have to be decrypted by the publicKey of the recipient-community and signed by the privateKey of the sender-community.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 231 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 237 KiB |
Loading…
x
Reference in New Issue
Block a user