- On installe le package depuis le dépôt COF-Geek
- On supprime tous les fichiers texte des mails
- On charge dans la bdd les mails nécessaires au fonctionnement de
GestioCOF
- On supprime le modèle CustomMail obsolète de gestioncof
Améliore les mails automatiques du BdA
Les mails du BdA sont maintenant tous chargés depuis des templates gérés par le système de templates de Django, et plus par de l'interpolation de chaîne de caractères. Ceci permet en particulier d'utiliser (et de configurer) la localisation de Django afin d'afficher les dates de façon uniforme (et sans "hack" à la `date_no_seconds`) dans un format comportant un "à" entre le jour et l'heure.
See merge request !113
Configure la localisation (i10n) de Django afin d’afficher un format
plus user-friendly par défaut pour les dates (par exemple, afficher
"21 septembre 2016 à 15:00" plutôt que "21 septembre 2016
15:00"). Ceci permet d’éliminer les utilisations de `date_no_seconds`
pour simplement les remplacer par l’affichage de la date, le format
par défaut étant maintenant satisfaisant.
Attention : le bon fonctionnement de ceci nécessite de changer les
settings afin d’utiliser le module `cof.locale` comme module de
localisation (définir `FORMAT_MODULE_PATH = "cof.locale"`). Le module
`cof.locale` définit le format d’affichage des dates+heures
(`DATETIME_FORMAT`) afin d’incorporer le "à" qui n'est pas présent
dans la localisation française de Django.
- Suppression de la variable `ALLOWED_HOSTS` de `cof/settings.dev` de
sorte quand django utilise le default (qui est adapté à notre usage)
- Correction d'indentation
- Suppression d'un "-e" dans le fichier `requirements.txt`
Les valeurs de champs FROM, REPLY-TO et BCC des mails envoyés par
GestioCOF sont enregistrées dans un dictionnaire `settings.MAIL_DATA`
plutôt que d'être toutes enregistrées comme variables indépendantes
- Suppression du dossier `apache` devenu inutile.
- On utilise `cof.settings` dans le fichier `asgi.py` par défaut
- Correction dans les urls du fichier de settings en lien avec les
nouvelles urls en `/gestion/...`
On fait tourner GestioCOF avec daphne derrière un reverse-proxy Apache
sur la VM Vagrant tout comme sur le serveur de production. On peut tester
en local GestioCOF en “conditions réelles”.
Le serveur lancé avec `python manage.py runserver 0.0.0.0:8000` est toujours
accessible à la même url `localhost:8000`.
Le (nouveau) serveur apache est accessible à `localhost:8080`.
Pour appliquer les changements dans le code au serveur type prod, il faut
relancer le worker : `sudo supervisorctl restart worker`. Alors que le serveur
de dev se relance tout seul.
NB important : ce patch supprime le mot de passe sur le serveur redis en dev,
pour faire marcher ce nouveau setup avec un version précédente de la VM, il faut
lancer `sudo redis-cli config set requirepass ""`
- Le backend d'auth K-Fêt est étendu pour aussi identifier une personne
dans le cas dans d'un formulaire en récupérant le password contenu
dans l'input de nom `KFETPASSWORD`
- Le middleware d'auth K-Fêt enregistre l'utilisateur connecté de
manière normale dans `request.real_user`
- Ajout d'un processeurs de contextes `kfet.context_processors.auth` qui
qui remplace `user` et `perms` par l'utilisateur connecté de manière
normale (`request.real_user`) et non celui connecté temporairement
- Modification de la vue de modif d'un compte pour s'adapter à l'auth
- Modification du template de modification d'un compte pour utiliser ce
moyen d'authentification
- Séparation du JS conservant le côté gauche d'une page à l'écran
- Séparation de l'encart gauche contenant les infos d'un comtpe dans un
autre template (`left_account`) pour l'utiliser dans `account_read` et `account_update`
- `base_nav` utilise user (qui est donc le vrai utilisateur connecté) au
lieu de `request.user` qui peut aussi bien être le vrai utilisateur
qu'un utilisateur temporaire
Si une (des) permission(s) sont nécessaires pour enregistrer/annuler des
opérations, une demande d'authentification apparaît où l'utilisateur
doit mettre le mot de passe d'un compte ayant la (les) permission(s)
requise(s).
Ce mot de passe est envoyé dans la requête AJAX via le header
`KFetPassword`.
Le middleware `KFetAuthenticationPassword` est appelée à chaque requête.
Il appelle lui même le backend `KFetBackend` qui est chargé de
retrouver le user dont le compte K-Fêt correspond au mot de passe défini
dans le header `KFETPASSWORD`.
Si le header n'est pas présent ou
qu'aucun utilisateur ne correspond à ce mot de passe, le middleware ne
fait... rien !
Dans le cas où un user est trouvé, il est "chargé" dans
`request.user` permettant ainsi de connecter l'utilisateur pour ce cycle
requête/réponse sans déconnecter l'utilisateur connecté de manière
normale.
Précédemment, GestioCOF utilisait django-cas, qui n'est plus maintenu.
Ceci le remplace par django-cas-ng, un fork plus récent et maintenu.
En particulier, django-cas-ng est compatible avec Python 3,
contrairement à django-cas.
