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.
Ce patch enlève la vérification faite par django-debug-toolbar pour ne
s'afficher que si l'IP source est dans l'option de configuration
INTERNAL_IPS. Ceci permet son fonctionnement avec Vagrant.
Fixes#8.
Ce patch enlève la vérification faite par django-debug-toolbar pour ne
s'afficher que si l'IP source est dans l'option de configuration
INTERNAL_IPS. Ceci permet son fonctionnement avec Vagrant.
Fixes#8.
Ce commit ajoute une configuration Vagrant permettant d'avoir un
environnement de développement facile à installer et réutilisable (cf
README.md).
En particulier :
- Vagrantfile est un fichier qui décrit une machine virtuelle Vagrant.
La configuration est assez proche des défauts, et n'introduit que
deux différences : les ports 8000 et 80 sont bindés sur les ports
8000 et 8080 (respectivement) sur la machine hôte, et le script
`provisioning/bootstrap.sh` est utilisé pour configurer une nouvelle
machine virtuelle.
- provisioning/bootstrap.sh est un script shell qui s'occupe
d'installer les paquets nécessaire et de configurer la machine
virtuelle pour que GestioCOF fonctionne.
- cof/settings_dev.py est un fichier de configuration minimal
permettant de faire fonctionner GestioCOF, configuré pour être
utilisé avec Vagrant mais facilement adaptable.
