132 lines
7.8 KiB
ReStructuredText
132 lines
7.8 KiB
ReStructuredText
.. _prop_rewrite_entities:
|
|
|
|
Entities involved
|
|
=================
|
|
|
|
Let us dive deep into the entities that would come together to make the Fedora Badges
|
|
project functional. We will call them "entities" for the context of this discussion.
|
|
Also, the names used for the entities here are temporary in nature and are, for the most
|
|
parts, only representative of the functions that these entities perform.
|
|
|
|
Here is a diagram exhibiting the proposed architecture.
|
|
|
|
.. image:: ../_static/badges-proposed-architecture.png
|
|
:target: ../_images/badges-proposed-architecture.png
|
|
|
|
Internal entities
|
|
-----------------
|
|
|
|
**Accolades API** - Backend service
|
|
1. Succeeds the existing `Tahrir <https://github.com/fedora-infra/tahrir>`_'s
|
|
backend API and/or is planned to be a reimplementation of the same.
|
|
2. This is planned to act as the backend service for the entire project and has
|
|
direct interactions with its neighbouring internal entities (i.e. Collection,
|
|
Database, Liberation, Messages Consumer, Accolades CLI).
|
|
|
|
**Accolades CLI** - Client application
|
|
1. Succeeds the existing `Tahrir API <https://github.com/fedora-infra/tahrir-api>`_
|
|
client and/or is planned to be a reimplementation of the same.
|
|
2. This is planned to act as a client application and/or library, usable for
|
|
automating purposes like pushing of badges (and their related awarding
|
|
conditions) to the Collection via the Accolades API, and other such high level
|
|
interactions offered by the Accolades API.
|
|
3. This is planned to be a standalone entity with just one possible interaction with
|
|
the neighbouring internal entity (i.e. Accolades API) and three possible
|
|
interactions with the neighbouring external entity (i.e. community users, badge
|
|
owners and service admins).
|
|
|
|
**Liberation** - Web interface
|
|
1. Succeeds the existing `Tahrir <https://github.com/fedora-infra/tahrir>`_'s
|
|
frontend part and/or is planned to be a reimplementation of the same.
|
|
2. This is planned to act as an interactive client application, accessible via
|
|
modern web browsers, usable by community members and service admins for purposes
|
|
like looking up the Fedora Badges leaderboard, checking badges awarded to self or
|
|
someone else etc. and adding new badges (and their related awarding conditions)
|
|
etc. respectively by interacting with the Accolades API.
|
|
3. This is planned to be a standalone entity with just one possible interaction with
|
|
the neighbouring internal entity (i.e. Accolades API) and three possible
|
|
interactions with the neighbouring external entity (i.e. community users, badge
|
|
owners and service admins).
|
|
|
|
**Collection** - Artworks and rules
|
|
1. Succeeds the existing `Fedora Badges <https://pagure.io/fedora-badges>`_
|
|
repository and/or is planned to be a reimplementation of the same.
|
|
2. This is planned to be a repository of supporting assets (artworks, awarding
|
|
conditions, consumer rules etc.) for the badges available for being awarded to
|
|
the community members, which can be read from and updated by the interactions
|
|
with the Accolades API entity and the Liberation entity as well as by admins
|
|
having relevant accesses to the repository.
|
|
3. This is planned to be a standalone entity with just one possible interaction with
|
|
the neighbouring internal entity (i.e. Accolades API) and one possible
|
|
interaction with the neighbouring external entity (i.e. repository members).
|
|
|
|
**Database** - Achievements storage
|
|
1. Succeeds the existing Fedora Badges database storage for storing the badges
|
|
awarded to community members, date of felicitation and other details and/or is
|
|
planned to be a reimplementation of the same.
|
|
2. A huge chunk of the existing database is planned to be reimported into the newer
|
|
schema and the columns specific to the Open Badges (or Badgr) compatibility will
|
|
not be taken into consideration. This can be read into and updated by the
|
|
interactions with the Accolades API only.
|
|
3. This is planned to be a standalone entity with just one possible interaction with
|
|
the neighbouring internal entity (i.e. Accolades API) and one possible
|
|
interaction with the neighbouring external entity (i.e. service admins).
|
|
|
|
**Messages consumer** - Conditions listener
|
|
1. Succeeds the existing `fedbadges <https://github.com/fedora-infra/fedbadges>`_
|
|
fedmsg listener and/or is planned to be a reimplementation of the same.
|
|
2. This is planned to act as a messages consumer, listening into the Fedora
|
|
Messaging bus matching the schemas that it is configured for and comparing the
|
|
messages against the awarding conditions available on the Collection, and on a
|
|
successful match, making a request to the Accolades API for awarding the said
|
|
badge to a certain contributor who have met the conditions specified in the
|
|
related badge rule.
|
|
3. This is planned to be a standalone entity with two possible interactions with the
|
|
neighbouring internal entities (i.e. Accolades API and Collection) and no
|
|
possible interaction with the neighbouring external entities.
|
|
|
|
External entities
|
|
-----------------
|
|
|
|
**Service admins** - Access Level IV
|
|
1. Consists of people belonging to the `Badges Administrators
|
|
<https://accounts.fedoraproject.org/group/sysadmin-badges/>`_ group.
|
|
2. People have access to the deployment environments (staging, development,
|
|
production etc.) and can control most of the aspects of all the internal
|
|
entities.
|
|
|
|
**Badge owners** - Access Level III
|
|
1. Consists of people who either lead or represent certain subcommunity, SIG or
|
|
subproject within the Fedora Project community, who want to make new badges
|
|
available and set rules for awarding.
|
|
2. People have an elevated access to the Liberation and Accolades CLI, which enables
|
|
them to access, create, change, award and delete badges that they "own" (not
|
|
those that they "have been awarded").
|
|
3. If there does not exist a designated IPA group for marking out these entities, a
|
|
new one can be created and they can be added to the same for easing access
|
|
control processes.
|
|
|
|
**Repository members** - Access Level II
|
|
1. Consists of people who either design, create and/or facilitate new badges and
|
|
want to make them available and set rules for awarding.
|
|
2. These are the people who can fall under the "Badge owners" category too but that
|
|
might not necessarily be the case always (for eg. badge designers who do not lead
|
|
or represent another subcommunity, SIG or subproject but are tasked to create and
|
|
upload badge assets).
|
|
3. There need not be a designated IPA group for marking out these entities as their
|
|
access is restricted to accessing, creating, changing and deleting badges assets
|
|
available on the Collection entity, which is simply a version control system
|
|
mediated repository.
|
|
|
|
**Community Users** - Access Level I
|
|
1. Consists of generally everyone from the Fedora Project community who have a valid
|
|
and activated, `IPA account <https://accounts.fedoraproject.org/>`_ and have
|
|
signed the `Fedora Project Contributor Agreement
|
|
<https://accounts.fedoraproject.org/user/t0xic0der/settings/agreements/>`_.
|
|
2. These are the people who are eligible to only receive badges for their recordable
|
|
actions (i.e. those which either trigger a message on the Fedora Messaging bus or
|
|
are noticed by a Badge Owner entity) within the Fedora Project community.
|
|
|
|
**NOTE** - These access levels are not exclusive in nature. A person who has an Access
|
|
Level IV, can (but not necessarily will) have those beneath it too and by default, every
|
|
FPCA signed member of the Fedora Project community, has at least, Access Level I.
|