plages libres, permettre de créer un pointage sans réservation (#80369) #149
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/80369-plages-libres-permettre-de-creer"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
3fa5eda2a1
to40b5868c6f
40b5868c6f
to6a730c0555
6a730c0555
to173799869e
173799869e
toa9d7ccbec0
a9d7ccbec0
to6b1bba75aa
6b1bba75aa
to5d21b7ac3f
5d21b7ac3f
tofe7b0f32b0
fe7b0f32b0
toe2d4653ca3
WIP: plages libres, permettre de créer un pointage sans réservation (#80369)to plages libres, permettre de créer un pointage sans réservation (#80369)Gros morceau, pas d'opposition à envisager une autre approche si il y a mieux (rappel qu'il y a aussi #80371 dans l'équation).
plages libres, permettre de créer un pointage sans réservation (#80369)to plages libres, permettre de créer un pointage sans réservation (#80369)@ -2788,1 +2801,3 @@
self.secondary_booking_set.update(user_was_present=None)
if self.user_check:
self.user_check.delete()
self.user_check = None
pas de reset des user_check des secondary_bookings ?
L'objet BookingCheck est partagé entre résa primaire et secondaire, donc le
self.user_check.delete()
au dessus vaut pour les deux.Je pense que le
self.user_check = None
est utile car on s'attend à ce que cette méthode enlève l'attribut user_check. En revanche leself.save()
en dessous est inutile.@ -393,0 +396,4 @@
app = 'agendas'
migrate_from = [(app, '0160_add_booking_check_model')]
migrate_to = [(app, '0161_migrate_booking_check_data')]
Dans le 3e commit il y a un changement là-dessus:
Possible de poser ça directement dans le 2e commit ?
Bien vu je vais le faire
J'hésite pour le 0004, dans le pointage classique (hors plage libre), quand on a une souscription sans réservation, on peut la pointer, et alors cela crée un objet Booking classique, comme si ça avait été réservé via une démarche de réservation.
Là tu crées un objet BookingCheck avec des FK sur Suscription et Event.
On pourrait harmoniser, et faire pareil pour le pointage classique, mais:
L'api qui moissonne les agendas pour la facturation, s'appuie sur Booking pour trouver le pointage, sans booking il se peut qu'on ne puisse pas facturer. (et du coup là pour le cas plages libres, il doit y avoir un trou pour la facturation)
Aussi, il faudrait vérifier comme ça remonte dans le widget de réservation et dans la cellule calendrier, si on voit bien une présence ou une absence.
Je préfèrerais, pour le cas plages libres, faire comme le cas classique, créer un Booking et un BookingCheck (avec des heures de pointage mais pas d'heures de réservation).
Note: avec la journalisation des pointages, on pourra retracer l'origine d'un objet Booking créé à la suite du pointage d'une Subscription.
Autre note: les calculs des dates de début et fin de période de pointage (arrondis par rapport aux unités de facturation et tolérance), fonctionnent si on a des heures de pointage mais pas d'heures de réservation.
Aïe, j'avais raté que ça existait déjà, et ça n'a pas été dit en eoday famille :/
Ça me va mais il n'y a plus d'intérêt immédiat à avoir ce nouveau modèle BookingCheck, non ?
Pour anticiper le pointage avec deux motifs différents ? une présence sur une partie de la journée, une absence sur le reste ?
Ou tu préfères sortir ça de la PR et l'introduire plus tard quand tu traiteras le sujet ?
e2d4653ca3
toe6ac54edd9
e6ac54edd9
to5840c15139
plages libres, permettre de créer un pointage sans réservation (#80369)to WIP: plages libres, permettre de créer un pointage sans réservation (#80369)WIP: plages libres, permettre de créer un pointage sans réservation (#80369)to WIP: plages libres, permettre de créer un pointage sans réservation (#80369)Yep j'ai fait ça, revoici un seul commit qui suit ce qui est fait pour le pointage classique.
Point d'attention, ça crée des bookings « fantômes », si on pointe/dépointe une inscription : c'est géré par lingo ou il faut les nettoyer au moment du dépointage ?
WIP: plages libres, permettre de créer un pointage sans réservation (#80369)to plages libres, permettre de créer un pointage sans réservation (#80369)J'ai un ticket à créer pour permettre de revenir à l'état initial sur la page de pointage, c'est à dire supprimer un Booking pour revenir à une inscription sans réservation, je prendrai en compte le cas plages libres à ce moment-là
@ -629,0 +631,4 @@
self.fields['user_check_start_time'].widget = widgets.TimeWidget(step=60)
self.fields['user_check_end_time'].widget = widgets.TimeWidget(step=60)
self.fields['user_was_present'].widget.choices = ((None, _('Not checked')), (True, _('Present')))
self.fields.pop('absence_check_type', None)
Il faudrait pouvoir préciser un motif, pour pointer l'enfant en "présence non prévue" et facturer en conséquence
(j'ai un ticket à créer plus tard, pour automatiser le set d'un motif paramétré pour être le motif appliqué sur un pointage sans réservation)
Mais ici ce qu'on retire c'est absence_check_type, il reste bien presence_check_type pour le motif (ça part du principe qu'on ne pointera jamais un enfant pas réservé comme absent, peut-être y a-t-il un cas d'usage tordu que j'ignore)
oups pardon, mal lu :)
yes en effet un motif d'absence pour une inscription sans réservation n'a pas de sens
@ -407,0 +464,4 @@
resp.form['user_was_present'] = ''
resp = resp.form.submit().follow()
assert len(resp.pyquery('.registrant--bar')) == 0
est-ce que tu peux juste ajouter quelques tests, vérifier qu'un objet Booking a été créé et contient bien les bonnes données dans user_external_id etc ?
Ajouté !
5840c15139
to118c067050