mirror of
https://gitlab.crans.org/bde/nk20
synced 2025-06-21 09:58:23 +02:00
Merge branch 'beta' into ouvreureuse
This commit is contained in:
korenstin
@ -3,12 +3,12 @@ Application Activités
|
||||
|
||||
L'application activités gère les différentes activités liées au BDE. Elle permet entre autres de créer des activités qui
|
||||
peuvent être diffusées via des calendriers ou la mailing list d'événements. Elle permet aussi de réguler l'accès aux
|
||||
événements, en s'assurant que leur note est positive. Elle permet enfin de gérer les invités.
|
||||
événements, en s'assurant que leur note est positive. Elle permet enfin de gérer les invité⋅es.
|
||||
|
||||
Modèles
|
||||
-------
|
||||
|
||||
L'application comporte 6 modèles : activités, types d'activité, invités, entrées, transactions d'invitation et les ouvreur⋅ses.
|
||||
L'application comporte 6 modèles : activités, types d'activité, invité⋅es, entrées et transactions d'invitation et les ouvreur⋅ses.
|
||||
|
||||
Types d'activité
|
||||
~~~~~~~~~~~~~~~~
|
||||
@ -16,7 +16,7 @@ Types d'activité
|
||||
Les activités sont triées par type (pots, soirées de club, ...), et chaque type regroupe diverses informations :
|
||||
|
||||
* Nom du type
|
||||
* Possibilité d'inviter des non-adhérents (booléen)
|
||||
* Possibilité d'inviter des non-adhérent⋅es (booléen)
|
||||
* Prix d'invitation (entier, centimes à débiter sur la note de l'hôte)
|
||||
|
||||
Activités
|
||||
@ -26,7 +26,7 @@ Le modèle d'activité regroupe les informations liées à l'activité même :
|
||||
|
||||
* Nom de l'activité
|
||||
* Description de l'activité
|
||||
* Créateur, personne qui a proposé l'activité
|
||||
* Créateur⋅rice, personne qui a proposé l'activité
|
||||
* Club ayant organisé l'activité
|
||||
* Note sur laquelle verser les crédits d'invitation (peut être nul si non concerné)
|
||||
* Club invité (généralement le club Kfet)
|
||||
@ -38,19 +38,19 @@ Le modèle d'activité regroupe les informations liées à l'activité même :
|
||||
Entrées
|
||||
~~~~~~~
|
||||
|
||||
Une instance de ce modèle est créé dès que quelqu'un est inscrit à l'activité. Sont stockées les informations suivantes :
|
||||
Une instance de ce modèle est créé dès que quelqu'un⋅e est inscrit⋅e à l'activité. Sont stockées les informations suivantes :
|
||||
|
||||
* Activité concernée (clé étrangère)
|
||||
* Heure d'entrée
|
||||
* Note de la personne entrée, ou hôte s'il s'agit d'un invité (clé étrangère vers ``NoteUser``)
|
||||
* Invité (``OneToOneField`` vers ``Guest``, ``None`` si c'est la personne elle-même qui rentre et non son invité)
|
||||
* Note de la personne entrée, ou hôte s'il s'agit d'un⋅e invité⋅e (clé étrangère vers ``NoteUser``)
|
||||
* Invité⋅e (``OneToOneField`` vers ``Guest``, ``None`` si c'est la personne elle-même qui rentre et non saon invité⋅e)
|
||||
|
||||
Il n'est pas possible de créer une entrée si la note est en négatif.
|
||||
|
||||
Invités
|
||||
~~~~~~~
|
||||
Invité⋅es
|
||||
~~~~~~~~~
|
||||
|
||||
Les adhérents ont la possibilité d'inviter des amis. Pour cela, les différentes informations sont enregistrées :
|
||||
Les adhérent⋅es ont la possibilité d'inviter des ami⋅es. Pour cela, les différentes informations sont enregistrées :
|
||||
|
||||
* Activité concernée (clé étrangère)
|
||||
* Nom de famille
|
||||
@ -60,7 +60,7 @@ Les adhérents ont la possibilité d'inviter des amis. Pour cela, les différent
|
||||
Certaines contraintes s'appliquent :
|
||||
|
||||
* Une personne ne peut pas être invitée plus de 5 fois par an (coupe nom/prénom)
|
||||
* Un adhérent ne peut pas inviter plus de 3 personnes par activité.
|
||||
* Un⋅e adhérent⋅e ne peut pas inviter plus de 3 personnes par activité.
|
||||
|
||||
Transactions d'invitation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -94,15 +94,15 @@ UI
|
||||
Création d'activités
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
N'importe quel adhérent Kfet peut suggérer l'ajout d'une activité via un formulaire.
|
||||
N'importe quel⋅le adhérent⋅e Kfet peut suggérer l'ajout d'une activité via un formulaire.
|
||||
|
||||
Gestion des activités
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Les ayant-droit (Res[pot] et respos infos) peuvent valider les activités proposées. Ils peuvent également la modifier
|
||||
si besoin. Ils peuvent enfin la déclarer ouvertes pour lancer l'accès aux entrées.
|
||||
si besoin. Iels peuvent enfin la déclarer ouverte pour lancer l'accès aux entrées.
|
||||
|
||||
N'importe qui peut inviter des amis non adhérents, tant que les contraintes de nombre (un adhérent n'invite pas plus de
|
||||
N'importe qui peut inviter des ami⋅es non adhérent⋅es, tant que les contraintes de nombre (un⋅e adhérent⋅e n'invite pas plus de
|
||||
trois personnes par activité et une personne ne peut pas être invitée plus de 5 fois par an). L'invitation est
|
||||
facturée à l'entrée.
|
||||
|
||||
@ -110,15 +110,15 @@ Entrées aux soirées
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
L'interface d'entrées est simple et ergonomique. Elle contient un champ de texte. À chaque fois que le champ est
|
||||
modifié, un tableau est affiché comprenant la liste des invités et des adhérents dont le prénom, le nom ou un alias
|
||||
modifié, un tableau est affiché comprenant la liste des invité⋅es et des adhérent⋅es dont le prénom, le nom ou un alias
|
||||
de la note est acceptée par le texte entré.
|
||||
|
||||
En cliquant sur la ligne de la personne qui souhaite rentrée, s'il s'agit d'un adhérent, alors la personne est comptée
|
||||
comme entrée à l'activité, sous réserve que sa note soit positive. S'il s'agit d'un invité, alors 3 boutons
|
||||
En cliquant sur la ligne de la personne qui souhaite rentrer, s'il s'agit d'un⋅e adhérent⋅e, alors la personne est comptée
|
||||
comme entrée à l'activité, sous réserve que sa note soit positive. S'il s'agit d'un⋅e invité⋅e, alors 3 boutons
|
||||
apparaîssent, afin de régler la taxe d'invitation : l'un prélève directement depuis la note de l'hôte, les deux autres
|
||||
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.
|
||||
la note de l'hôte vers la note du club 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é.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Applications de la NoteKfet2020
|
||||
===============================
|
||||
Applications de la Note Kfet 2020
|
||||
=================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
@ -15,27 +15,26 @@ Applications de la NoteKfet2020
|
||||
treasury
|
||||
wei
|
||||
|
||||
La NoteKfet est un projet Django, décomposé en applications.
|
||||
Certaines Applications sont développées uniquement pour ce projet, et sont indispensables,
|
||||
d'autres sont packagesé et sont installées comme dépendances.
|
||||
Enfin des fonctionnalités annexes ont été rajouté, mais ne sont pas essentiel au déploiement de la NoteKfet;
|
||||
leur usage est cependant recommandé.
|
||||
La Note Kfet 2020 est un projet Django, décomposé en applications.
|
||||
Certaines applications sont développées uniquement pour ce projet, et sont indispensables,
|
||||
d'autres sont packagées et sont installées comme dépendances.
|
||||
Enfin, des fonctionnalités annexes ont été rajoutées, mais ne sont pas essentielles au déploiement de la Note Kfet 2020. Leur usage est cependant recommandé.
|
||||
|
||||
Le front utilise le framework Bootstrap4 et quelques morceaux de javascript custom.
|
||||
L'affichage Web utilise le framework Bootstrap4 et quelques morceaux de JavaScript personnalisés.
|
||||
|
||||
Applications indispensables
|
||||
---------------------------
|
||||
|
||||
* ``note_kfet`` :
|
||||
Application "projet" de django, c'est ici que la config de la note est gérée.
|
||||
Application "projet" de django, c'est ici que la configuration de la note est gérée.
|
||||
* `Member <member>`_ :
|
||||
Gestion des profils d'utilisateurs, des clubs et de leur membres.
|
||||
Gestion des profils d'utilisateur⋅rices, des clubs et de leur membres.
|
||||
* `Note <note>`_ :
|
||||
Les notes associés a des utilisateurs ou des clubs.
|
||||
Les notes associées à des utilisateur⋅rices ou des clubs.
|
||||
* `Activity <activity>`_ :
|
||||
La gestion des Activités (créations, gestion, entrée...)
|
||||
La gestion des activités (créations, gestion, entrées,…)
|
||||
* `Permission <permission>`_ :
|
||||
Backend de droits, limites les pouvoirs des utilisateurs
|
||||
Backend de droits, limites les pouvoirs des utilisateur⋅rices
|
||||
* `API <../api>`_ :
|
||||
API REST de la note, est notamment utilisée pour rendre la note dynamique
|
||||
(notamment la page de conso)
|
||||
@ -52,9 +51,9 @@ Applications packagées
|
||||
`<https://django-polymorphic.readthedocs.io/en/stable/>`_
|
||||
|
||||
* ``crispy_forms``
|
||||
Utiliser pour générer des forms avec bootstrap4
|
||||
Utiliser pour générer des formulaires avec Bootstrap4
|
||||
* ``django_tables2``
|
||||
utiliser pour afficher des tables de données et les formater, en python plutôt qu'en HTML.
|
||||
utiliser pour afficher des tables de données et les formater, en Python plutôt qu'en HTML.
|
||||
* ``restframework``
|
||||
Base de l'`API <../api>`_.
|
||||
|
||||
@ -63,11 +62,11 @@ Applications facultatives
|
||||
* `Logs <logs>`_
|
||||
Enregistre toute les modifications effectuées en base de donnée.
|
||||
* ``cas-server``
|
||||
Serveur central d'authenfication, permet d'utiliser son compte de la NoteKfet2020 pour se connecter à d'autre application ayant intégrer un client.
|
||||
* `Script <https://gitlab.crans.org/bde/nk20-scripts>`_
|
||||
Ensemble de commande `./manage.py` pour la gestion de la note: import de données, verification d'intégrité, etc ...
|
||||
Serveur central d'authentification, permet d'utiliser son compte de la NoteKfet2020 pour se connecter à d'autre application ayant intégrer un client.
|
||||
* `Scripts <https://gitlab.crans.org/bde/nk20-scripts>`_
|
||||
Ensemble de commande `./manage.py` pour la gestion de la note: import de données, verification d'intégrité, etc…
|
||||
* `Treasury <treasury>`_ :
|
||||
Interface de gestion pour les trésoriers, émission de facture, remise de chèque, statistiques ...
|
||||
Interface de gestion pour les trésorièr⋅es, émission de factures, remises de chèque, statistiques ...
|
||||
* `WEI <wei>`_ :
|
||||
Interface de gestion du WEI.
|
||||
|
||||
|
||||
@ -6,22 +6,22 @@ Chaque modification effectuée sur un modèle est enregistrée dans la base dans
|
||||
Dès qu'un modèle veut être sauvegardé, deux signaux sont envoyés dans ``logs.signals`` : un avant et un après
|
||||
la sauvegarde.
|
||||
En pré-sauvegarde, on récupère l'ancienne version du modèle, si elle existe.
|
||||
En post-sauvegarde, on récupère l'utilisateur et l'IP courants (voir ci-dessous), on convertit les modèles en JSON
|
||||
En post-sauvegarde, on récupère l'utilisateur⋅rice et l'IP courant⋅es (voir ci-dessous), on convertit les modèles en JSON
|
||||
et on enregistre une entrée ``Changelog`` dans la base de données.
|
||||
|
||||
Pour récupérer l'utilisateur et son IP, le middleware ``logs.middlewares.LogsMiddlewares`` récupère à chaque requête
|
||||
l'utilisateur et l'adresse IP, et les stocke dans le processus courant, afin qu'ils puissent être
|
||||
Pour récupérer l'utilisateur⋅rice et son IP, le middleware ``logs.middlewares.LogsMiddlewares`` récupère à chaque requête
|
||||
l'utilisateur⋅rice et l'adresse IP, et les stocke dans le processus courant, afin qu'ils puissent être
|
||||
récupérés par les signaux.
|
||||
|
||||
Si jamais la modification ne provient pas d'une requête Web, on suppose qu'elle vient d'une instruction
|
||||
lancée avec ``manage.py``.
|
||||
On récupère alors le nom de l'utilisateur dans l'interface de commandes, et si une note est associée à cet alias,
|
||||
On récupère alors le nom de l'utilisateur⋅rice dans l'interface de commandes, et si une note est associée à cet alias,
|
||||
alors on considère que c'est le détenteur de la note qui a effectué cette modification, sur l'adresse IP ``127.0.0.1``.
|
||||
Sinon, le champ est laissé à ``None``.
|
||||
|
||||
Une entrée de ``Changelog`` contient les informations suivantes :
|
||||
|
||||
* Utilisateur (``ForeignKey`` vers ``User``, nullable)
|
||||
* Utilisateur⋅rice (``ForeignKey`` vers ``User``, nullable)
|
||||
* Adresse IP (``GenericIPAddressField``)
|
||||
* Type de modèle enregistré (``ForeignKey`` vers ``Model``)
|
||||
* Identifiant ``pk`` de l'instance enregistrée (``CharField``)
|
||||
@ -54,4 +54,4 @@ Graphe
|
||||
~~~~~~
|
||||
|
||||
.. image:: ../_static/img/graphs/logs.svg
|
||||
:alt: Logs graphe
|
||||
:alt: Logs graph
|
||||
|
||||
@ -1,63 +1,63 @@
|
||||
Application Member
|
||||
==================
|
||||
|
||||
L'application ``member`` s'occcupe de la gestion des utilisateurs enregistrés.
|
||||
L'application ``member`` s'occcupe de la gestion des utilisateur⋅rices enregistré⋅es.
|
||||
|
||||
Le model d'utilisateur ``django.contrib.auth.model.User`` est complété par un ``Profile`` utilisateur.
|
||||
Le model d'utilisateur⋅rice ``django.contrib.auth.model.User`` est complété par un ``Profile`` utilisateur⋅rice.
|
||||
|
||||
Tous les utilisateurs peuvent être membre de ``Club``. Cela se traduit par une adhésion ``Membership``, dont les
|
||||
Toustes les utilisateur⋅rices peuvent être membre de ``Club``. Cela se traduit par une adhésion ``Membership``, dont les
|
||||
caractéristiques sont propres à chaque club.
|
||||
|
||||
En pratique, la NoteKfet possède au minimum deux Club: **Bde** et **Kfet** (instanciés via les fixtures). Et tous
|
||||
les personnes à jour de cotisation sont membre à minima de Bde.
|
||||
Être adhérent du club Kfet permet d'utiliser sa note pour consommer.
|
||||
En pratique, la Note Kfet possède au minimum deux clubs : **Bde** et **Kfet** (instanciés
|
||||
via les fixtures). Et toutes les personnes à jour de cotisation sont membre à minima de
|
||||
BDE. Être adhérent⋅e du club Kfet permet d'utiliser sa note pour consommer.
|
||||
|
||||
Modèles
|
||||
-------
|
||||
|
||||
Utilisateur
|
||||
~~~~~~~~~~~
|
||||
Utilisateur⋅rice
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Le modèle ``User`` est directement implémenté dans Django et n'appartient pas à l'application ``member``, mais il est
|
||||
bon de rappeler à quoi ressemble ce modèle.
|
||||
|
||||
* ``date_joined`` : ``DateTimeField``, date à laquelle l'utilisateur a été inscrit (*inutilisé dans la Note*)
|
||||
* ``email`` : ``EmailField``, adresse e-mail de l'utilisateur.
|
||||
* ``first_name`` : ``CharField``, prénom de l'utilisateur.
|
||||
* ``date_joined`` : ``DateTimeField``, date à laquelle l'utilisateur⋅rice a été inscrit⋅e (*inutilisé dans la Note*)
|
||||
* ``email`` : ``EmailField``, adresse e-mail de l'utilisateur⋅rice.
|
||||
* ``first_name`` : ``CharField``, prénom de l'utilisateur⋅rice.
|
||||
* ``is_active`` : ``BooleanField``, indique si le compte est actif et peut se connecter.
|
||||
* ``is_staff`` : ``BooleanField``, indique si l'utilisateur peut se connecter à l'interface Django-admin.
|
||||
* ``is_superuser`` : ``BooleanField``, indique si l'utilisateur dispose de droits super-utilisateurs, permettant n'importe quelle action en base de donnée (lecture, ajout, modification, suppression).
|
||||
* ``is_staff`` : ``BooleanField``, indique si l'utilisateur⋅rice peut se connecter à l'interface Django-admin.
|
||||
* ``is_superuser`` : ``BooleanField``, indique si l'utilisateur⋅rice dispose de droits super-utilisateur⋅rices, permettant n'importe quelle action en base de donnée (lecture, ajout, modification, suppression).
|
||||
* ``last_login`` : ``DateTimeField``, date et heure de dernière connexion.
|
||||
* ``last_name`` : ``CharField``, nom de famille de l'utilisateur.
|
||||
* ``password`` : ``CharField``, contient le hash du mot de passe de l'utilisateur. L'algorithme utilisé est celui par défaut de Django : PBKDF2 + HMAC + SHA256 avec 150000 itérations.
|
||||
* ``username`` : ``CharField`` (unique), pseudo de l'utilisateur.
|
||||
* ``last_name`` : ``CharField``, nom de famille de l'utilisateur⋅rice.
|
||||
* ``password`` : ``CharField``, contient le hash du mot de passe de l'utilisateur⋅rice. L'algorithme utilisé est celui par défaut de Django : PBKDF2 + HMAC + SHA256 avec 150000 itérations.
|
||||
* ``username`` : ``CharField`` (unique), pseudo de l'utilisateur⋅rice.
|
||||
|
||||
Profil
|
||||
~~~~~~
|
||||
|
||||
Le modèle ``Profile`` contient un champ ``user`` de type ``OneToOneField``, ce qui permet de voir ce modèle comme une
|
||||
extension du modèle ``User``, sans avoir à le réécrire. Il contient diverses informations personnelles sur
|
||||
l'utilisateur, utiles pour l'adhésion au BDE :
|
||||
l'utilisateur⋅rice, utiles pour l'adhésion au BDE :
|
||||
|
||||
* ``user`` : ``OneToOneField(User)``, utilisateur lié à ce profil
|
||||
* ``address`` : ``CharField``, adresse physique de l'utilisateur
|
||||
* ``paid`` : ``BooleanField``, indique si l'utilisateur normalien est rémunéré ou non (utile pour différencier les montants d'adhésion aux clubs)
|
||||
* ``phone_number`` : ``CharField``, numéro de téléphone de l'utilisateur
|
||||
* ``section`` : ``CharField``, section de l'ENS à laquelle apartient l'utilisateur (exemple : 1A0, ...)
|
||||
* ``user`` : ``OneToOneField(User)``, utilisateur⋅rice lié à ce profil
|
||||
* ``address`` : ``CharField``, adresse physique de l'utilisateur⋅rice
|
||||
* ``paid`` : ``BooleanField``, indique si l'utilisateur⋅rice normalien⋅ne est rémunéré⋅e ou non (utile pour différencier les montants d'adhésion aux clubs)
|
||||
* ``phone_number`` : ``CharField``, numéro de téléphone de l'utilisateur⋅rice
|
||||
* ``section`` : ``CharField``, section de l'ENS à laquelle appartient l'utilisateur⋅rice (exemple : 1A0,…)
|
||||
|
||||
Clubs
|
||||
~~~~~
|
||||
|
||||
La gestion des clubs est une différence majeure avec la Note Kfet 2015. La Note gère ainsi les adhésions des
|
||||
utilisateurs aux différents clubs.
|
||||
utilisateur⋅rices aux différents clubs.
|
||||
|
||||
* ``parent_club`` : ``ForeignKey(Club)``. La présence d'un club parent force l'adhésion au club parent avant de pouvoir adhérer au dit club. Tout club qui n'est pas le club BDE doit avoir le club BDE dans son arborescence.
|
||||
* ``email`` : ``EmailField``, adresse e-mail sur laquelle contacter le bureau du club.
|
||||
* ``membership_start`` : ``DateField``, date à partir de laquelle il est possible d'adhérer à un club pour l'année suivante (si adhésions à l'année), en ignorant l'année. Par exemple, l'adhésion BDE est possible à partir du 31/08 par défaut, et c'est à cette date que les adhésions pour l'année future est possible.
|
||||
* ``membership_start`` : ``DateField``, date à partir de laquelle il est possible d'adhérer à un club pour l'année suivante (si adhésions à l'année), en ignorant l'année. Par exemple, l'adhésion BDE est possible à partir du 01/08 par défaut, et c'est à cette date que les adhésions pour l'année future est possible.
|
||||
* ``membership_end`` : ``DateField``, date maximale de fin d'adhésion. Pour le club BDE, il s'agit du 30/09 de l'année suivante. Si cette valeur vaut ``null``, la fin d'adhésion n'est pas limitée.
|
||||
* ``membership_duration`` : ``PositiveIntegerField``, durée (en jours) maximale d'adhésion. Par exemple, le club BDE permet des adhésions maximales de 13 mois, soit 396 jours.
|
||||
* ``membership_fee_paid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un élève normalien (donc rémunéré) puisse adhérer.
|
||||
* ``membership_fee_unpaid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un étudiant normalien (donc non rémunéré) puisse adhérer.
|
||||
* ``membership_fee_paid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un⋅e élève normalien⋅ne (donc rémunéré⋅e) puisse adhérer.
|
||||
* ``membership_fee_unpaid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un⋅e étudiant⋅e normalien⋅ne (donc non rémunéré) puisse adhérer.
|
||||
* ``name`` : ``CharField``, nom du club.
|
||||
* ``require_memberships`` : ``BooleanField``, indique si le club est un vrai club BDE qui nécessite des adhésions de club, ou s'il s'agit d'une note "pot commun" (organisation d'une activité, note de département, ...)
|
||||
|
||||
@ -67,16 +67,16 @@ Adhésions
|
||||
Comme indiqué précédemment, la note gère les adhésions.
|
||||
|
||||
* ``club`` : ``ForeignKey(Club)``, club lié à l'adhésion.
|
||||
* ``user`` : ``ForeignKey(User)``, utilisateur adhéré.
|
||||
* ``user`` : ``ForeignKey(User)``, utilisateur⋅rice qui a adhéré.
|
||||
* ``date_start`` : ``DateField``, date de début d'adhésion.
|
||||
* ``date_end`` : ``DateField``, date de fin d'adhésion.
|
||||
* ``fee`` : ``PositiveIntegerField``, montant de la cotisation payée.
|
||||
* ``roles`` : ``ManyToManyField(Role)``, liste des rôles endossés par l'adhérent.
|
||||
* ``roles`` : ``ManyToManyField(Role)``, liste des rôles endossés par l'adhérent⋅e.
|
||||
|
||||
Rôles
|
||||
~~~~~
|
||||
|
||||
Comme indiqué le modèle des adhésions, les adhésions octroient des rôles aux adhérents, qui offrent des permissions
|
||||
Comme indiqué le modèle des adhésions, les adhésions octroient des rôles aux adhérent⋅es, qui offrent des permissions
|
||||
(cf ``RolesPermissions`` dans la page des permissions). Le modèle ``RolesPermissions`` possède un
|
||||
``OneToOneField(Role)``, qui implémente les permissions des rôles. Le modèle ``Role`` à proprement parler ne contient
|
||||
que le champ de son nom (``CharField``).
|
||||
@ -88,7 +88,7 @@ Si le modèle ``MembershipTransaction`` appartient à l'application ``note``, il
|
||||
Le modèle ``MembershipTransaction`` est une extension du modèle ``Transaction`` (application ``note``) qui est de type
|
||||
polymorphique, et contient en plus des informations de base de la transaction un champ ``OneToOneField(Membership)``
|
||||
faisant le lien entre l'adhésion et la transaction liée. Une adhésion club, si elle n'est pas gratuite,
|
||||
génère en effet automatiquement une transaction de l'utilisateur vers le club (voir section adhésions).
|
||||
génère en effet automatiquement une transaction de l'utilisateur⋅rice vers le club (voir section adhésions).
|
||||
|
||||
Graphe
|
||||
------
|
||||
@ -100,28 +100,28 @@ Adhésions
|
||||
---------
|
||||
|
||||
La Note Kfet offre la possibilité aux clubs de gérer l'adhésion de leurs membres. En plus de réguler les cotisations
|
||||
des adhérents, des permissions sont octroyées sur la note en fonction des rôles au sein des clubs. Un rôle est une
|
||||
fonction occupée au sein d'un club (Trésorier de club, président de club, GCKfet, Res[pot], respo info, ...).
|
||||
Une adhésion attribue à un adhérent ses rôles. Les rôles fournissent les permissions. Par exemple, le trésorier d'un
|
||||
des adhérent⋅es, des permissions sont octroyées sur la note en fonction des rôles au sein des clubs. Un rôle est une
|
||||
fonction occupée au sein d'un club (Trésorièr⋅e de club, président⋅e de club, GC Kfet, Res[pot], respo info,…).
|
||||
Une adhésion attribue à un⋅e adhérent⋅e ses rôles. Les rôles fournissent les permissions. Par exemple, læ trésorièr⋅e d'un
|
||||
club a le droit de faire des transferts de et vers la note du club, tant que la source reste au-dessus de -50 €.
|
||||
Une adhésion est considérée comme valide si la date du jour est comprise (au sens large) entre les dates de début et
|
||||
de fin d'adhésion.
|
||||
|
||||
On peut ajouter une adhésion à un utilisateur dans un club à tout non adhérent de ce club. La personne en charge
|
||||
d'adhérer quelqu'un choisit l'utilisateur, les rôles au sein du club et la date de début d'adhésion. Cette date de
|
||||
On peut ajouter une adhésion à un⋅e utilisateur⋅rice dans un club à tout⋅e non adhérent⋅e de ce club. La personne en charge
|
||||
d'adhérer quelqu'un choisit l'utilisateur⋅rice, les rôles au sein du club et la date de début d'adhésion. Cette date de
|
||||
début d'adhésion doit se situer entre les champs ``club.membership_start`` et ``club.membership_end``,
|
||||
si ces champs sont non nuls. Si ``club.parent_club`` n'est pas nul, l'utilisateur doit être membre de ce club.
|
||||
Le montant de la cotisation est fixé en fonction du statut normalien de l'utilisateur (``club.membership_fee_paid``
|
||||
centimes pour les élèves et ``club.membership_fee_unpaid`` centimes pour les étudiants). La date de fin est calculée
|
||||
si ces champs sont non nuls. Si ``club.parent_club`` n'est pas nul, l'utilisateur⋅rice doit être membre de ce club.
|
||||
Le montant de la cotisation est fixé en fonction du statut normalien de l'utilisateur⋅rice (``club.membership_fee_paid``
|
||||
centimes pour les élèves et ``club.membership_fee_unpaid`` centimes pour les étudiant⋅es). La date de fin est calculée
|
||||
comme ce qui suit :
|
||||
|
||||
* Si ``club.membership_duration`` est non nul, alors ``date_end`` = ``date_start`` + ``club.membership_duration``
|
||||
* Sinon ``club``, ``date_end`` = ``date_start`` + 424242 jours (suffisant pour tenir au moins une vie)
|
||||
* Si ``club.membership_end`` est non nul, alors ``date_end`` = min(``date_end``, ``club.membership_end``)
|
||||
|
||||
Si l'utilisateur n'est pas membre du club ``Kfet``, l'adhésion n'est pas possible si le solde disponible sur sa note est
|
||||
Si l'utilisateur⋅rice n'est pas membre du club ``Kfet``, l'adhésion n'est pas possible si le solde disponible sur sa note est
|
||||
insuffisant. Une fois toute ces contraintes vérifiées, l'adhésion est créée. Une transaction de type
|
||||
``MembershipTransaction`` est automatiquement créée de la note de l'utilisateur vers la note du club, finalisant l'adhésion.
|
||||
``MembershipTransaction`` est automatiquement créée de la note de l'utilisateur⋅rice vers la note du club, finalisant l'adhésion.
|
||||
|
||||
Réadhésions
|
||||
~~~~~~~~~~~
|
||||
@ -137,7 +137,7 @@ Il est possible de réadhérer si :
|
||||
* Il n'y a pas encore de réadhésion (pas d'adhésion au même club vérifiant ``new_membership.date_start`` >= ``club.membership_start``)
|
||||
|
||||
Un bouton ``Réadhérer`` apparaît dans la liste des adhésions si le droit est permis et si ces contraintes sont vérifiées.
|
||||
En réadhérant, une nouvelle adhésion est créée pour l'utilisateur avec les mêmes rôles, commençant le lendemain de la
|
||||
En réadhérant, une nouvelle adhésion est créée pour l'utilisateur⋅rice avec les mêmes rôles, commençant le lendemain de la
|
||||
date d'expiration de la précédente adhésion. Si on réadhère le 16 août pour une adhésion finissant le 30 septembre,
|
||||
la nouvelle adhésion commencera le 1er octobre).
|
||||
|
||||
|
||||
@ -7,23 +7,23 @@ Affichage
|
||||
La page de consommations est principalement une communication entre l'`API <../api>`_ et la page en JavaScript.
|
||||
Elle est disponible à l'adresse ``/note/consos/``, et l'onglet n'est visible que pour ceux ayant le droit de voir au
|
||||
moins un bouton. L'affichage, comme tout le reste de la page, est géré avec Boostrap 4.
|
||||
Les boutons que l'utilisateur a le droit de voir sont triés par catégorie.
|
||||
Les boutons que l'utilisateur⋅rice a le droit de voir sont triés par catégorie.
|
||||
|
||||
Sélection des consommations
|
||||
---------------------------
|
||||
|
||||
Lorsque l'utilisateur commence à taper un nom de note, un appel à l'API sur la page ``/api/note/alias`` est fait,
|
||||
récupérant les 20 premiers aliases en accord avec la requête. Quand l'utilisateur survole un alias, un appel à la page
|
||||
Lorsque l'utilisateur⋅rice commence à taper un nom de note, un appel à l'API sur la page ``/api/note/alias`` est fait,
|
||||
récupérant les 20 premiers aliases en accord avec la requête. Quand l'utilisateur⋅rice survole un alias, un appel à la page
|
||||
``/api/note/note/<NOTE_ID>/`` est fait pour récupérer plus d'infos sur la note telles que le solde, le vrai nom de la
|
||||
note et la photo, si toutefois l'utilisateur a le droit de voir ceci.
|
||||
note et la photo, si toutefois l'utilisateur⋅rice a le droit de voir ceci.
|
||||
|
||||
L'utilisateur peut cliquer sur des aliases pour ajouter des émetteurs, et sur des boutons pour ajouter des consommations.
|
||||
Cliquer dans la liste des émetteurs supprime l'élément sélectionné.
|
||||
L'utilisateur⋅rice peut cliquer sur des aliases pour ajouter des émetteur⋅rices, et sur des boutons pour ajouter des consommations.
|
||||
Cliquer dans la liste des émetteur⋅rices supprime l'élément sélectionné.
|
||||
|
||||
Il ya deux possibilités pour faire consommer des adhérents :
|
||||
- En mode **consommation simple** (mode par défaut), les consommations sont débitées dès que émetteurs et consommations
|
||||
Il y a deux possibilités pour faire consommer des adhérent⋅es :
|
||||
- En mode **consommation simple** (mode par défaut), les consommations sont débitées dès que émetteur⋅rices et consommations
|
||||
sont renseignées.
|
||||
- En mode **consommation double**, l'utilisateur doit cliquer sur "Consommer !" pour débiter toutes les consommations.
|
||||
- En mode **consommation double**, l'utilisateur⋅rice doit cliquer sur « **Consommer !** »" pour débiter toutes les consommations.
|
||||
|
||||
Débit des consommations
|
||||
-----------------------
|
||||
@ -71,7 +71,7 @@ des types. Il vaut `42` lors de la rédaction de cette documentation, mais pourr
|
||||
Si une erreur survient lors de la requête (droits insuffisants), un message apparaîtra en haut de page.
|
||||
Dans tous les cas, tous les champs sont réinitialisés.
|
||||
|
||||
L'historique et la balance de l'utilisateur sont ensuite mis à jour via jQuery, qui permet de recharger une partie de page Web.
|
||||
L'historique et le solde de l'utilisateur⋅rice sont ensuite mis à jour via jQuery, qui permet de recharger une partie de page Web.
|
||||
|
||||
Validation/dévalidation des transactions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -86,4 +86,4 @@ une requête PATCH est faite à l'API sur l'adresse ``/api/note/transaction/tran
|
||||
"valid": false
|
||||
}
|
||||
|
||||
L'historique et la balance sont ensuite rafraîchis. Si une erreur survient, un message apparaîtra.
|
||||
L'historique et le solde sont ensuite rafraîchis. Si une erreur survient, un message apparaîtra.
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
Application Note
|
||||
================
|
||||
|
||||
L'application ``note`` gère tout ce qui est en lien avec les flux d'argent et les notes (balances) des utilisateurs.
|
||||
L'application ``note`` gère tout ce qui est en lien avec les flux d'argent et les notes (soldes) des utilisateur⋅rices.
|
||||
|
||||
La gestion des consommations s'effectue principalement via la page dédiée, dont le fonctionnement est expliqué
|
||||
dans la page `Consommations <consumptions>`_.
|
||||
|
||||
Le fonctionnnemnent des crédit/débit de note (avec le "monde extérieur" donc avec de l'argent réel) ainsi que les
|
||||
Le fonctionnement des crédit/débit de note (avec le « monde extérieur » donc avec de l'argent réel) ainsi que les
|
||||
transferts/dons entre notes est détaillé sur la page `Transferts <transactions>`_.
|
||||
|
||||
.. toctree::
|
||||
|
||||
@ -6,7 +6,7 @@ Affichage
|
||||
|
||||
L'interface de la page de transferts est semblable à celles des consommations, et l'auto-complétion de note est géré de
|
||||
la même manière. La page se trouve à l'adresse ``/note/transfer/``. La liste des 20 transactions les plus récentes que
|
||||
l'utilisateur a le droit de voir est également présente.
|
||||
l'utilisateur⋅rice a le droit de voir est également présente.
|
||||
|
||||
Des boutons ``Don``, ``Transfert``, ``Crédit``, ``Retrait`` sont présents, représentant les différents modes de
|
||||
transfert. Pour chaque transfert, un montant et une description sont attendus.
|
||||
@ -23,7 +23,7 @@ Onglets Crédit et retrait
|
||||
Ces onglets ne sont visibles que par ceux qui ont le droit de voir les ``SpecialNote``.
|
||||
|
||||
Une boîte supplémentaire apparaît, demandant en plus de la note, du montant et de la raison le nom, le prénom et
|
||||
la banque de la personne à recharger/retirer. Lorsqu'une note est sélectionnée, les champs "nom" et "prénom" sont
|
||||
la banque de la personne à recharger/retirer. Lorsqu'une note est sélectionnée, les champs « nom » et « prénom » sont
|
||||
remplis automatiquement. Par ailleurs, seule une note peut être choisie.
|
||||
|
||||
Transfert
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Droits
|
||||
======
|
||||
|
||||
Le système de droit par défault de django n'est pas suffisament granulaire pour les besoins de la NoteKfet2020.
|
||||
Un système custom a donc été développé.
|
||||
Le système de droit par défaut de Django n'est pas suffisamment granulaire pour les besoins de la Note Kfet 2020.
|
||||
Un système personnalisé a donc été développé.
|
||||
|
||||
Il permet la création de Permission, qui autorise ou non a faire une action précise sur un ou des objets
|
||||
de la base de données.
|
||||
@ -22,12 +22,12 @@ Une permission est un Model Django dont les principaux attributs sont :
|
||||
* ``query`` : Requête sur la cible, encodé en JSON, traduit en un Q object (cf `Query <#compilation-de-la-query>`_)
|
||||
* ``field`` : le champ cible qui pourra être modifié. (tous les champs si vide)
|
||||
|
||||
Pour savoir si un utilisateur a le droit sur un modèle ou non, la requête est compilée (voir ci-dessous) en un filtre
|
||||
de requête dans la base de données, un objet de la classe ``Q`` (En SQL l'objet Q s'interprete comme tout ce qui suit
|
||||
Pour savoir si un⋅e utilisateur⋅rice a le droit sur un modèle ou non, la requête est compilée (voir ci-dessous) en un filtre
|
||||
de requête dans la base de données, un objet de la classe ``Q`` (En SQL l'objet Q s'interprète comme tout ce qui suit
|
||||
un ``WHERE ...`` Ils peuvent être combiné à l'aide d'opérateurs logiques. Plus d'information sur les Q object dans la
|
||||
`documentation officielle <https://docs.djangoproject.com/fr/2.2/topics/db/queries/#complex-lookups-with-q-objects>`_.
|
||||
|
||||
Ce Q object sera donc utilisé pour savoir si l'instance que l'on veux modifier est concernée par notre permission.
|
||||
Ce Q object sera donc utilisé pour savoir si l'instance que l'on veut modifier est concernée par notre permission.
|
||||
|
||||
Exception faite sur l'ajout d'objets : l'objet n'existant pas encore en base de données, il est ajouté puis supprimé
|
||||
à la volée, en prenant soin de désactiver les signaux.
|
||||
@ -36,7 +36,7 @@ Compilation de la query
|
||||
-----------------------
|
||||
|
||||
La query est enregistrée sous un format JSON, puis est traduite en requête ``Q`` récursivement en appliquant certains paramètres.
|
||||
Le fonctionnemente de base des permission peux être décris avec les differents opérations :
|
||||
Le fonctionnemente de base des permission peux être décris avec les différents opérations :
|
||||
|
||||
+----------------+-----------------------------+-------------------------------------+
|
||||
| opérations | JSON | Q object |
|
||||
@ -64,7 +64,7 @@ Exemples
|
||||
|
||||
{"is_superuser": true}
|
||||
|
||||
| si l'utilisateur cible est un super utilisateur.
|
||||
| si l'utilisateur⋅rice cible est un⋅e super utilisateur⋅rice.
|
||||
|
||||
* sur le model ``Note`` :
|
||||
|
||||
@ -74,7 +74,7 @@ Exemples
|
||||
["user","note", "pk"]
|
||||
}
|
||||
|
||||
| si l'identifiant de la note cible est l'identifiant de l'utilisateur dont on regarde la permission.
|
||||
| si l'identifiant de la note cible est l'identifiant de l'utilisateur⋅rice dont on regarde la permission.
|
||||
|
||||
* sur le model ``Transaction``:
|
||||
|
||||
@ -87,7 +87,7 @@ Exemples
|
||||
["user", "note", "balance"]}
|
||||
]
|
||||
|
||||
| si la source est la note de l'utilisateur et si le montant est inférieur à son solde.
|
||||
| si la source est la note de l'utilisateur⋅rice et si le montant est inférieur à son solde.
|
||||
|
||||
* Sur le model ``Alias``
|
||||
|
||||
@ -106,7 +106,7 @@ Exemples
|
||||
}
|
||||
]
|
||||
|
||||
| si l'alias appartient à une note de club ou s'il appartient à la note d'un utilisateur membre du club Kfet.
|
||||
| si l'alias appartient à une note de club ou s'il appartient à la note d'un⋅e utilisateur⋅rice membre du club Kfet.
|
||||
|
||||
* sur le model ``Transaction``
|
||||
|
||||
@ -130,19 +130,19 @@ Exemples
|
||||
Masques de permissions
|
||||
----------------------
|
||||
|
||||
Chaque permission est associée à un masque. À la connexion, l'utilisateur choisit le masque de droits avec lequel il
|
||||
souhaite se connecter. Les masques sont ordonnés totalement, et l'utilisateur aura effectivement une permission s'il est
|
||||
Chaque permission est associée à un masque. À la connexion, l'utilisateur⋅rice choisit le masque de droits avec lequel iel
|
||||
souhaite se connecter. Les masques sont ordonnés totalement, et l'utilisateur⋅rice aura effectivement une permission si iel est
|
||||
en droit d'avoir la permission et si son masque est suffisamment haut.
|
||||
|
||||
Par exemple, si la permission de voir toutes les transactions est associée au masque "Droits note uniquement",
|
||||
se connecter avec le masque "Droits basiques" n'octroiera pas cette permission tandis que le masque "Tous mes droits" oui.
|
||||
Par exemple, si la permission de voir toutes les transactions est associée au masque « Droits note uniquement »,
|
||||
se connecter avec le masque « Droits basiques » n'octroiera pas cette permission tandis que le masque « Tous mes droits » oui.
|
||||
|
||||
Signaux
|
||||
-------
|
||||
|
||||
À chaque fois qu'un modèle est modifié, ajouté ou supprimé, les droits sont contrôlés. Si les droits ne sont pas
|
||||
suffisants, une erreur est lancée. Pour ce qui est de la modification, on ne contrôle que les champs réellement
|
||||
modifiés en comparant l'ancienne et la nouvele instance.
|
||||
modifiés en comparant l'ancienne et la nouvelle instance.
|
||||
|
||||
Graphe des modèles
|
||||
------------------
|
||||
|
||||
@ -4,7 +4,7 @@ Inscriptions
|
||||
L'inscription a la note se fait via une application dédiée, sans toutefois avoir de modèle en base de données.
|
||||
|
||||
Un formulaire d'inscription est disponible sur la page ``/registration/signup``, accessible depuis n'importe qui,
|
||||
authentifié ou non. Les informations suivantes sont demandées :
|
||||
authentifié⋅e ou non. Les informations suivantes sont demandées :
|
||||
|
||||
* Prénom
|
||||
* Nom de famille
|
||||
@ -15,7 +15,7 @@ authentifié ou non. Les informations suivantes sont demandées :
|
||||
* Département d'études
|
||||
* Promotion, année d'entrée à l'ENS
|
||||
* Adresse (optionnel)
|
||||
* Payé (si la personne perçoit un salaire)
|
||||
* Payé⋅e (si la personne perçoit un salaire)
|
||||
|
||||
Le mot de passe doit vérifier des contraintes de longueur, de complexité et d'éloignement des autres informations
|
||||
personnelles.
|
||||
@ -34,28 +34,28 @@ le compte sera enfin actif.
|
||||
Pour récapituler : compte actif = adresse e-mail validée + inscription validée par le BDE.
|
||||
|
||||
Lors de la validation de l'inscription, le BDE peut (et doit même) faire un crédit initial sur la future note de
|
||||
l'utilisateur. Il peut spécifier le type de crédit (carte bancaire/espèces/chèque/virement bancaire), le prénom,
|
||||
l'utilisateur⋅rice. Il peut spécifier le type de crédit (carte bancaire/espèces/chèque/virement bancaire), le prénom,
|
||||
le nom et la banque comme un crédit normal. Cependant, il peut aussi cocher une case "Société générale", si le nouveau
|
||||
membre indique avoir ouvert un compte à la Société générale via le partenariat Société générale - BDE de
|
||||
l'ÉNS Paris-Saclay. Dans ce cas, tous les champs sont grisés.
|
||||
|
||||
Une fois l'inscription validée, détail de ce qu'il se passe :
|
||||
|
||||
* Si crédit de la socitété générale, on mémorise que le fait que la personne ait demandé ce crédit (voir
|
||||
* Si crédit de la société générale, on mémorise que le fait que la personne ait demandé ce crédit (voir
|
||||
`Trésorerie <treasury>`_ section crédits de la société générale). Nécessairement, le club Kfet doit être rejoint.
|
||||
* Sinon, on crédite la note du montant demandé par le nouveau membre (avec comme description "Crédit TYPE (Inscription)"
|
||||
* Sinon, on crédite la note du montant demandé par læ nouvelleau membre (avec comme description "Crédit TYPE (Inscription)"
|
||||
où TYPE est le type de crédit), après avoir vérifié que le crédit est suffisant (on n'ouvre pas une note négative)
|
||||
* On adhère la personne au BDE, l'adhésion commence aujourd'hui. Il dispose d'un unique rôle : "Adhérent BDE",
|
||||
* On adhère la personne au BDE, l'adhésion commence aujourd'hui. Iel dispose d'un unique rôle : « Adhérent⋅e BDE »,
|
||||
lui octroyant un faible nombre de permissions de base, telles que la visualisation de son compte.
|
||||
* On adhère la personne au club Kfet si cela est demandé, l'adhésion commence aujourd'hui. Il dispose d'un unique rôle :
|
||||
"Adhérent Kfet", lui octroyant un nombre un peu plus conséquent de permissions basiques, telles que la possibilité de
|
||||
faire des transactions, d'accéder aux activités, au WEI, ...
|
||||
* Si le nouveau membre a indiqué avoir ouvert un compte à la société générale, alors les transactions sont invalidées,
|
||||
* On adhère la personne au club Kfet si cela est demandé, l'adhésion commence aujourd'hui. Iel dispose d'un unique rôle :
|
||||
« Adhérent⋅e Kfet » , lui octroyant un nombre un peu plus conséquent de permissions basiques, telles que la possibilité de
|
||||
faire des transactions, d'accéder aux activités, au WEI,…
|
||||
* Si læ nouvelleau membre a indiqué avoir ouvert un compte à la société générale, alors les transactions sont invalidées,
|
||||
la note n'est pas débitée (commence alors à 0 €).
|
||||
|
||||
Par ailleurs, le BDE peut supprimer la demande d'inscription sans problème via un bouton dédié. Cette opération
|
||||
n'est pas réversible.
|
||||
|
||||
L'utilisateur a enfin accès a sa note et peut faire des bêtises :)
|
||||
L'utilisateur⋅rice a enfin accès a sa note et peut faire des bêtises :)
|
||||
|
||||
L'inscription au BDE et à la Kfet est indépendante de l'inscription au WEI. Voir `WEI <wei>`_ pour l'inscription WEI.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Application Trésorerie
|
||||
======================
|
||||
|
||||
L'application de Trésorerie facilite la vie des trésorier, et sert d'interface de création de facture.
|
||||
L'application de Trésorerie facilite la vie des trésorièr⋅es, et sert d'interface de création de facture.
|
||||
Elle permet également le suivi des remises de chèques reçus par le BDE et des crédits de la Société générale.
|
||||
|
||||
Factures
|
||||
@ -90,7 +90,7 @@ présent à l'adresse suivante :
|
||||
|
||||
On le remplit avec les données de la facture et les données du BDE, hard-codées. On copie le template rempli dans un
|
||||
ficher tex dans un dossier temporaire. On fait ensuite 2 appels à ``pdflatex`` pour générer la facture au format PDF.
|
||||
Les deux appels sont nécessaires, il y a besoin d'un double rendu. Ensuite, le PDF est envoyé à l'utilisateur et on
|
||||
Les deux appels sont nécessaires, il y a besoin d'un double rendu. Ensuite, le PDF est envoyé à l'utilisateur⋅rice et on
|
||||
supprime les données temporaires.
|
||||
|
||||
On remarque que les PDF sont générés à la volée et ne sont pas sauvegardés. Niveau performances, cela prend du temps
|
||||
@ -155,7 +155,7 @@ Relations
|
||||
~~~~~~~~~
|
||||
|
||||
* Toute transaction qui n'est pas attachée à une remise d'un bon type peut être attachée à une remise. Cela se passe
|
||||
par le biais d'un formulaire, où le trésorier peut vérifier et corriger au besoin nom, prénom, banque émettrice et montant.
|
||||
par le biais d'un formulaire, où læ trésorièr⋅e peut vérifier et corriger au besoin nom, prénom, banque émettrice et montant.
|
||||
|
||||
* Toute transaction attachée à une remise encore ouverte peut être retirée.
|
||||
* Pour clore une remise, il faut au moins 1 transaction associée.
|
||||
@ -174,39 +174,39 @@ Modèle
|
||||
|
||||
Cette sous-application dispose d'un unique modèle "SogeCredit" avec les champs suivant :
|
||||
|
||||
* ``user`` : ``OneToOneField`` vers ``User``, utilisateur associé à ce crédit (relation ``OneToOne`` car chaque
|
||||
utilisateur ne peut bénéficier qu'une seule fois d'un crédit de la Société générale)
|
||||
* ``user`` : ``OneToOneField`` vers ``User``, utilisateur⋅rice associé à ce crédit (relation ``OneToOne`` car chaque
|
||||
utilisateur⋅rice ne peut bénéficier qu'une seule fois d'un crédit de la Société générale)
|
||||
* ``transactions`` : ``ManyToManyField`` vers ``MembershipTransaction``, liste des transactions d'adhésion associées
|
||||
à ce crédit, généralement adhésion BDE+Kfet+WEI même si cela n'est pas restreint
|
||||
* ``credit_transaction`` : ``OneToOneField`` vers ``SpecialTransaction``, peut être nulle, transaction de crédit de la
|
||||
Société générale vers la note de l'utilisateur si celui-ci a été validé. C'est d'ailleurs le témoin
|
||||
Société générale vers la note de l'utilisateur⋅rice si celui-ci a été validé. C'est d'ailleurs le témoin
|
||||
de validation du crédit.
|
||||
|
||||
On sait qu'un utilisateur a déjà demandé un crédit de la Société générale s'il existe un crédit associé à cet
|
||||
utilisateur avec une transaction associée. Par ailleurs, le modèle ``Profile`` contient une propriété ``soge`` qui
|
||||
On sait qu'un⋅e utilisateur⋅rice a déjà demandé un crédit de la Société générale s'il existe un crédit associé à cet⋅te
|
||||
utilisateur⋅rice avec une transaction associée. Par ailleurs, le modèle ``Profile`` contient une propriété ``soge`` qui
|
||||
traduit exactement ceci, et qui vaut ``False`` si jamais l'application Trésorerie n'est pas chargée.
|
||||
|
||||
Si jamais l'utilisateur n'a pas encore demandé de crédit de la Société générale (ou que celui-ci n'est pas encore validé),
|
||||
l'utilisateur peut demander un tel crédit lors de son adhésion BDE, de sa réadhésion BDE ou de son inscription au WEI.
|
||||
Dans les deux premiers cas, il est invité à jumeler avec une nouvelle adhésion Kfet (merci de d'abord se réadhérer au
|
||||
Si jamais l'utilisateur⋅rice n'a pas encore demandé de crédit de la Société générale (ou que celui-ci n'est pas encore validé),
|
||||
l'utilisateur⋅rice peut demander un tel crédit lors de son adhésion BDE, de sa réadhésion BDE ou de son inscription au WEI.
|
||||
Dans les deux premiers cas, iel est invité⋅e à jumeler avec une nouvelle adhésion Kfet (merci de d'abord se réadhérer au
|
||||
BDE avant la Kfet dans ce cas).
|
||||
|
||||
Lorsqu'une telle demande est faite, l'adhésion est créée avec une transaction d'adhésion invalide. Cela implique que
|
||||
la note source n'est pas débitée et la note destination n'est pas créditée.
|
||||
|
||||
Sur son interface, le trésorier peut récupérer les crédits de Société générale invalides. Deux options s'offrent à lui :
|
||||
Sur son interface, læ trésorièr⋅e peut récupérer les crédits de Société générale invalides. Deux options s'offrent à ellui :
|
||||
|
||||
* Supprimer la demande. Dans ce cas, les transactions vont être validées, la note de l'utilisateur sera débité, les
|
||||
clubs seront crédités. Puisque la demande sera supprimée, l'utilisateur pourra à nouveau à l'avenir déclarer avoir
|
||||
ouvert un compte à la Société générale. Cette option est utile dans le cas où l'utilisateur est un boulet (ou pas,
|
||||
* Supprimer la demande. Dans ce cas, les transactions vont être validées, la note de l'utilisateur⋅rice sera débité, les
|
||||
clubs seront crédités. Puisque la demande sera supprimée, l'utilisateur⋅rice pourra à nouveau à l'avenir déclarer avoir
|
||||
ouvert un compte à la Société générale. Cette option est utile dans le cas où l'utilisateur⋅rice est un boulet (ou pas,
|
||||
pour d'autres raisons) et a déclaré vouloir ouvrir un compte à la Société générale sans ne rien faire.
|
||||
Cette action est irréversible, et n'est pas possible si la note de l'utilisateur n'a pas un solde suffisant.
|
||||
Cette action est irréversible, et n'est pas possible si la note de l'utilisateur⋅rice n'a pas un solde suffisant.
|
||||
|
||||
* Valider la demande. Dans ce cas, un crédit de la note "Virements bancaires" vers la note de l'utilisateur sera créé,
|
||||
* Valider la demande. Dans ce cas, un crédit de la note "Virements bancaires" vers la note de l'utilisateur⋅rice sera créé,
|
||||
la transaction sera liée à la demande via le champ ``credit_note`` (et donc la demande déclarée valide), et toutes les
|
||||
transactions d'adhésion seront déclarées valides.
|
||||
|
||||
* Demander à un respo info s'il y a un problème pour le régler avant de faire des bêtises. Je l'admets, ça fait trois options.
|
||||
* Demander à un⋅e respo info s'il y a un problème pour le régler avant de faire des bêtises. Je l'admets, ça fait trois options.
|
||||
|
||||
La validité d'une transaction d'adhésion n'a aucune influence sur l'adhésion elle-même. Toutefois, cela se remarque rapidement ...
|
||||
|
||||
|
||||
@ -19,14 +19,14 @@ Champs hérités de ``Club`` de l'application ``member`` :
|
||||
|
||||
* ``parent_club`` : ``ForeignKey(Club)``. Ce champ vaut toujours ``Kfet`` dans le cas d'un WEI : on doit être membre du
|
||||
club Kfet pour participer au WEI.
|
||||
* ``email`` : ``EmailField``, adresse e-mail sur laquelle contacter les gérants du WEI.
|
||||
* ``email`` : ``EmailField``, adresse e-mail sur laquelle contacter les gérant⋅es du WEI.
|
||||
* ``membership_start`` : ``DateField``, date à partir de laquelle il est possible de s'inscrire au WEI.
|
||||
* ``membership_end`` : ``DateField``, date de fin d'adhésion possible au WEI.
|
||||
* ``membership_duration`` : ``PositiveIntegerField``, inutilisé dans le cas d'un WEI, vaut ``None``.
|
||||
* ``membership_fee_paid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un élève normalien
|
||||
(donc rémunéré) puisse adhérer.
|
||||
* ``membership_fee_unpaid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un étudiant
|
||||
normalien (donc non rémunéré) puisse adhérer.
|
||||
* ``membership_fee_paid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un⋅e élève normalien⋅ne
|
||||
(donc rémunéré⋅e) puisse adhérer.
|
||||
* ``membership_fee_unpaid`` : ``PositiveIntegerField``, montant de la cotisation (en centimes) pour qu'un⋅e étudiant⋅e
|
||||
normalien⋅ne (donc non rémunéré⋅e) puisse adhérer.
|
||||
* ``name`` : ``CharField``, nom du WEI.
|
||||
* ``require_memberships`` : ``BooleanField``, vaut toujours ``True`` pour le WEI.
|
||||
|
||||
@ -65,27 +65,27 @@ que de dissocier les rôles propres au WEI des rôles s'appliquant pour n'import
|
||||
WEIRegistration
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Inscription au WEI, contenant les informations avant validation. Ce modèle est créé dès lors que quelqu'un se pré-inscrit au WEI.
|
||||
Inscription au WEI, contenant les informations avant validation. Ce modèle est créé dès lors que quelqu'un⋅e se pré-inscrit au WEI.
|
||||
|
||||
* ``user`` : ``ForeignKey(User)``, utilisateur qui s'est pré-inscrit. Ce champ est unique avec ``wei``.
|
||||
* ``wei`` : ``ForeignKey(WEIClub)``, le WEI auquel l'utilisateur s'est pré-inscrit. Ce champ est unique avec ``user``.
|
||||
* ``soge_credit`` : ``BooleanField``, indique si l'utilisateur a déclaré vouloir ouvrir un compte à la Société générale.
|
||||
* ``caution_check`` : ``BooleanField``, indique si l'utilisateur (en 2ème année ou plus) a bien remis son chèque de
|
||||
* ``user`` : ``ForeignKey(User)``, utilisateur⋅rice qui s'est pré-inscrit⋅e. Ce champ est unique avec ``wei``.
|
||||
* ``wei`` : ``ForeignKey(WEIClub)``, le WEI auquel l'utilisateur⋅rice s'est pré-inscrit⋅e. Ce champ est unique avec ``user``.
|
||||
* ``soge_credit`` : ``BooleanField``, indique si l'utilisateur⋅rice a déclaré vouloir ouvrir un compte à la Société générale.
|
||||
* ``caution_check`` : ``BooleanField``, indique si l'utilisateur⋅rice (en 2ème année ou plus) a bien remis son chèque de
|
||||
caution auprès de la trésorerie.
|
||||
* ``birth_date`` : ``DateField``, date de naissance de l'utilisateur.
|
||||
* ``birth_date`` : ``DateField``, date de naissance de l'utilisateur⋅rice.
|
||||
* ``gender`` : ``CharField`` parmi ``male`` (Homme), ``female`` (Femme), ``non binary`` (Non binaire), genre de la personne.
|
||||
* ``health_issues`` : ``TextField``, problèmes de santé déclarés par l'utilisateur.
|
||||
* ``health_issues`` : ``TextField``, problèmes de santé déclarés par l'utilisateur⋅rice.
|
||||
* ``emergency_contact_name`` : ``CharField``, nom du contact en cas d'urgence.
|
||||
* ``emergency_contact_phone`` : ``CharField``, numéro de téléphone du contact en cas d'urgence.
|
||||
* ``ml_events_registration`` : ``BooleanField``, déclare si l'utilisateur veut s'inscrire à la liste de diffusion des
|
||||
* ``ml_events_registration`` : ``BooleanField``, déclare si l'utilisateur⋅rice veut s'inscrire à la liste de diffusion des
|
||||
événements du BDE (1A uniquement)
|
||||
* ``ml_art_registration`` : ``BooleanField``, déclare si l'utilisateur veut s'inscrire à la liste de diffusion des
|
||||
* ``ml_art_registration`` : ``BooleanField``, déclare si l'utilisateur⋅rice veut s'inscrire à la liste de diffusion des
|
||||
actualités du BDA (1A uniquement)
|
||||
* ``ml_sport_registration`` : ``BooleanField``, déclare si l'utilisateur veut s'inscrire à la liste de diffusion des
|
||||
* ``ml_sport_registration`` : ``BooleanField``, déclare si l'utilisateur⋅rice veut s'inscrire à la liste de diffusion des
|
||||
actualités du BDS (1A uniquement)
|
||||
* ``first_year`` : ``BooleanField``, indique si l'inscription est d'un 1A ou non. Non modifiable par n'importe qui.
|
||||
* ``first_year`` : ``BooleanField``, indique si l'inscription est d'un⋅e 1A ou non. Non modifiable par n'importe qui.
|
||||
* ``information_json`` : ``TextField`` non modifiable manuellement par n'importe qui stockant les informations du
|
||||
questionnaire d'inscription au WEI pour les 1A, et stocke les demandes faites par un 2A+ concerant bus, équipes et rôles.
|
||||
questionnaire d'inscription au WEI pour les 1A, et stocke les demandes faites par un⋅e 2A+ concernant bus, équipes et rôles.
|
||||
On utilise un ``TextField`` contenant des données au format JSON pour permettre de la modularité au fil des années,
|
||||
sans avoir à tout casser à chaque fois.
|
||||
|
||||
@ -94,19 +94,19 @@ WEIMembership
|
||||
|
||||
Ce modèle hérite de ``Membership`` et contient les informations d'une adhésion au WEI.
|
||||
|
||||
* ``bus`` : ``ForeignKey(Bus)``, bus dans lequel se trouve l'utilisateur.
|
||||
* ``bus`` : ``ForeignKey(Bus)``, bus dans lequel se trouve l'utilisateur⋅rice.
|
||||
* ``team`` : ``ForeignKey(BusTeam)`` pouvant être nulle (pour les chefs de bus et électrons libres), équipe dans laquelle
|
||||
se trouve l'utilisateur.
|
||||
se trouve l'utilisateur⋅rice.
|
||||
* ``registration`` : ``OneToOneField(WEIRegistration)``, informations de la pré-inscription.
|
||||
|
||||
Champs hérités du modèle ``Membership`` :
|
||||
|
||||
* ``club`` : ``ForeignKey(Club)``, club lié à l'adhésion. Doit être un ``WEIClub``.
|
||||
* ``user`` : ``ForeignKey(User)``, utilisateur adhéré.
|
||||
* ``user`` : ``ForeignKey(User)``, utilisateur⋅rice qui a adhéré.
|
||||
* ``date_start`` : ``DateField``, date de début d'adhésion.
|
||||
* ``date_end`` : ``DateField``, date de fin d'adhésion.
|
||||
* ``fee`` : ``PositiveIntegerField``, montant de la cotisation payée.
|
||||
* ``roles`` : ``ManyToManyField(Role)``, liste des rôles endossés par l'adhérent. Les rôles doivent être des ``WEIRole``.
|
||||
* ``roles`` : ``ManyToManyField(Role)``, liste des rôles endossés par l'adhérent⋅e. Les rôles doivent être des ``WEIRole``.
|
||||
|
||||
Graphe des modèles
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
@ -123,32 +123,32 @@ Fonctionnement
|
||||
Création d'un WEI
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Seul un respo info peut créer un WEI. Pour cela, se rendre dans l'onglet WEI, puis "Liste des WEI" et enfin
|
||||
"Créer un WEI". Diverses informations sont demandées, comme le nom du WEI, l'adresse mail de contact, l'année du WEI
|
||||
Seul un⋅e respo info peut créer un WEI. Pour cela, se rendre dans l'onglet WEI, puis « Liste des WEI » et enfin
|
||||
« Créer un WEI ». Diverses informations sont demandées, comme le nom du WEI, l'adresse mail de contact, l'année du WEI
|
||||
(doit être unique), les dates de début et de fin, et les dates pendant lesquelles les utilisateurs peuvent s'inscrire.
|
||||
|
||||
Don des droits à un GC WEI
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Le GC WEI peut gérer tout ce qui a un rapport avec le WEI. Il ne peut cependant pas créer le WEI, ce privilège est
|
||||
réservé au respo info. Pour avoir ses droits, le GC WEI doit s'inscrire au WEI avec le rôle GC WEI, et donc payer
|
||||
en premier sa cotisation. C'est donc au respo info de créer l'adhésion du GC WEI. Voir ci-dessous pour l'inscription au WEI.
|
||||
Læ GC WEI peut gérer tout ce qui a un rapport avec le WEI. Iel ne peut cependant pas créer le WEI, ce privilège est
|
||||
réservé aux respos info. Pour avoir ses droits, læ GC WEI doit s'inscrire au WEI avec le rôle GC WEI, et donc payer
|
||||
en premièr⋅e sa cotisation. C'est donc aux respos info de créer l'adhésion du GC WEI. Voir ci-dessous pour l'inscription au WEI.
|
||||
|
||||
S'inscrire au WEI
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
N'importe quel utilisateur peut s'auto-inscrire au WEI, lorsque les dates d'adhésion le permettent. Ceux qui se sont
|
||||
déjà inscrits peuvent également inscrire un 1A. Seuls les GC WEI et les respo info peuvent inscrire un autre 2A+.
|
||||
N'importe quel⋅le utilisateur⋅rice peut s'auto-inscrire au WEI, lorsque les dates d'adhésion le permettent. Celleux qui se sont
|
||||
déjà inscrit⋅es peuvent également inscrire un⋅e 1A. Seul⋅es les GC WEI et les respos info peuvent inscrire un⋅e autre 2A+.
|
||||
|
||||
À tout moment, tant que le WEI n'est pas passé, l'inscription peut être modifiée, même après validation.
|
||||
|
||||
Inscription d'un 2A+
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
Inscription d'un⋅e 2A+
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Comme indiqué, les 2A+ sont assez autonomes dans leur inscription au WEI. Ils remplissent le questionnaire et sont
|
||||
ensuite pré-inscrits. Le questionnaire se compose de plusieurs champs (voir WEIRegistration) :
|
||||
Comme indiqué, les 2A+ sont assez autonomes dans leur inscription au WEI. Iels remplissent le questionnaire et sont
|
||||
ensuite pré-inscrit⋅es. Le questionnaire se compose de plusieurs champs (voir WEIRegistration) :
|
||||
|
||||
* Est-ce que l'utilisateur a déclaré avoir ouvert un compte à la Société générale ? (Option disponible uniquemement
|
||||
* Est-ce que l'utilisateur⋅rice a déclaré avoir ouvert un compte à la Société générale ? (Option disponible uniquemement
|
||||
si cela n'a pas été fait une année avant)
|
||||
* Date de naissance
|
||||
* Genre (Homme/Femme/Non-binaire)
|
||||
@ -159,17 +159,17 @@ ensuite pré-inscrits. Le questionnaire se compose de plusieurs champs (voir WEI
|
||||
* Équipes préférées (choix multiple éventuellement vide, vide pour les chefs de bus/staff)
|
||||
* Rôles souhaités
|
||||
|
||||
Les trois derniers champs n'ont aucun caractère définitif et sont simplement là en suggestion pour le GC WEI qui
|
||||
Les trois derniers champs n'ont aucun caractère définitif et sont simplement là en suggestion pour læ GC WEI qui
|
||||
validera l'inscription. C'est utile si on hésite entre plusieurs bus.
|
||||
|
||||
L'inscription est ensuite créée, le GC WEI devra ensuite la valider (voir plus bas).
|
||||
|
||||
Inscription d'un 1A
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
Inscription d'un⋅e 1A
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
N'importe quelle personne déjà inscrite au WEI peut inscrire un 1A. Le formulaire 1A est assez peu différent du formulaire 2A+ :
|
||||
N'importe quelle personne déjà inscrite au WEI peut inscrire un⋅e 1A. Le formulaire 1A est assez peu différent du formulaire 2A+ :
|
||||
|
||||
* Est-ce que l'utilisateur a déclaré avoir ouvert un compte à la Société générale ?
|
||||
* Est-ce que l'utilisateur⋅rice a déclaré avoir ouvert un compte à la Société générale ?
|
||||
* Date de naissance
|
||||
* Genre (Homme/Femme/Non-binaire)
|
||||
* Problèmes de santé
|
||||
@ -179,10 +179,10 @@ N'importe quelle personne déjà inscrite au WEI peut inscrire un 1A. Le formula
|
||||
* S'inscrire à la ML BDA
|
||||
* S'inscrire à la ML BDS
|
||||
|
||||
Le 1A ne peut donc pas choisir de son bus et de son équipe, et peut s'inscrire aux listes de diffusion.
|
||||
Læ 1A ne peut donc pas choisir de son bus et de son équipe, et peut s'inscrire aux listes de diffusion.
|
||||
Il y a néanmoins une différence majeure : une fois le formulaire rempli, un questionnaire se lance.
|
||||
Ce questionnaire peut varier au fil des années (voir section Questionnaire), et contient divers formulaires de collecte
|
||||
de données qui serviront à déterminer quel est le meilleur bus pour ce nouvel utilisateur.
|
||||
de données qui serviront à déterminer quel est le meilleur bus pour ce⋅tte nouvelleau utilisateur⋅rice.
|
||||
|
||||
Questionnaire 1A
|
||||
^^^^^^^^^^^^^^^^
|
||||
@ -200,7 +200,7 @@ Je veux changer d'algorithme de répartition, que faire ?
|
||||
|
||||
Cette section est plus technique et s'adresse surtout aux respos info en cours de mandat.
|
||||
|
||||
Première règle : on ne supprime rien (sauf si vraiment c'est du mauvais boulot). En prenant exemple sur des fichiers déjà existant tels que ``apps/wei/forms/surveys/wei2020.py``, créer un nouveau fichier ``apps/wei/forms/surveys/wei20XY.py``. Ce fichier doit inclure les éléments suivants :
|
||||
Première règle : on ne supprime rien (sauf si vraiment c'est du mauvais boulot). En prenant exemple sur des fichiers déjà existant tels que ``apps/wei/forms/surveys/wei2021.py``, créer un nouveau fichier ``apps/wei/forms/surveys/wei20XY.py``. Ce fichier doit inclure les éléments suivants :
|
||||
|
||||
WEISurvey
|
||||
"""""""""
|
||||
@ -223,7 +223,7 @@ Une classe héritant de ``wei.forms.surveys.base.WEISurvey``, comportant les él
|
||||
Naturellement, il est implicite qu'une fonction ayant pour premier argument ``cls`` doit être annotée par ``@classmethod``.
|
||||
Nativement, la classe ``WEISurvey`` comprend les informations suivantes :
|
||||
|
||||
* ``registration``, le modèle ``WEIRegistration`` de l'utilisateur qui remplit le questionnaire
|
||||
* ``registration``, le modèle ``WEIRegistration`` de l'utilisateur⋅rice qui remplit le questionnaire
|
||||
* ``information``, instance de ``WEISurveyInformation``, contient les données du questionnaire en cours de remplissage.
|
||||
* ``get_wei(cls)``, renvoie le WEI correspondant à l'année du sondage.
|
||||
* ``save(self)``, enregistre les informations du sondage dans l'objet ``registration`` associé, qui est ensuite
|
||||
@ -291,7 +291,7 @@ pour unique effet d'appeler la fonction ``run_algorithm`` décrite plus tôt. Un
|
||||
n'a pas été évoqué d'adhésion. L'adhésion est ensuite manuelle, l'algorithme ne fournit qu'une suggestion.
|
||||
|
||||
Cette structure, complexe mais raisonnable, permet de gérer plus ou moins proprement la répartition des 1A,
|
||||
en limitant très fortement le hard code. Ami nouveau développeur, merci de bien penser à la propreté du code :)
|
||||
en limitant très fortement le hard code. Ami⋅e nouvelleau développeur⋅se, merci de bien penser à la propreté du code :)
|
||||
En particulier, on évitera de mentionner dans le code le nom des bus, et profiter du champ ``information_json``
|
||||
présent dans le modèle ``Bus``.
|
||||
|
||||
@ -300,34 +300,34 @@ Valider les inscriptions
|
||||
|
||||
Cette partie est moins technique.
|
||||
|
||||
Une fois la pré-inscription faite, elle doit être validée par le BDE, afin de procéder au paiement. Le GC WEI a accès à
|
||||
Une fois la pré-inscription faite, elle doit être validée par le BDE, afin de procéder au paiement. Læ GC WEI a accès à
|
||||
la liste des inscriptions non validées, soit sur la page de détails du WEI, soit sur un tableau plus large avec filtre.
|
||||
Une inscription non validée peut soit être validée, soit supprimée (la suppression est irréversible).
|
||||
|
||||
Lorsque le GC WEI veut valider une inscription, il a accès au récapitulatif de l'inscription ainsi qu'aux informations
|
||||
personnelles de l'utilisateur. Il lui est proposé de les modifier si besoin (du moins les informations liées au WEI,
|
||||
pas les informations personnelles). Il a enfin accès aux résultats du sondage et la sortie de l'algorithme s'il s'agit
|
||||
d'un 1A, aux préférences d'un 2A+. Avant de valider, le GC WEI doit sélectionner un bus, éventuellement une équipe
|
||||
et un rôle. Si c'est un 1A et que l'algorithme a tourné, ou si c'est un 2A+ qui n'a fait qu'un seul choix de bus,
|
||||
Lorsque læ GC WEI veut valider une inscription, iel a accès au récapitulatif de l'inscription ainsi qu'aux informations
|
||||
personnelles de l'utilisateur⋅rice. Il lui est proposé de les modifier si besoin (du moins les informations liées au WEI,
|
||||
pas les informations personnelles). Iel a enfin accès aux résultats du sondage et la sortie de l'algorithme s'il s'agit
|
||||
d'un⋅e 1A, aux préférences d'un⋅e 2A+. Avant de valider, læ GC WEI doit sélectionner un bus, éventuellement une équipe
|
||||
et un rôle. Si c'est un⋅e 1A et que l'algorithme a tourné, ou si c'est un⋅e 2A+ qui n'a fait qu'un seul choix de bus,
|
||||
d'équipe, de rôles, les champs sont automatiquement pré-remplis.
|
||||
|
||||
Quelques restrictions cependant :
|
||||
|
||||
* Si c'est un 2A+, le chèque de caution doit être déclaré déposé
|
||||
* Si c'est un⋅e 2A+, le chèque de caution doit être déclaré déposé
|
||||
* Si l'inscription se fait via la Société générale, un message expliquant la situation apparaît : la transaction de
|
||||
paiement sera créée mais invalidée, les trésoriers devront confirmer plus tard sur leur interface que le compte
|
||||
paiement sera créée mais invalidée, les trésorièr⋅es devront confirmer plus tard sur leur interface que le compte
|
||||
à la Société générale a bien été créé avant de valider la transaction (voir `Trésorerie <treasury>`_ section
|
||||
Crédit de la Société générale).
|
||||
* Dans le cas contraire, l'utilisateur doit avoir le solde nécessaire sur sa note avant de pouvoir adhérer.
|
||||
* L'utilisateur doit enfin être membre du club Kfet. Un lien est présent pour le faire adhérer ou réadhérer selon le cas.
|
||||
* Dans le cas contraire, l'utilisateur⋅rice doit avoir le solde nécessaire sur sa note avant de pouvoir adhérer.
|
||||
* L'utilisateur⋅rice doit enfin être membre du club Kfet. Un lien est présent pour le faire adhérer ou réadhérer selon le cas.
|
||||
|
||||
Si tout est bon, le GC WEI peut valider. L'utilisateur a bien payé son WEI, et son interface est un peu plus grande.
|
||||
Il peut toujours changer ses paramètres au besoin. Un 1A ne voit rien de plus avant la fin du WEI.
|
||||
Si tout est bon, læ GC WEI peut valider. L'utilisateur⋅rice a bien payé son WEI, et son interface est un peu plus grande.
|
||||
Iel peut toujours changer ses paramètres au besoin. Un⋅e 1A ne voit rien de plus avant la fin du WEI.
|
||||
|
||||
Un adhérent WEI non 1A a accès à la liste des bus, des équipes et de leur descriptions. Les chefs de bus peuvent gérer
|
||||
les bus et leurs équipes. Les chefs d'équipe peuvent gérer leurs équipes. Cela inclut avoir accès à la liste des membres
|
||||
Un⋅e adhérent⋅e WEI non 1A a accès à la liste des bus, des équipes et de leur descriptions. Les chef⋅fes de bus peuvent gérer
|
||||
les bus et leurs équipes. Les chef⋅fes d'équipe peuvent gérer leurs équipes. Cela inclut avoir accès à la liste des membres
|
||||
de ce bus / de cette équipe.
|
||||
|
||||
Un export au format PDF de la liste des membres *visibles* est disponible pour chacun.
|
||||
Un export au format PDF de la liste des membres *visibles* est disponible pour chacun⋅e.
|
||||
|
||||
Bon WEI à tous !
|
||||
Bon WEI à toustes !
|
||||
|
||||
Reference in New Issue
Block a user