Update Member, add models

ynerant 2020-04-02 02:57:40 +02:00
parent eb5fc53d9b
commit 50cca60266
1 changed files with 68 additions and 4 deletions

@ -6,8 +6,72 @@ Le model d'utilisateur `django.contrib.auth.model.User` est complété par un `P
Tous les utilisateurs peuvent être membre de `Club`. Cela se traduit par une adhésion `Membership`, dont les caractéristiques sont propres à chaque club.
En pratiques, la NoteKfet possède au minimum deux Club: **Bde** et **Kfet**. Et tous les personnes à jour de cotisation sont membre à minima de Bde.
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.
## Models
![models_member.svg](uploads/69e91535e5a80a21b89bec2e72c994b0/models_member.svg)
## Modèles
### Utilisateur
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.
* `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).
* `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.
### 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 :
* `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, ...)
### 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.
* `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_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.
* `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, ...)
### 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é.
* `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.
### Rôles
Comme indiqué le modèle des adhésions, les adhésions octroient des rôles aux adhérents, 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`).
### Transactions d'adhésion
Si le modèle `MembershipTransaction` appartient à l'application `note`, il est bon d'en parler ici. 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).
### Graphe
![member.svg](uploads/74b2f3ec520eb077a4a54162db5ee043/member.svg)
## Adhésions