Admin: Ajout du référent FT sur la page de profil de demandeur d'emploi - #5447
Conversation
Les deux se tiennent, je préfère également modifié quand il s’agit de changements mineurs 🤷 |
|
|
||
| def __str__(self): | ||
| return f"{self.name} ({self.jobseeker_profile})" | ||
| return f"{self.name} ({self.email})" |
There was a problem hiding this comment.
En pratique le str(self.jobseeker_profile) va imprimer le __str__ du modèle User comme 'Eric Fromm (Jacques HENRY — test+de@inclusion.beta.gouv.fr)'
Au moment là j'avais en tête que ça permet de "inheriter" les changements à la serialization d'un utilisateur... mais en relecture ça me fait remarquer que ce n'était pas très pythonique ("explicit is better than implicit")
Du coup content avec le changement, la suggestion est juste s'il y a un intérêt à garder le nom
| return f"{self.name} ({self.email})" | |
| return f"{self.name} ({self.jobseeker_profile.user.get_full_name()} - {self.email})" |
There was a problem hiding this comment.
Justement, je trouve qu'il n'y a pas d'intérêt à conserver le nom de l'utilisateur, et en plus ça fait 2 requêtes SQL en plus :)
4 participants
🤔 Pourquoi ?
cf https://www.notion.so/gip-inclusion/Donner-acc-s-advisor_information-sur-l-admin-1815f321b60480308e41e8155e79c4ee?pvs=4
J'ajoute un élément à la page d'admin, mais j'aurais tendance à mettre le label modifié parce que je modifie une page existante, vous êtes d'accord avec la logique ?
🍰 Comment ?
J'en ai profité pour changer le
__str__du modèleFranceTravailContactcar l'affichage duJobSeekerProfilene me semblait pas utile vu qu'on le récupère normalement depuis cet objet.🚨 À vérifier
🏝️ Comment tester ?
💻 Captures d'écran