Development #49899
/api/users/: autre tri par défaut
0%
Description
Pour le moment le tri par défaut est défini ainsi :
class UsersAPI(api_mixins.GetOrCreateMixinView, HookMixin, ExceptionHandlerMixin, ModelViewSet):
(...)
ordering = ['modified', 'id']
Bien sûr on peut avoir discuter pas mal pour trouver ce que serait le "meilleur" tri mais comme il n'y aura pas de réponse, je proposerais plutôt que l'API ne définisse pas de tri, que ça soit l'ordering défini au niveau du modèle qui entre en compte.
(la personne qui aurait besoin du tri par date de modification peut toujours faire ?ordering=modified).
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a plus de 3 ans
- Lié à Development #49957: custom_user : dans free_text_search spécialiser en fonction du motif et utiliser sinon find_duplicates(fullname=) si on ne trouve pas mieux ajouté
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Je vois que tu lies ça au ticket #49957 mais aucun tri n'ira pour la recherche libre, le tri doit être déterminé par la recherche qui est effectivement faite, je vais l'écrire dans l'autre ticket.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Assigné à mis à Benjamin Dauvergne
Ok pour virer l'ordering par défaut, après réflexion ça n'impacte pas l'autre ticket.
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Fichier 0001-api_views-remove-default-ordering-on-UsersAPI-49899.patch 0001-api_views-remove-default-ordering-on-UsersAPI-49899.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Statut changé de Solution proposée à Solution validée
OK, donc pour le contexte
Frédéric Péters a écrit :
je proposerais plutôt que l'API ne définisse pas de tri, que ça soit l'ordering défini au niveau du modèle qui entre en compte.
Pas possible de ne pas définir de tri avec la pagination par curseur.
(la personne qui aurait besoin du tri par date de modification peut toujours faire ?ordering=modified).
Permettre de spécifier un ordre reste apparemment possible en implémentant un truc à base OrderingFilter, il faut réfléchir à ce qui serait permis, à faire dans un autre ticket si besoin.
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Statut changé de Solution validée à Information nécessaire
Quoique wait ce changement est incompatible avec #50536 ? (en vrai ça aurait été mieux d'avoir un ticket avec tous les patchs, là c'est dur à voir quoi s'applique dans quel ordre et impossible de tester le truc final à moins de me farcir les rebases)
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
Valentin Deniaud a écrit :
Quoique wait ce changement est incompatible avec #50536 ? (en vrai ça aurait été mieux d'avoir un ticket avec tous les patchs, là c'est dur à voir quoi s'applique dans quel ordre et impossible de tester le truc final à moins de me farcir les rebases)
Rebasé ils sont compatibles :) dans le sens où celui-ci disparaît mais j'ai voulu le laisser pour qu'on voit le parcours, qu'on ne passe pas directement du tri sur ['modified', 'id'] au tri via ['dist', 'last_name', 'first_name'] et User._media.ordering sans point médian.
Mis à jour par Valentin Deniaud il y a environ 3 ans
- Statut changé de Information nécessaire à Solution validée
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 4c029ae062ebc41cc13c62f3e5296fda5a8f142e
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date: Tue Jan 26 09:08:33 2021 +0100
api_views: order users as in the model (#49899)
Mis à jour par Benjamin Dauvergne il y a environ 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api_views: order users as in the model (#49899)