Haie / L'historique des dossiers inclut la mise en attente + champs de l'état du dossier (Attente PC 3/3) + analytics #918
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
numahell
left a comment
numahell
left a comment
There was a problem hiding this comment.
J'ai des commentaires pour plus de commentaires :)
à part ça c'est bon pour moi.
numahell
left a comment
numahell
left a comment
There was a problem hiding this comment.
Merci pour l'ajout des commentaires et des docstrings :)
thibault
left a comment
thibault
left a comment
There was a problem hiding this comment.
J'ai posé quelques commentaires, j'ai l'intuition que la solution choisie risque de créer des problèmes quand on prendra en compte plus d'éléments dans l'historique de modification du dossier. Qu'en penses-tu ?
envergo/petitions/views.py
Outdated
|
|
||
| def get_context_data(self, **kwargs): | ||
|
|
||
| def extract_entries(log): |
There was a problem hiding this comment.
Je suis un peu mitigé quant à ce choix technique. À ce stade, on a une belle correspondance ou chaque entrée StatusLog correspond à un changement d'état. C'est clair, explicite et propre.
Est-ce que ça n'aurait pas été plus simple de garder cette correspondance en créant tout simplement une nouvelle entrée au moment de la reprise de l'instruction ? Ça aurait évité de bidouiller pour créer ce tableau et épargné la nécessité de créer une nouvelle structure de données.
Par ailleurs, la présente solution créé un petit bug de cohérence sur le nombre de changements indiqué.
There was a problem hiding this comment.
Pour ce besoin précis d'affichage des changements, on prefererait effectivement avoir un objet distinct pour chaque changement: changement d'état, demande de suppression, reception des compléments.
Mais il y a peut etre eu d'autre raison technique ou metier qui ont mené à la decision de faire porter les demandes de supplement et les reception directement sur les changements d'état.
Je ne suis pas fermé à lancer la discussion, mais peut etre en dehors de ce ticket que je preferais merger tel quel.
There was a problem hiding this comment.
Je reste super mitigé vis à vis de ça, parce qu'on intègre au dépôt du code relativement complexe pour quelque chose qui devrait être trivial : une liste d'états = un tableau d'historique. Pour moi ça frise pas mal la dette technique parce que dès qu'on devra toucher à ce changement d'état, il faudra retoucher cette boucle. Je trouve dommage d'intégrer ça au dépôt si ça doit être retouché plus tard.
D'ailleurs, il me semble qu'il y a déjà un ticket dans les tuyaux qui va obliger à se poser la question.
https://trello.com/c/ecg5IsPW/2057-conserver-l%C3%A9tat-suspendu-lors-dun-changement-d%C3%A9tape
Maintenant, si tu juges que c'est mieux de fusionner en état pour des raisons de mep et que tu veux y revenir plus tard, je ne bloque pas la fusion :)
There was a problem hiding this comment.
J'ai suivi la voie de la sagesse (aka @thibault) voici la séparation des logs en différents objets ! Une nouvelle revue n'est pas de refus :)
| {% if log.previous_log %} | ||
| {{ log.previous_log.get_stage_display }} | ||
| {% if log.previous_log.decision != "unset" %} | ||
| {% if log.type == "status_change" %} |
There was a problem hiding this comment.
Ça me semble beaucoup de logique pour de l'affichage. Est-ce que ça n'aurait pas plutôt sa place dans le modèle, avec un champ « type » de type Choices ?
```{{ log.get_type_display }}``
envergo/templates/haie/petitions/instructor_view_procedure.html
Outdated
Show resolved
Hide resolved
Add data migration step to set resumed_by for existing StatusLog entries that have info_receipt_date but were missing resumed_by. Use atomic=False to avoid pending trigger events error. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
envergo/petitions/views.py
Outdated
|
|
||
| def get_context_data(self, **kwargs): | ||
|
|
||
| def extract_entries(log): |
There was a problem hiding this comment.
Je reste super mitigé vis à vis de ça, parce qu'on intègre au dépôt du code relativement complexe pour quelque chose qui devrait être trivial : une liste d'états = un tableau d'historique. Pour moi ça frise pas mal la dette technique parce que dès qu'on devra toucher à ce changement d'état, il faudra retoucher cette boucle. Je trouve dommage d'intégrer ça au dépôt si ça doit être retouché plus tard.
D'ailleurs, il me semble qu'il y a déjà un ticket dans les tuyaux qui va obliger à se poser la question.
https://trello.com/c/ecg5IsPW/2057-conserver-l%C3%A9tat-suspendu-lors-dun-changement-d%C3%A9tape
Maintenant, si tu juges que c'est mieux de fusionner en état pour des raisons de mep et que tu veux y revenir plus tard, je ne bloque pas la fusion :)
https://trello.com/c/EQ4qj2or/1963-haie-lhistorique-des-dossiers-inclut-la-mise-en-attente-champs-de-l%C3%A9tat-du-dossier-attente-pc-3-3-analytics