- Reprise en utilisant `history.js`
- Fix csrf_token sur ajax POST K-Psul
- Fix annulation K-Psul
- Ajouts de select_related pour économiser de la requête BDD
- Reprise du JS d'historique dans `kfet/static/kfet/js/history.js`
- Adapatation de K-Psul pour l'utiliser
- Création page historique avec filtres (dates, caisses, comptes)
- Ajout de paramètres à cette vue
- `opegroups` contient maintenant une liste de groupes d'opérations et
non plus un dictionnaire contenant `opegroup.pk` => `opegroup`
- Un commentaire est demandé. Une permission est nécessaire (afin
d'enregistrer la personne ayant enregistré la commande)
- Fix annulation K-Psul. Appuyer sur Suppr appelait tout le temps
`cancelOperations` même si aucune opération à supprimer n'était
sélectionné.
- Reprise de l'affichage
- Affichage en direct des totaux et erreurs
- Possibilité de ne pas compter la caisse ajoutée (et identifiée par
`not_count` dans le modèle Statement si tel est le cas)
Nouveau relevé:
Il faut donner le détail du nombre de chaque
pièces/billets pris et laissé en caisse pour calculer les valeurs
`balance_new` et `amount_taken` d'un relevé (`CheckoutStatement`).
L'erreur est directement calculée par rapport à la balance actuelle de
la caisse et ces 2 valeurs. Une erreur positive correspond à un surplus
d'argent et inversement.
Modification d'un relevé:
Il est possible de modifier les infos d'un ancien relevé. L'erreur est
ensuite recalculée à partir de ces infos.
Important: Dans le cas où `balance_new` est modifiée et qu'il s'agit du
relevé le plus récent sur cette caisse. Alors la balance de la caisse
est mise à jour en prenant en compte cette correction (et en conservant
les modifications s'il y a eu des mouvements sur la caisse)
- Les infos d'annulations apparaissent sur les historiques (K-Psul et
standard)
- Les infos de validation apparaissent sur l'historique standard si la
personne est de l'équipe
- Si la ligne contenant les données d'une opération est trop longue,
celle-ci est scrollable (exemple : opé annulée sur K-Psul)
- Le fond change de couleur lorsqu'il y a une majoration. La majoration
est indiquée dans le cadre sur la caisse (et clignote !)
- Meilleure prise en charge des paramètres sur K-Psul
En appuyant sur F9, il est possible de définir une majoration destinée à
un compte en donnant le trigramme du compte destinataire et la valeur en
euro de la majoration par article
- Lors de la création ou modification d'un article, il est possible de
sélectionner une catégorie existante ou d'en créer une nouvelle.
- Autorisations pour la création/modif d'article prises en compte
correctement. Si l'utilisateur identifié n'a pas la permission
add(ou change)_accoount, input password apparait et l'utilisateur est
identifié temporairement pour la validation de l'ajout/modif.
- 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
- Un utilisateur ayant la perm `kfet.is_team` peut se déconnecter et
connecter à la place un utilisateur `kfet_genericteam` ne disposant
que de la permission `kfet.is_team`
- Backend et vue associée à cette connexion créés
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.
