228 lines
12 KiB
ReStructuredText
228 lines
12 KiB
ReStructuredText
.. _prop_rewrite_interactions:
|
|
|
|
Interactions possible
|
|
=====================
|
|
|
|
The interactions between the previously mentioned entities would dictate the workflow of
|
|
the project and the direction of the flow of information among multiple entities
|
|
involved in an interaction. They are denoted by the line connecting the entities and can
|
|
be distinguished using the labels written on the top of the aforementioned joining
|
|
lines.
|
|
|
|
Internal-only interactions
|
|
--------------------------
|
|
|
|
Interactions involving only internal entities are termed, in this context, as
|
|
internal-only interactions.
|
|
|
|
.. image:: ../_static/badges-proposed-architecture.png
|
|
:target: ../_images/badges-proposed-architecture.png
|
|
|
|
AA
|
|
~~
|
|
|
|
1. Defines the interaction between entities, Accolades CLI and Accolades API.
|
|
2. Accolades CLI can help abstract reading, creating, changing and deleting of badge
|
|
related assets or information with the help of the endpoints that the Accolades API
|
|
provides.
|
|
3. This interaction causes DA and CA interactions to take place, as the data requested
|
|
is read from and data modified is changed into the Database and Collection entities.
|
|
For eg. fetching information about the badges awarded to a certain user from the
|
|
Database entity (DA) and automating adding new badges with the awarding conditions to
|
|
the Collection entity (CA).
|
|
4. This interaction affects LA and MA interactions as changes made to the Accolades API
|
|
would affect how it reacts to the actions made by the Liberation and Message Consumer
|
|
entities. For eg. new badges added into the Collection entity might show up on the
|
|
catalog of the Liberation entity (LA) and the awarding condition added to the
|
|
Collection entity would change the way the Message Consumer behaves in awarding
|
|
badges (MA).
|
|
|
|
LA
|
|
~~
|
|
|
|
1. Defines the interaction between entities, Liberation and Accolades API.
|
|
2. Liberation provides an interactive web interface for abstracting reading, creating,
|
|
changing, awarding and deleting of badge related assets or information with the help
|
|
of the endpoints that the Accolades API provides.
|
|
3. This interaction causes DA and CA interactions to take place, as the data requested
|
|
is read from and data modified is changed into the Database and Collection entities.
|
|
For eg. displaying the leaderboard of the top 100 community members by fetching it
|
|
from the Database entity (DA) and adding new badges with the awarding conditions to
|
|
the Collection entity (CA).
|
|
4. This interaction affects AA and MA interactions as changes made to the Accolades API
|
|
would affect how it reacts to the actions made by the Accolades CLI and Message
|
|
Consumer entities. For eg. newly awarded badge from Liberation would show up on the
|
|
Accolades CLI for the user querying about that information (AA) and the awarding
|
|
condition added to the Collection entity would change the way the Message Consumer
|
|
behaves in awarding badges (MA).
|
|
|
|
DA
|
|
~~
|
|
|
|
1. Defines the interaction between entities, Database and Accolades API.
|
|
2. Database stores the information of the achievements made by the community members by
|
|
their recordable actions within the Fedora Project community, along with the metadata
|
|
of when the badges were awarded etc.
|
|
3. This interaction cannot be directly triggered and can only happen as a cause of LA,
|
|
AA and MA interactions. As a result, this interaction does not become a causative
|
|
agent for any other interaction. For eg. awarding a user with a badge from the
|
|
Liberation entity would lead to changes made in the Database entity (LA), querying
|
|
about the badges achieved by a user in the Accolades CLI entity requires reading
|
|
information from the Database entity (AA) and conditioned awards made from the
|
|
Message Consumer entity would be reflected on the Database entity (MA).
|
|
4. This interaction affects only those interactions, that cause it to happen in the
|
|
first place. This can be explained as the consequences of the aforementioned example
|
|
interactions - for eg. Liberation entity would be able to see the badge under the
|
|
username that it was awarded to recently (LA) and Accolades CLI entity would be able
|
|
to retrieve the information it requested for (AA) but the MA interaction would stay
|
|
unaffected.
|
|
|
|
CA
|
|
~~
|
|
|
|
1. Defines the interaction between entities, Collection and Accolades API.
|
|
2. Collection entity stores the badge assets (artworks, badge rules, awarding conditions
|
|
etc.) that the Accolades API can read content from, add new badges, change/update and
|
|
delete/remove existing ones.
|
|
3. This interaction cannot be directly triggered and can only happen as a cause of
|
|
internal interactions like LA, AA, DA and MA as well as external interactions like
|
|
changes made into the Collection entity by external entities like Repository Members
|
|
etc. For eg. adding new badges for distribution using the Liberation entity (LA) and
|
|
doing so using the Accolades CLI (AA) would lead to changes in the Collection entity,
|
|
changes in the database due to the awarding of badges would require reading
|
|
information from the Collection entity (DA) and rules on how the Message Consumer
|
|
entity would award badges would be described by the conditions mentioned in the
|
|
Collection entity (MA).
|
|
4. This interaction affects only those interactions, that cause it to happen in the
|
|
first place. This can be explained as the consequences of the aforementioned examples
|
|
- for eg. addition of new badge for distribution would cause it to be accessible on
|
|
Liberation entity (LA) and on Accolades API (AA), Message Consumer entity would now
|
|
have new rules as a result to changes in the Collection entity (MA) but the DA
|
|
interaction would stay unaffected.
|
|
|
|
MA
|
|
~~
|
|
|
|
1. Defines the interaction between entities, Messages Consumer and Accolades API.
|
|
2. Message Consumer listens in to the Fedora Messaging bus and compares the messages
|
|
against the awarding conditions, and when the said condition is satisfied, it makes a
|
|
request to the Accolades API to award an external entity, a certain Community User
|
|
with the relevant badge.
|
|
3. This interaction cannot be directly triggered and can only happen as a cause of
|
|
internal interactions like CM and CA. For eg. any new additions made to the
|
|
Collection entity would change the way the Message Consumer entity checks for
|
|
conditions for badges (CA) and the Message Consumer would read the content regarding
|
|
the badges from the Collection entity (CM).
|
|
4. This interaction affects DA, LA and AA interactions as changes made to the Accolades
|
|
API entity by the Messages Consumer entity would affect how it reacts to the actions
|
|
made into the Database entity, by the Liberation entity and Message Consumer
|
|
entities. For eg. badges awarded automatically by the Messsage Consumer entity's
|
|
interaction would cause a change to be made on the Database entity (DA) and lead them
|
|
to be visible on the Liberation entity (LA) and accessible on the Accolades CLI
|
|
entity (AA).
|
|
|
|
CM
|
|
~~
|
|
|
|
1. Defines the interaction between entities, Collection and Message Consumer.
|
|
2. In order for the Message Consumer to obtain badge assets (artworks, rules, awarding
|
|
conditions etc.), it has to interact with the Collection entity.
|
|
3. This interaction cannot be directly triggered and can only happen as a cause of
|
|
internal interactions like CA and external interactions like Repository Members
|
|
making changes to the Collection entity. For eg. internal changes made to the
|
|
Collection entity and external changes made to the Collection entity (for eg. by the
|
|
Repository Members) would change the way the Messages Consumer entity would check for
|
|
awarding conditions for the badges (CA).
|
|
4. The interaction does not directly affect any other internal interaction but can
|
|
indirectly affect interactions like MA. For eg. changes in the Collection entity can
|
|
change the frequency and cases when the Messages Consumer would interact with the
|
|
Accolades API (MA).
|
|
|
|
External-Internal interactions
|
|
------------------------------
|
|
|
|
Interactions involving both external and internal entities are termed, in this context,
|
|
as external-internal interactions.
|
|
|
|
Accolades API interacting with external entities
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
.. image:: ../_static/badges-proposed-api-ext-interactions.png
|
|
:target: ../_images/badges-proposed-api-ext-interactions.png
|
|
|
|
1. Service Admins [Access Level IV] would have a direct control on the deployment
|
|
environments (staging, development, production etc.).
|
|
|
|
Accolades CLI interacting with external entities
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
.. image:: ../_static/badges-proposed-cli-ext-interactions.png
|
|
:target: ../_images/badges-proposed-cli-ext-interactions.png
|
|
|
|
1. Service Admins [Access Level IV] would have a direct control on the deployment
|
|
environments (staging, development, production etc.).
|
|
2. Badge Owners [Access Level III] would have an elevated access to the Accolades API
|
|
entity using the Accolades CLI entity where they can automate addition of new badges
|
|
for distribution within the community, create, access, modify and remove the badges
|
|
that they "own" (not the ones that they "have been awarded").
|
|
3. Community Users [Access Level I] would have a limited access to the Accolades API
|
|
entity using the Accolades CLI entity where they can view the badges received by them
|
|
(and by others), access the catalog of available badges, view leaderboards and other
|
|
such similar tasks.
|
|
|
|
Liberation interacting with external entities
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
.. image:: ../_static/badges-proposed-web-ext-interactions.png
|
|
:target: ../_images/badges-proposed-web-ext-interactions.png
|
|
|
|
1. Service Admins [Access Level IV] would have a direct control on the deployment
|
|
environments (staging, development, production etc.).
|
|
2. Badge Owners [Access Level III] would have an elevated access to the Accolades API
|
|
entity using the Liberation entity where they can manually add new badges for
|
|
distribution within the community, create, access, modify and remove the badges that
|
|
they "own" (not the ones that they "have been awarded").
|
|
3. Community Users [Access Level I] would have a limited access to the Accolades API
|
|
entity using the Liberation entity where they can view the badges received by them
|
|
(and by others), access the catalog of available badges, view leaderboards and other
|
|
such similar tasks.
|
|
|
|
Collection interacting with external entities
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
.. image:: ../_static/badges-proposed-col-ext-interactions.png
|
|
:target: ../_images/badges-proposed-col-ext-interactions.png
|
|
|
|
1. Repository Members [Access Level II] would have complete access to the Collection
|
|
entity where they can access, create, modify and remove badge assets (i.e. artworks,
|
|
badge rules, awarding conditions etc.). As the access is unrestricted, they have
|
|
access to the assets created by someone else too, which belong to the entity.
|
|
|
|
Database interacting with external entities
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
.. image:: ../_static/badges-proposed-dtb-ext-interactions.png
|
|
:target: ../_images/badges-proposed-dtb-ext-interactions.png
|
|
|
|
1. Service Admins [Access Level IV] would have a direct control on the deployment
|
|
environments (staging, development, production etc.).
|
|
|
|
Messages Consumer interacting with external entities
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
.. image:: ../_static/badges-proposed-msg-ext-interactions.png
|
|
:target: ../_images/badges-proposed-msg-ext-interactions.png
|
|
|
|
1. Service Admins [Access Level IV] would have a direct control on the deployment
|
|
environments (staging, development, production etc.).
|
|
|
|
External-only interactions
|
|
--------------------------
|
|
|
|
Interactions involving only external entities are termed, in this context, as
|
|
external-only interactions.
|
|
|
|
1. Badge Owners [Access Level III] might need to interact with Repository Members
|
|
[Access Level II] for assistance with changing badge assets in the Collection entity.
|
|
2. Community User [Access Level I] might need to interact with the Badge Owners [Access
|
|
Level III] to obtain badges for the action that they have done within the community.
|