-
Notifications
You must be signed in to change notification settings - Fork 1
Présentation générale et choix
Sigma est une plateforme communautaire à destination des écoles d'ingénieur françaises. Les principales fonctionnalités sont donc :
- un annuaire structuré ;
- un calendrier d'événements partagé et personnel ;
- un système de publications avec une gestion fine de la visibilité ;
- ...
Sigma utilise un certain nombre de modèles pour représenter les objets en jeu dans une telle plateforme. Voici la liste des principales entités utilisées :
Un utilisateur, ou User
, représente une personne physique qui utilise le service.
Il est identifié par une adresse email avec laquelle il peut se connecter.
Un utilisateur possède également un nom, un prénom, un mot de passe et un username.
Tout utilisateur authentifié sur Sigma peut voir les noms et prénoms de tous les autres utilisateurs (au moyen d'une recherche par exemple). Ceci est nécessaire pour retrouver quelqu'un d'une autre école par exemple. On appellera informations minimales d'un utilisateur, ses nom, prénom et username.
Pour voir plus d'informations sur un utilisateur (email, photo, groupes, etc.), je dois être connecté à cet utilisateur. Pour cela, deux possibilités : -> je partage un groupe ou un chat avec lui -> je l'ai ajouté en tant que "connaissance" : dans ce cas, on a créé un objet UserConnection. Les "connaissances" peuvent être considérées comme les amitiés fb dans leur fonctionnement, mais pas dans leur usage : il n'est par exemple pas possible de rajouter quelqu'un dans ses connaissances si je partage un groupe avec lui puisque je peux déjà voir son profil.
Comme tout réseau social, Sigma permet aux utilisateurs de se rassembler par groupe.
Un groupe (Group
) est une notion très générique dans Sigma, et peut représenter aussi bien une école qu'un groupe de discussion entre utilisateurs.
Concernant la visibilité des groupes, il y a deux notions à séparer : la visibilité du groupe, et la visibilité de ses membres.
Un groupe peut être considéré comme : -> visible uniquement par ses membres -> visible par les membres de groupes qui ont été acknowledged -> visible par tous
Ses membres quant à eux peuvent être : -> visibles que par eux-mêmes (obligatoire dans le cas où le groupe n'est visible que par ses membres) -> visibles si je suis connecté à eux (cf ci-dessus pour la définition de la connexion entre 2 users) -> visibles par tous
L'appartenance à un groupe, ou membership en anglais, est modélisée dans Sigma par un objet (GroupMember
dans le backend Django, Membership
dans le frontend Angular). Un GroupMember
pointe donc vers un User
et un `Group.
Des détails tels que le niveau de permission de l'utilisateur dans le groupe sont stockés dans cet objet.
Une membership peut posséder une date de fin de validité : passé cette date, l'appartenance au groupe est "désactivée" et l'utilisateur ne peut plus voir les nouvelles activités du groupe. Si cette date est modifiée, l'utilisateur peut voir ce qu'il s'est passé entre temps. En cas de suppression complète de la membership, toutes les informations sont perdues.
Je peux voir un GroupMember
si je peux voir l'User
et le Group
associés, suivant les Règles Normales de Visibilité présentées précédemment.
Un groupe peut être vu comme un sous-groupe d'un autre groupe (dit "parent"). Cette relation doit être validée par les deux parties (sous-groupe et parent), et porte le nom de GroupAcknowledgment
.
C'est au travers de cette relation que l'on définit le type d'un groupe, par exemple "association" ou "cursus".
Cette relation permet également de définir les Règles Normales de Visibilité des Groupes (cf. supra).
D'autre part, quand on groupe est acknowledged par un autre, les admins du parent peuvent disposer également des droits d'administration sur le sous-groupe si le champ GroupAcknowledgment.delegate_admin
est défini à True
.
Afin de favoriser la communication dans les écoles, Sigma fournit un système de publications. Une Publication
est toujours postée dans un Group
(destinataire), par un User
(auteur). Celui-ci peut poster au nom d'un groupe.
Une publication peut être "mise en avant", ce qui permet de distinguer les publications importantes (et "validées" par les modérateurs) des publications plus "spammatoires".
Les publications sont toutes visibles par les membres du groupe destinataire.
Concernant l'utilisateur-auteur et le groupe (éventuel) au nom duquel la publication est postée, les Règles Normales de Visibilité s'appliquent.
La modération se fait à trois niveaux :
- groupe destinataire :
- qui peut publier dans le groupe ?
- qui peut mettre des publications en avant ?
- groupe émetteur (éventuel) : qui peut publier au nom du groupe ?
La modération s'appuie sur un système de listes blanches et noires, pouvant contenir le joker "tout le monde".
Un événement (Event
) est un groupe, celui des participants.
Les Règles Normales de Visibilité des Groupes s'appliquent donc aux événements : un événement public sera visible par tout le monde, un événement privé demandera certaines conditions.
Si un Event
privé, non acknowledged par un cluster, et "sur invitation seulement*, publie dans un groupe, cela implique qu'il invite tous les membres du groupe à rejoindre l'événement.