Development #75331
Mis à jour par Lauréline Guérin il y a environ un an
constaté sur un agenda de type events dans #75320
Un appel de type /api/agenda/<slug>/datetimes/ renvoie les créneaux dans un ordre aléatoire (pk ? apparition dans la DB ?)
L'ordering pas défaut défini sur la classe Event n'est pas appliqué:
<pre>
class Meta:
ordering = ['agenda', 'start_datetime', 'duration', 'label']
</pre>
Le code:
<pre>
entries = Event.objects.none()
[...]
entries |= agenda.get_open_events( # <- ici on a bien un tri
min_start=payload.get('date_start'),
max_start=payload.get('date_end'),
bypass_delays=payload.get('bypass_delays'),
)
entries = Event.annotate_queryset_for_user(entries, user_external_id) # <- ici plus de tri
</pre>
Intuitivement, j'ai envie d'accuser le passage à django 3.2, et un changement de comportement lorsqu'on a un annotate sur une concaténation de querysets. 3.2
Un appel de type /api/agenda/<slug>/datetimes/ renvoie les créneaux dans un ordre aléatoire (pk ? apparition dans la DB ?)
L'ordering pas défaut défini sur la classe Event n'est pas appliqué:
<pre>
class Meta:
ordering = ['agenda', 'start_datetime', 'duration', 'label']
</pre>
Le code:
<pre>
entries = Event.objects.none()
[...]
entries |= agenda.get_open_events( # <- ici on a bien un tri
min_start=payload.get('date_start'),
max_start=payload.get('date_end'),
bypass_delays=payload.get('bypass_delays'),
)
entries = Event.annotate_queryset_for_user(entries, user_external_id) # <- ici plus de tri
</pre>
Intuitivement, j'ai envie d'accuser le passage à django 3.2, et un changement de comportement lorsqu'on a un annotate sur une concaténation de querysets. 3.2