Prescripteur: ajout de tri dans la liste des candidats [GEN-1844]#5602
Conversation
|
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
e762394 to
ce7bd08
Compare
ce7bd08 to
81f7c29
Compare
81f7c29 to
e36ec24
Compare
francoisfreitag
left a comment
There was a problem hiding this comment.
J’imagine qu’il n’a pas été question de multisort ?
| self.request.GET or {}, | ||
| request_user=request.user, | ||
| ) | ||
| self.form.full_clean() # We do not use is_valid to validate each field independently |
There was a problem hiding this comment.
Je ne suis vraiment pas convaincu de la nécessité de se casser la tête à éviter le standard form.is_valid() (qui est d’ailleurs recommandé au lieu d’appeler .errors ou full_clean).
On risque de se retrouver à valider le formulaire deux fois, alors que l’appel à is_valid() permet de valider et cacher le résultat, et de centraliser les traitements.
La version actuelle « triche » en appelant full_clean() sans vérifier s’il y a des erreurs, et en traitant uniquement les arguments valides.
D’ailleurs, en faisant ainsi, elle introduit un bug car si le job_seeker est invalide, on va tout de même faire self.form.cleaned_data["job_seeker"].
http://localhost:8000/job-seekers/list?job_seeker=0&order=
(un petit test serait utile 😉)
J’entends bien que pour un formulaire de filtres, ignorer les erreurs est envisageable, mais il me semblerait plus clair pour les devs et les utilisateurs de procéder de la manière suivante :
- valider les entrées
- afficher les erreurs éventuelles (et une liste de résultats non triée / filtrée)
- autrement, appliquer les filtres donnés
There was a problem hiding this comment.
Yup, je pense repasser sur is_valid mais aucune idée pour le moment où je vais remonter l'erreur éventuelle de tri 😬 (à part un gros messages.warning) mais bon, ça ne devrait pas se produire
Non, pas pour le moment 🤞 |
1aff559 to
e594dfc
Compare
e16c5b5 to
4c0e851
Compare
|
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
4c0e851 to
57e2293
Compare
| <th scope="col">Statut du PASS IAE</th> | ||
| <th scope="col">Nombre de candidatures</th> | ||
| <th scope="col">Dernière mise à jour de candidature</th> | ||
| {% include 'common/tables/th_with_sort.html' with order=order ascending_value=order.JOB_APPLICATIONS_NB_ASC name="Nombre de candidatures" only %} |
There was a problem hiding this comment.
C'est un choix motivé, le tri croissant de nombre de candidatures ?
Instinctivement je pensais que ça allait trier par ordre décroissant.
Mais c'est vrai que ça permet de voir les candidats qui n'ont aucune candidature en premier, et ça peut être utile pour retrouver un candidat qu'on vient de créér par exemple.
There was a problem hiding this comment.
Comme discuté, pas vraiment motivé: cela permet de simplifier l'include en considérant le tri par défaut comme étant toujours le tri croissant.
| User.objects.filter(kind=UserKind.JOB_SEEKER, pk__in=job_seekers_ids) | ||
| .prefetch_related("approvals") | ||
| .annotate( | ||
| full_name=Concat(Lower("first_name"), Value(" "), Lower("last_name")), |
There was a problem hiding this comment.
Peut-être un tri sur le nom de famille plutôt, selon ce que dit le métier ?
|
J'ai vu plein de trucs élégants 🤩 |
f11ada4 to
accfdfc
Compare
dcb83a8 to
1f2df20
Compare
since they will be changed in next commit
a3ef626 to
f141a25
Compare
f141a25 to
51e7540
Compare
🤔 Pourquoi ?
🍰 Comment ?
🚨 À vérifier
🏝️ Comment tester ?
💻 Captures d'écran