Produits Entr'ouvert » w.c.s.

Ou plutôt que de la définir pour un rôle en particulier, pouvoir le spécifier pour une fonction, de la manière que pour les alertes.

Oui, ce serait selon moi à prioriser.
Par exemple : #46372

0001 : j'ai fait au plus simple mais j'ai du toucher à sql.py pour passer le formdata

Je pense qu'il faut surtout expliquer pourquoi tu as du passer le formdata.

Je pense qu'il faut surtout expliquer pourquoi tu as du passer le formdata.

De manière générale; i.e. la modification à la signature de la méthode view(), ici il me semble ça serait "pour que l'action puisse être configurée pour que le message soit affiché à l'usager associé à la demande, il faut passer la demande lors du rendu des différents éléments de l'historique".

Et ensuite, alors, expliciter le choix de la modif sur sql.py, que je ne comprends pas, parce que le contexte est là l'indexation full text, qui sera partagée par tout le monde, et j'aurais l'impression alors qu'en cas de restriction d'affichage sur l'action, il ne faut juste pas inclure son texte dans l'indexation full text, ce qui n'est pas quelque chose qui demande de passer formdata.

Sur l'ordre des manipulations, ça complique la relecture, on va avoir 0001 et à sa lecture dire "c'est dommage d'avoir du dupliquer is_for_current_user" mais le commentaire sera immédiatement obsolète par 0002 qui supprime la duplication qui vient d'être ajoutée.

Détails dans 0003 tu mets deux espaces devant les hasattr,

            if  hasattr(p, 'to') and not self.formdata.is_for_current_user(p.to):

et ici

                        if  hasattr(part, 'to') and not self.is_for_current_user(part.to):

À part ça, si tu veux tu pourrais ajouter dans 0003 un test dans tests/test_workflow_import.py pour assurer que la présence et l'absence de self.to sont bien gérés par les export/import (pas critique vu que to_export_to_xml et to_init_with_xml doivent déjà être traités par d'autres tests).

Et ça sera bon ainsi.

Du coup j'ai initialisé to à [] dans wcs/wf/register_comment.py.

Ça me fait plus peur qu'autre chose; ce n'est pas ce qui est fait dans DisplayMessageWorkflowStatusItem. Fais plutôt comme l'existant. Et adapte le test pour gérer la situation.

Bon je vois que je me suis retenu tout du long mais "hold ..." je ne trouve vraiment pas ça parlant comme message; fait plutôt genre "misc: move get_role_translation method to formdata".

Sur le reste ça me semble ok, si jamais tu te sentais d'ajouter un test dans tests/form_pages/ ça serait super (genre ajout d'un message à tout le monde, à un rôle que l'usager n'a pas, à un rôle que l'usager a, et vérifier ce qui s'affiche).