Produits Entr'ouvert » w.c.s.

Le problème c'est qu'ExportToModel et AddAttachmentWorkflowStatusItem utilise le même objet AttachmentEvolutionPart pour stocker les fichiers créés et rien n'empêche pour ces deux actions de les accomplir plusieurs fois, donc même en leur donnant un nom on pourrait avoir plusieurs fichiers.

Je dirais qu'on pourrait avoir quelque chose du style, attachments.<varname>[x].filename/content_type/content ou les attachements seraient rangés dans l'ordre inverse de leur arrivée. Comme on a pas de boucle dans le wscall je ne vois pas comment envoyer une liste variable de fichiers attachés, mais je laisse l'exercice pour plus tard.

Il suffit de stocker le <varname> dans l'objet AttachementEvolutionPart au moment de sa création.

C'est sans le nommage des variables (je laisse ça comme exercice au lecteur attentif). Je ne suis pas sûr sur le coup de renversé le tableau des fichiers, ça rend le test plus compliqué mais l'utilisation me semble plus simple à utiliser, à moins de faire en sorte d'avoir une équivalence de ce genre attachments.content == attachements[-1].content.

En discutant la chose rapidement hier soir avec Serghei (qui a besoin d'envoyer le document généré à iParapheur, via passerelle), on s'est dit qu'une autre solution pourrait être que l'action "ExportToModel" génère dans le workflow_data les informations nécessaires (une URL) pour que passerelle récupère le document. Ca éviterait surtout de se retrouver avec des Mo de base64 dans du json (c'est vraiment très peu efficace).

Un peu comme pour les docs attachés par un formulaire de workflow (cf #8031), on aurait dans workflow_datat "foobar_content_type" + "foobar_filename" + "foobar_url", où foobar est le nom de variable choisi dans l'action ExportToModel.

Resterait cependant à étudier les droits d'accès à ces URL...

Concernant la possibilité de générer plusieurs documents avec le même nom : on n'en a pas besoin, selon moi. Une action ExportToModel créé un document "foobar", si cette action est exécutée plusieurs fois, c'est la dernière qui gagne.

Dans les tests, tu pourrais laisser les existants intacts (i.e. sans placer varname) et en ajouter des variantes qui auraient justement varname ?

Autre détail de style que je note, cette manière de continuer les lignes, par le \ plutôt qu'en ayant une parenthèse ouverte, je n'aime pas trop : (et même la pep8 dit que c'est pas super).

    resp = login(get_app(pub), username='admin', password='admin') \    
        .get(attachment_variable.url).follow()

À part ça, sur le fond, on pourrait avoir content = le contenu, et b64_content = le contenu encodé en base64 ?

+ ajouter une référence à ce ticket aux messages de commit + pour le 0004 réécrire son sujet pour tenir sur une ligne de 80 caractères (genre simplement 'add 'attachments' substitution variable to formdatas (#8829)).

Il manque l'import de VarnameWidget dans le patch 0003

Serghei Mihai a écrit :

Il manque l'import de VarnameWidget dans le patch 0003

Ce qui est attrapé par tests/test_admin_pages.py::test_workflows_add_all_actions; pensons à exécuter tous les tests.

[2015-11-02 17:52:17] exception caught
Exception:
  type = '<type 'exceptions.NameError'>', value = 'global name 'VarnameWidget' is not defined'

Stack trace (most recent call first):
  File "/home/fred/src/eo/wcs/wcs/wf/export_to_model.py", line 266, in add_parameters_widgets
   264                      value=self.backoffice_info_text)
   265         if 'varname' in parameters:
>  266             form.add(VarnameWidget, '%svarname' % prefix,
   267                      title=_('Variable Name'), value=self.varname)
   268 

(J'ai poussé le patch de corection de #4292.)

Ack