documentation and modification of permissions

docs/apps/activity.rst

@@ -8,7 +8,7 @@ peuvent être diffusées via des calendriers ou la mailing list d'événements.
 Modèles
 -------
 
-L'application comporte 5 modèles : activités, types d'activité, invités, entrées et transactions d'invitation.
+L'application comporte 6 modèles : activités, types d'activité, invités, entrées, transactions d'invitation et les ouvreur⋅ses.
 
 Types d'activité
 ~~~~~~~~~~~~~~~~
@@ -71,6 +71,17 @@ comportent qu'un champ supplémentaire, de type ``OneToOneField`` vers ``Guest``
 Ce modèle aurait pu appartenir à l'application ``note``, mais afin de rester modulaire et que l'application ``note``
 ne dépende pas de cette application, on procède de cette manière.
 
+Ouvreur⋅ses
+~~~~~~~~~~~
+
+Depuis la page d'une activité, il est possible d'ajouter des personnes en tant qu'« ouvreur⋅se ». Cela permet à une
+personne sans aucun droit note de pouvoir faire les entrées d'une ``Activity``. Ce rôle n'est valable que pendant que
+l'activité est ouverte et sur aucune autre activité. Les ouvreur⋅ses ont aussi accès à l'interface des transactions.
+
+Ce modèle regroupe :
+* Activité (clé étrangère)
+* Note (clé étrangère)
+
 Graphe
 ~~~~~~
 
@@ -108,3 +119,6 @@ apparaîssent, afin de régler la taxe d'invitation : l'un prélève directement
 permettent un paiement par espèces ou par carte bancaire. En réalité, les deux derniers boutons enregistrent
 automatiquement un crédit sur la note de l'hôte, puis une transaction (de type ``GuestTransaction``) est faite depuis
 la note de l'hôte vers la note de l'organisateur de l'événement.
+
+Si une personne souhaite faire les entrées, il est possible de l'ajouter dans la liste des ouvreur⋅ses depuis la page
+de l'activité.