Produits Entr'ouvert » w.c.s.

Dans un premier temps et pour simplifier l'interface, je propose de prévoir uniquement l'envoi de documents contenus dans des champs de traitement de type fichier (la liste de ceux-ci étant connue dans le workflow, contrairement aux variables).

sans doute un premier patch avec la modification du code d'envoi des mails, pour y ajouter la possibilité de documents attachés (et s'embêter à voir comment tester ça)

À vouloir commenter pour dire qu'il y a un **kwargs qui va permettre de descendre jusque la fonction email elle-même, je lis la signature de la fonction en question et il y a déjà une paramètre attachments. (commit 855a343f de 2010 de Benjamin, je ne sais pas trop à quel projet ça pouvait être lié).

donc : permettre l'envoi de n'importe quel champ fichier backoffice

Hésitation là-dessus, on veut vraiment un sélecteur de champ fichier ou bien une expression python permettant n'importe quoi. (ou un milieu où on propose un choix parmi une série de ('=form_var_bo_fichier', 'Champ X'), généré à partir des champs, comme ça on se donne ensuite la tranquillité nécessaire pour basculer vers une expression python au moment qui l'appellera, sans se prendre la tête sur une migration.

quand la valeur du champ n'est pas un fichier ou n'existe pas, si le champ relatif est marqué obligatoire : alerter (bon oui mais comment et qui ? en attendant, lever une exception et logger) ; sinon envoyer le mail sans le fichier concerné

Oui, pour moi on passe par self.compute() et on rapporte les exceptions via notify_of_exception; aussi on autorise le compute() à retourner None et on ignore alors juste cette référence.

Hésitation là-dessus, on veut vraiment un sélecteur de champ fichier ou bien une expression python permettant n'importe quoi.

(c'est une question mal formulée), et à ce sujet, ça me va de sortir/exploiter le get_file_value() qu'on a dans wcs/wf/backoffice_fields.py.

J'avais en tête un système qui ne permette pas de Python (parce que oui c'est oversouple et überpuissant, mais ça ne nous apporte aussi des fonctionnalités indocumentables et des dizaines de traces indéchiffrables dans nos mbox ; j'ai parlé).

Mais ça oblige à refaire toute une mécanique qui existe par ailleurs déjà; je comprends l'argument, c'est pour ça que j'avais la suggestion d'un choix dans une liste fermée mais dont les éléments seraient in fine des expressions python menant au fichier choisi (et libre à nous plus tard de transformer le <select> pour avoir un choix "autre" laissant libre entrée d'une expression Python, comme on le fait pour le choix du destinataire).

Je continue de trouver la fonctionnalité intéressante (en particulier pour les gens qui n'accèderont pas à la plate-forme), mais faut pas se mettre la rate au court-bouillon sur le délais : si on a ça fin juillet ça va.

On peut facilement obtenir la liste des varname associés aux actions de génération à partir d'un modèle ou d'attachement de fichier, ça me dirait bien de les avoir directement dans le sélecteur plutôt que d'avoir à utiliser une expression Python.

J'ai l'impression que ce sera des cas plus fréquent que d'avoir un champ BO de type fichier; pour moi le cas typique ce sera un agent qui génère un accusé soit via w.c.s. soit manuellement, l'accusé est attaché à la demande puis envoyé par mail.

Benjamin Dauvergne a écrit :

On peut facilement obtenir la liste des varname associés aux actions de génération à partir d'un modèle ou d'attachement de fichier, ça me dirait bien de les avoir directement dans le sélecteur plutôt que d'avoir à utiliser une expression Python.

Avec ce patch (enfin, ce bout de patch) les champs backoffice fichiers sont bien présentés dans une liste jolie, avec un "autre" final si la personne veut s'obliger à taper du python (pour d'autres champs non backoffice, ou pour inventer des bêtises et créer des bogues)

J'ai l'impression que ce sera des cas plus fréquent que d'avoir un champ BO de type fichier; pour moi le cas typique ce sera un agent qui génère un accusé soit via w.c.s. soit manuellement, l'accusé est attaché à la demande puis envoyé par mail.

Yep.

Thomas Noël a écrit :

Benjamin Dauvergne a écrit :

On peut facilement obtenir la liste des varname associés aux actions de génération à partir d'un modèle ou d'attachement de fichier, ça me dirait bien de les avoir directement dans le sélecteur plutôt que d'avoir à utiliser une expression Python.

Avec ce patch (enfin, ce bout de patch) les champs backoffice fichiers sont bien présentés dans une liste jolie, avec un "autre" final si la personne veut s'obliger à taper du python (pour d'autres champs non backoffice, ou pour inventer des bêtises et créer des bogues)

Je ne vois pas en quoi ça répond à ma remarque, je ne parle pas des champs backoffice fichiers, mais des fichiers attachés dans des AttachmentPart (action joindre un fichier ou générer un document office).

Benjamin Dauvergne a écrit :

Je ne vois pas en quoi ça répond à ma remarque, je ne parle pas des champs backoffice fichiers, mais des fichiers attachés dans des AttachmentPart (action joindre un fichier ou générer un document office).

Ah, mal lu. Pour ça, mon plan ça serait plutôt d'avoir dans l'action de génération de fichier (et dans l'action d'appel webservice quand elle est en mode récup de fichier), la possibilité de pousser le résultat dans un des champs backoffice, à choisir parmi les champs de type fichiers.

Quel raison t'incite à vouloir tout router dans les champs BO ? Il y a peut-être eu une discussion sur ce sujet que j'ai raté.

Thomas Noël a écrit :

Dans un premier temps et pour simplifier l'interface, je propose de prévoir uniquement l'envoi de documents contenus dans des champs de traitement de type fichier (la liste de ceux-ci étant connue dans le workflow, contrairement aux variables).

Je rebondis sur ça, la liste des variables est connu, au moins partiellement (on connait d'avance le nom des variables pour toutes les actions du workflow). Pour les web-service c'est juste compliqué parce qu'on ne connaît pas d'avance le format qui est renvoyé, si on avait des schémas JSON oui dans des sortes de WSDL, oui, mais on en a pas.

L'idée ce serait ça

wf = self.parent.parent
for status in wf.possible_status:
    for item in status.items:
        if isinstance(item, (AddAttachmentWorkflowStatusItem, ExportToModel)) and item.varname:
            codename = '=attachments.%s' % item.varname
            attachments_fields.append(
                # la valeur, le label, la clé 
                (codename, item.label, codename))

Plutôt que de lister explicitement les classes d'Item qui génèrent des fichiers attachés, on pourrait aussi leur ajouter une méthode get_file_attachment_variables().

Benjamin Dauvergne a écrit :

Quel raison t'incite à vouloir tout router dans les champs BO ? Il y a peut-être eu une discussion sur ce sujet que j'ai raté.

Parce que c'est plus simple à expliquer à tout le monde, qu'elles ne sont pas cachées au fin fond d'une action, qu'elles sont toujours là... Moi c'est pour ça que je préfère (surtout parce que c'est plus simple à expliquer). Le but c'est quand même d'arriver à permettre des workflows où les gens n'aient pas à configurer des noms de variables et autres paramétrages "techniques".

Ensuite, oui, on peut parfaitement ajouter la liste des champs qu'on sait être normalement présents via des actions qui génèrent des docs, mais ça sera pas simple de les nommer ("fichier récupéré depuis le webservice appelé en 4ème position du statut trucmuche...", "fichier généré par la 3ème action de création d'un fichier dans le statut chose"...). Un simple "item.label" ne suffira pas.

(sinon pour les webservices, ceux qui doivent recevoir des documents sont configurés comme tels à travers response_type='attachment', donc on pourrait les avoir aussi)

Bref, je vais crânement suivre mon plan d'abord avec mes backoffice_fields, on verra comment compléter avec all_other_file_fields ensuite ;)

Non non, c'est très bien ce que tu dis, mais je voudrais que ce soit public, compris et acceptés par tous que ce sera la règle pour faire des workflows maintenant, moi ça m'irait qu'on aille jusqu'à virer varname des actions générant des fichiers pour le remplacer par le fait de choisir la variable backoffice qui recevra le résultat, ça nous débarrassera aussi de ces histoires de attachements.xxx[y] parce qu'on se retrouve avec plusieurs fichiers pour la même variable :( Explicit is better than implicit, tu as raison.

Le calcul de la liste des pièces jointes possibles, il pourrait se faire dans le if 'attachments' in parameters:; et éventuellement déplacé dans une méthode get_attachments_options. Ajouter un notify_of_exception sur le cas du ValueError lors du convert_value_from_anything.

Idéalement il faudrait un test de l'interface d'édition, test_workflows_edit_sendmail_action dans test_admin_pages.py.

Je pense que je mettrais plutôt :

            for attachment in self.attachments:
                try:
                    picklableupload = eval(attachment, global_eval_dict, local_eval_dict)
                except:
                    get_publisher().notify_of_exception(sys.exc_info(),
                                                        context='[Sendmail/attachments]')
                    continue 
                if not picklableupload:
                    continue
                try:
                    picklableupload = FileField.convert_value_from_anything(picklableupload)
                except ValueError:
                    get_publisher().notify_of_exception(sys.exc_info(),
                                                        context='[Sendmail/attachments]')
                    continue
                attachments.append(picklableupload)

Comme ça il devient légitime pour un eval() de retourner None, ce qui me semble avoir du sens.

Ack.