IT4Change/gradido
3
0
Fork 0
mirror of https://github.com/IT4Change/gradido.git synced 2025-12-13 07:45:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

additional community services

Browse Source
This commit is contained in:
Claus-Peter Hübner 2022-01-11 02:01:43 +01:00
parent d254f875ec
commit 04c7930109
2 changed files with 172 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docu/Concepts/BusinessRequirements/CommunityVerwaltung.md
View File

@ -305,9 +305,9 @@ Der oben grafisch dargestellte Ablauf wird in drei grobe Teile untergliedert:
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
* ein Listener lauscht am Public-Channel auf Antworten (*replyNewCommunity*-Msg) der schon existenten Communities
* ein Listener lauscht am Public-Channel auf initiale "*newCommunity*-Msg" anderer neuer Communities
4. mit dem ersten Empfangen einer *replyNewCommunity*-Msg einer anderen Community, wird der *Community-Communication* 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

175
docu/Concepts/TechnicalRequirements/CommunityCommunication.md
View File

@ -4,20 +4,19 @@ This document contains the detailed descriptions of the public API of a communit
## Authentication and Autorization
Each public API of a community has to be authenticated and autorized before. This has to be done by following the *OpenID Connect* protocoll. To fullfil these security requirements a separate security service has to be part of the Gradido-application.
Each public API of a community has to be authenticated and autorized before. This has to be done by following the *OpenID Connect* protocoll. To fullfil these security requirements a separate security service has to be part of the Gradido-application.
Following the link [OpenID Connect](https://www.npmjs.com/package/openid-client) there can be found a server-side OpenID relying party implementation for node.js runtime.
The authentication of communities base on the community-attributes *key* and *URL*, which where exchanged during the federation process before. In concequence a community that hasn't execute his federation well will be unknown for other communities and can't be authenticated and autorized for further API calls.
The authentication of communities base on the community-attributes *key* and *URL*, which where exchanged during the *federation process* before. In concequence a community that hasn't execute his federation well will be unknown for other communities and can't be authenticated and autorized for further API calls.
## Service: "Familiarize communities"
## Familiarize communities
This request is used to exchange data between an existing and a new community. It will be invoked by the existing community, which received a valid *newCommunity*-Message from a new community during the federation process.
This request is used to exchange data between an existing and a new community. It will be invoked by the existing community, which received a valid *newCommunity*-Message from a new community during the federation process.
The invocation from the federation process gives the *Community-Key* and *New_Community_URL* as input parameters, which are used to get the *Security-Token* from the SecurityService.
The exchanged data will be transferred as a *CommunityTO* transferobject in both directions as input and output parameter.
The exchanged data will be transferred as a *CommunityTO* transferobject in both directions as input and output parameter.
### Route:
@ -63,6 +62,170 @@ The new community will save the received data and returns its own collected data
### Exceptions:
A *SecurityException* will be thrown, if the security-accesstoken is not valid or the if internal autorization rules like black-listings will not allow access.
In case the transferred community-key from the service-consumer will not match the previous authenticated community on service-provider the exception *UnknownCommunityException* will be thrown.
In case the transferred data can't be stored on service-provider the exception *WriteAccessException* will be thrown.
## Service: "Member of Community"
Before user A can start any cross-community interactions with user B, this service api can be used to check if user B is a valid member of the other community.
### Route:
GET https://<Other_Community_URL>/memberOfCommunity/`<security-accesstoken>`
### Input-Data:
```
{
userid : "user-id following the pattern <communityname@username"
}
```
### Output-Data:
the other community will search in its member list for the given userid. If the user could be found the output data will be returned, otherwise null.
```
{
UserTO
{
"userid" : "user-id",
"surename" : "surename of user",
"name" : "name of user",
"alias" : "alias name of user",
"email" : "email address of user",
"member-since" : "date of entry in community",
"interacting-members" : "amount of members the user interact with",
"interacting-communities" : "amount of communities the user interact with"
}
}
```
### Exceptions:
A *SecurityException* will be thrown, if the security-accesstoken is not valid or the if internal autorization rules like black-listings will not allow access.
## Service: "Receive Coins"
With this service a cross community transaction can be done. In detail if *user-A* member of *community-sender* wants to send *user-B* member of *community-receiver* an amount of GDDs, the gradido server of *community-sender* invokes this service at the server of *community-receiver*.
The service will use a datatype Money as attribute in the input-data with the following attributes and methods:
```
Money
{
Attributes:
- Integer "amount" : "in Gradido-Cent and so without decimal places"
- String "currencykey" : "unique currency key (communitykey) as the source community the coins are created"
Methods:
- toString() : "returns the amount as String with 2 decimal places and the Gradido-currencysymbol"
- plus(Money m) : "evaluates if the currencykey of m equals the internal currencyKey and if yes adds the amount of m to the internal ammount, otherwise throws an WrongCurrencyException"
- minus(Money m) : "evaluates if the currencykey of m equals the internal currencyKey and if yes substracts the amount of m from the internal ammount, otherwise throws an WrongCurrencyException
- isSameCommunity(Money m) : "returns TRUE if the currencykey of m is equals the internal currencyKey, otherwise FALSE"
- decay(Long sec) : "calculates the decay of the internal amount with the given duration in sec by: amount - (amount x 0.99999997802044727 ^ sec)
}
```
### Route:
GET https://<receiver_community_URL>/receiveCoins/`<security-accesstoken>`
### Input-Data:
```
{
TransactionTO
{
"sender-community" : "the key of the sender community",
"sender-user" : "the user-id of the user, who sends the coins",
"receiver-user" : "the user-id of the user, who will receive the coins",
"money" : "the amount of coins and community-currency (community-key) as type Money",
"reason for transfer" : "the transaction description",
"timestamp of transfer" : "date and time of transaction"
}
}
```
### Output-Data:
```
{
"result" : "result of a valid receive coins processing (perhaps gratitude of user or community), otherwise exception"
}
```
### Exceptions:
*WrongCommunityException* in case the receiver community didn't know the sender community.
*UnknownUserException* in case the receiver community has no user with the given receiver-user-id.
*MissingTxDetailException* in case of missing one or more attributes in the TransactionTO,
*InvalidCurrencyException* in case the currency (community-key) doesn't match with the sender-community.
*InvalidTxTimeException* in case the timestamp of transfer is in the past.
*DenyTxException* in case the receiver community or user will not interact with the sender community or user.
## Service: "get Activity List"
This service can be used to read the activity list of another community. A community supports a list of activities a member can select to create gradidos for his actions. Each activity has an attribute *topic* on which the list reading can be filtered.
### Route:
GET https://<Other_Community_URL>/getActivityList/`<security-accesstoken>`
### Input-Data:
```
{
"topics" : "list of topics the reading of the activity list should be filtered by"
}
```
### Output-Data:
```
{
"activities" : "list of found activity, which match the input-data"
}
```
### Exceptions:
## Service: "get Clearing Activities"
This service can be used to read open activities of other community members, which are open to be cleared by other users. This base on the concept to clear at least two or more activities of other users before the amount of gradidos of the own activity can be credit on the own AGE account.
### Route:
GET https://<Other_Community_URL>/getClearingActivities/`<security-accesstoken>`
### Input-Data:
### Output-Data:
### Exceptions:
## Service: "Clear Activity"
This service can be used to clear an open activity, which was read by the service getClearingActivies before. This base on the concept to clear at least two or more activities of other users before the amount of gradidos of the own activity can be credit on the own AGE account.
### Route:
### Input-Data:
### Output-Data:
### Exceptions: