- 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.
- Ajoute l'affichage de l'historique dans K-Psul
- Ajoute la synchronisation du montant des caisses et de l'historique
entre les interfaces K-Psul ouvertes par le package 'channels' et
l'utilisation de websockets
- Corrige l'obligation de l'article sur K-Psul (pas d'article pour les
charges et retraits)
- Corrige type renvoyé par perms_to_perform_operations
- Rangement de js.cookie.js dans static/kfet/js/
- Ajout de dépendances
Ce patch propose aux adhérents du COF de télécharger un calendrier
dynamique (`.ics`).
Il est configurable :
- On peut s'abonner ou non aux événements du COF.
- On peut choisir les spectacles auxquels on veut s'abonner.
Rend GestioCOF compatible avec python 3. En particulier, il s'agit de :
- Utiliser la version "fonction" de `print` dans `sync_clipper` et
`tirage_bda`, avec le `from __future__ import print_function` pour
garder la compatibilité avec python 2
- Utiliser de l'unicode par défaut, même en python 2, avec
`from __future__ import unicode_literals` et le décorateur de
compatibilité `python_2_unicode_compatible` de Django pour les
modèles, comme décrit à
https://docs.djangoproject.com/en/1.9/topics/python3/#str-and-unicode-methods
- Utiliser `six.text_type` à la place de `unicode`
Fixes#2.
Sépare les urls entre les différentes apps
Ajoute des commentaires dans `cof/urls` qui donnent des indications sur
les groupes d'urls.
Enjolive le code
See merge request !24
La vue `bda.mails.send_rappel/<id>` envoie des mails aux participants
du spectacle référencé par `<id>`. Elle doit être déclenchée
manuellement.
Le template du mail est dans `bda/templates/mail-rappel.txt`. Tant que
GestioCOF ne sait pas si les spectacles sont sur listing ou non, il
reste une partie pas très belle.
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.
