Produits Entr'ouvert » Chrono

Taper le test dans sa propre fonction.

Il y a un test avec start_dt et end_dt, et un test avec end_dt, mais pas de test avec juste start_dt.

Se permettre d'appeler ça _datetime plutôt que _dt.

Le ticket parlait de filter sur une date donnée, le patch permet de filtrer sur début/fin de dates/heures. Je peux comprendre le cas d'usage du date/fin sur des dates, mais pourquoi faire date/heure ?

Pas fan de l'imbrication de fonction surtout quand c'est totalement inutile vu qu'il y a un seul appel.

Pourquoi une méthode de classe ?

Pourquoi passer par un opérateur particulier pour le cas où les deux bornes sont présentes ?

Tout ceci ne tiendrait-il pas dans un patch de cinq lignes, plus clair ?

if request.GET.get('date_start'):
    kwargs['start_datetime__gte'] = parse_date(request.GET['date_start'])
if request.GET.get('date_end'):
    kwargs['start_datetime__lte'] = parse_date(request.GET['date_end])

Aussi, je n'incluerais perso pas la borne supérieure (ce qui fait un plus logique start=d, end=d+7 pour couvrir une semaine, ou 1/mm/yy → 1/mm+1/yy pour un mois, je trouve).

Une question par contre, est ce que l'on autorise la récupération des événements au delà du max_booking_delay ?

Non, on présente les dates de réservation possibles uniquement.

Ainsi, la fonction devrait être réécrite pour enchainer les .filter() sur le queryset, plutôt que remplir un kwargs.

from django.utils.dateparse import parse_date

dateparse vient avant timezone.

Tu peux conserver le « entries = Event.objects.filter(agenda=agenda).filter(**kwargs) » tel quel à la suite des ajouts sur kwargs, au lieu de le couper en deux

Alors en fait, quand je parlais d'enchainer les .filter() plutôt que remplir un kwargs, je ne pensais pas à remplir un kwargs puis un params (puis demain que sais-je).

Genre :

        entries = Event.objects.filter(agenda=agenda)

        # we never want to allow booking for past events.
        entries = entries.filter(start_datetime__gte=localtime(now()))

        if agenda.minimal_booking_delay:
            entries = entries.filter(
                    start_datetime__gte=localtime(now() + datetime.timedelta(days=agenda.minimal_booking_delay)).date())

        if agenda.maximal_booking_delay:
            entries = entries.filter(
                    start_datetime__lt=localtime(now() + datetime.timedelta(days=agenda.maximal_booking_delay)).date())

        if 'date_start' in request.GET:
            entries = entries.filter(start_datetime__gte=parse_date(request.GET['date_start']))

        if 'date_end' in request.GET:
            entries = entries.filter(start_datetime__lt=parse_date(request.GET['date_end']))

Il faudrait ajouter des tests assurant le respect de minimal_booking_delay et/ou maximal_booking_delay, pour éviter les régressions lors d'un refactoring de Datetimes qui déciderait de tout mettre dans un kwargs.

Ack