You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user model in AIoD allows users to maintain and share ownership over assets,
4
+
and to allow a review process for new assets.
5
+
The components of this user model are defined in [src/database/authorization.py](https://github.com/aiondemand/AIOD-rest-api/blob/develop/src/database/authorization.py)
6
+
and [src/database/review.py](https://github.com/aiondemand/AIOD-rest-api/blob/develop/src/database/review.py).
7
+
8
+
[//]: #(Add a diagram overview once the model is more final, e.g., groups are added)
9
+
10
+
## Users
11
+
User credentials are kept in keycloak or by identity providers, in any case the user is uniquely identified
12
+
by the unique "sub" key that keycloak provides in its token.
13
+
In our user model we keep as little information about the user as we can.
14
+
This avoids a scenario were data is kept twice and may desynchronize, and also respects the users' privacy.
15
+
Currently, that is only the "sub", but in the future we may consider adding e.g., usernames.
16
+
17
+
## Permissions
18
+
A user may have certain permissions for an asset, these are:
19
+
20
+
- read: a user may retrieve this metadata asset.
21
+
- write: a user may modify this metadata asset.
22
+
- admin: a user may delete this metadata asset, submit it for review, and grant other users permissions for the asset.
23
+
24
+
The only notion of "ownership" over a particular metadata asset is having administrator rights.
25
+
When user A uploads an asset and assigns user B administrator rights, they have completely equal rights.
26
+
There is no special privilege for user A, and this also means that e.g., user B may remove administrator rights from user A.
27
+
28
+
## Reviews
29
+
An asset uploaded by a user is by default in `draft` state.
30
+
The user may request the asset to be `published` by submitting it for review through the REST API.
31
+
To do this, they submit the identifier of the asset to the `ASSET_TYPE/submit/v1/{identifier}` endpoint.
32
+
When it is submitted for review, reviewers will be able to see the request and make a decision.
33
+
As long as no decision has been made, the user may retract their submission from review using the `ASSET_TYPE/retract/v1/{identifier}`
34
+
endpoint.
35
+
Each asset may only have one concurrent review request, and the asset may not be modified while it is under review.
36
+
37
+
Reviewers can find pending submissions using the `submissions/v1` endpoint,
38
+
and get information on a particular submission with the `submissions/v1/{identifier}` endpoint,
39
+
where the identifier denotes the identifier of the submission (i.e., review request).
40
+
Reviewers can submit a review using the `ASSET_TYPE/review/v1/{identifier}` endpoint.
41
+
42
+
If the submission is accepted, the asset will be published without further action from the original uploader.
43
+
If the submission is rejected, the asset will move back to `draft` state and may be submitted again.
0 commit comments