Produits Entr'ouvert » w.c.s.

Autres règles observées en cours de route: si le champ fichier n'est pas requis, mais qu'un fichier est uploadé et un champ de métadonnée requis par le type de justificatif est vide, une erreur de validation est levée et le champ devient requis, idem si un champ de métadonnées est rempli mais qu'aucun fichier n'a été uploadé, celui-ci devient requis; l'idée est qu'on doit garantir qu'une validation est possible.

Dans les tests, je ne retirerais pas les tests actuels, (avec des document_type sans metadata), qui doivent continuer à fonctionner.

            r += htmltext('<p>%s&nbsp;: %s</p>') % (meta_field['label'], metadata_value)

La place de l'espace insécable est dans le .po; aussi je mettrais ces entrées sous forme de <li>, dans un <ul>, avec un attribut class.

    PARTIAL_FILL_ERROR = _('This field is normally not required, but you must leave it completely '
                           'empty or fill it, You cannot fill it partially')

Ça doit être déclaré avec N_(), et _() appelé quand la chaine est utilisée.

Aussi, sur le fond, le message est-il correct ? i.e. on doit pouvoir avoir un justif de domicile avec un numéro de boite optionnel et ne pas dire à l'usager qu'il doit compléter tous les champs.

Frédéric Péters a écrit :

Dans les tests, je ne retirerais pas les tests actuels, (avec des document_type sans metadata), qui doivent continuer à fonctionner.

Je ne comprends pas, je n'ai retiré aucun test, j'ai juste modifié tous ceux qui concernaient des types de document fargo (et donc avec métadonnées).

[...]

La place de l'espace insécable est dans le .po; aussi je mettrais ces entrées sous forme de <li>, dans un <ul>, avec un attribut class.

Ok.

[...]

Ça doit être déclaré avec N_(), et _() appelé quand la chaine est utilisée.

Ok.

Aussi, sur le fond, le message est-il correct ? i.e. on doit pouvoir avoir un justif de domicile avec un numéro de boite optionnel et ne pas dire à l'usager qu'il doit compléter tous les champs.

L'erreur n'est levée que si un champ requis par le type de document n'est pas rempli (bien que le champ fichier dans son ensemble ne soit pas lui requis); donc sur le fond le message est imprécis, on peut laisser vide certains champs, mais c'est difficile à exprimer. Je veux bien une proposition si tu vois mieux. Idéalement ça devrait plutôt être géré coté client sans message pour expliquer ce qui est ou non requis et pourquoi.

Benjamin Dauvergne a écrit :

Frédéric Péters a écrit :

Dans les tests, je ne retirerais pas les tests actuels, (avec des document_type sans metadata), qui doivent continuer à fonctionner.

Je ne comprends pas, je n'ai retiré aucun test, j'ai juste modifié tous ceux qui concernaient des types de document fargo (et donc avec métadonnées).

En cela ça retire les tests sur des documents types qui n'ont pas de métadonnées.

Aussi, sur le fond, le message est-il correct ? i.e. on doit pouvoir avoir un justif de domicile avec un numéro de boite optionnel et ne pas dire à l'usager qu'il doit compléter tous les champs.

L'erreur n'est levée que si un champ requis par le type de document n'est pas rempli (bien que le champ fichier dans son ensemble ne soit pas lui requis); donc sur le fond le message est imprécis, on peut laisser vide certains champs, mais c'est difficile à exprimer. Je veux bien une proposition si tu vois mieux. Idéalement ça devrait plutôt être géré coté client sans message pour expliquer ce qui est ou non requis et pourquoi.

Donc le message est faux, va bloquer les usagers qui vont penser qu'ils doivent mettre quelque chose dans le champ "numéro de boite" alors que ce n'est pas vrai. Pourquoi ne pas en rester au message générique actuel (ERROR_NOTICE) et laisser l'usager regarder le champ fichhier pour voir le détail du problème ?

Le message n'est pas faux, il est imprécis. Il faut remplir les champs si on attache un fichier (ou attacher un fichier si on remplit un champ, même pas requis) mais pas forcément tous. Pour les tests je vois le problème, mais j'en ai identifié un plus embêtant qui est l'export des champs fichiers, ça ne marche plus avec les types de documents issus de fargo (je crois que ça ne marchait déjà plus avant car il y a file_type dans extra_attributes alors que le champ s'appelle document_type maintenant). Mais là s'ajoute le problème du contenu du champ metadata. Je me demande s'il vaut mieux n'exporter que l'identifiant du type de document et espérer qu'à l'import on aura un fargo configuré dans w.c.s. connaissant ce type de document pour en récupérer le schéma ou continuer à exporter le schéma tel quel avec possibilité qu'à l'exécution ça ne marche pas (pas de fargo ou un fargo qui n'a pas ce type là).

Patch 0004 avec des tests qui passent (certainment que je vais le merger avec le 0002 et mettre le 0003 en premier).

Correspond bien à ce que l'on a discuté, OK pour moi, merci.
Un point, pê que je ne comprends pas trop la cinématique décrite dans la vidéo : à 0:46 on voit que c'est validé or à ma compréhension, l'agent n'a pas encore validé l'adresse à cette étape, non ?

Il y a une validation à 0:42.

Si on utilise un justificatif déjà validé de la liste déroulante (dont il faut améliorer le placeholder je pense) alors on n'a pas besoin de valider, par contre il n'y aucun fichier qui y sera associé. De fait le justificatif est associé au hash d'un fichier, donc ce serait possible sur présentation d'un fichier déjà validé de retrouver la validation qui va avec, mais je ne l'ai pas fait trouvant le cas d'usage complètement limite. Je me dis qu'il faut forcer de vrai dématérialisation, la donnée informatique est plus importante que le document. Ce qui reste à faire pour la phase 2 c'est de pouvoir dans le remplissage d'un formulaire "pour le compte de", remplir les champs sans télécharger de fichier, en demandant une validation immédiate et aussi voir les validations associé au compte du formulaire et pas celui de l'agent actuellement connecté.

Il me semble que pour le justificatif de domicile (et pour d'autres certainement) il faudrait que j'ajoute un champ "Type du document" pour y marquer, facture EDF, facture d'eau, facture France Telecom, etc.

• ça ne gère que des champs chaînes de caractères, on pourrait éventuellement supporter des listes à choix ou d'autres simples de ce type, je préfère attendre le besoin
• il n'est pas possible d'ajouter du paramétrage à ces champs autre que leur nom: pas de class halfwidth, fullwidth, etc.. pas de texte d'aide, on pourrait assez facilement accepter un "extra_wcs_kwargs" dans les schémas fargo; mais je laisse ça pour plus tard
• le statut validé ou pas du document ne fait pas partie des variables exportées, donc il n'est pas possible de faire une condition de saut n'autorisant le saut que si c'est validé par exemple

Benjamin Dauvergne a écrit :

Parmi les limitations actuelles :

• ça ne gère que des champs chaînes de caractères, on pourrait éventuellement supporter des listes à choix ou d'autres simples de ce type, je préfère attendre le besoin
• il n'est pas possible d'ajouter du paramétrage à ces champs autre que leur nom: pas de class halfwidth, fullwidth, etc.. pas de texte d'aide, on pourrait assez facilement accepter un "extra_wcs_kwargs" dans les schémas fargo; mais je laisse ça pour plus tard

Contre ces points, dès maintenant, je suggérerais que le contenu de "metadata" (dans le json renvoyé par fargo) corresponde au json définissant les champs dans w.c.s.; de {'label': 'Nom', 'name': 'nom'} à {'label': 'Nom', 'varname': 'nom', 'type': 'string'}, ou que ça soit transformé ainsi (name→varname, ajout de type:string quand absence de type) automatiquement par w.c.s. Pour que w.c.s. derrière les affiche non pas en ajoutant des StringWidget mais en passant par les classes fields.

Dès maintenant parce que les champs adresse ils vont devoir faire appel au SIG (type de voie, nom de la voie, numéro, complément).

Ok.

En fait je ne vois pas comment utiliser les classes Field dans un CompositeWidget...

Je dirais qu'en appelant field.add_to_form(self) (self étant le compositewidget), ça pourrait peut-être passer; sinon factoriser un peu le add_to_form pour également avoir un add_to_composite_widget().

Après une première série de tests :

Au premier clic sur suivant, sur un formulaire pas complété, les différentes métadonnées sont marquées comme étant obligatoires, mais pas le champ fichier en tant que tel. Je les remplis, je valide, et voilà il est marqué obligatoire.

Le nom du fichier apparait après les métadonnées, c'est étrange.

Il manque l'ajout de 'fargo' au _q_exports de AlternateRootDirectory dans le module auquo.

La modif avec le enumerate(metadata), il me semble que ça casse la sélection d'un document existant. (le data-validations du <select> contient des références au varname, alors que les champs sont nommés façon f1$f0)

Après validation, dans le backoffice, "validated by Frédéric Péters on 2016-04-07T14:27:52.768120Z", ce serait bien d'avoir le timestamp en format/heure locale. (même si c'était déjà comme ça avant).

Aussi j'ai déplacé un bout du #10506 ce qui est devenu ce patch:

commit 30edefdeebccb4e94143bc0899baef2d51af8490
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date:   Fri Apr 8 12:56:49 2016 +0200

    tests: generalize site-options.cfg fixtures (#10444)

En testant (la précédente série, mais cette part du code ne me semble pas avoir été modifiée), j'ai eu des crashs sur self.document_type == None.

Pour avancer en local j'ai rapidement fait ces modifs :

diff --git a/wcs/fields.py b/wcs/fields.py
index e7bf08a..347f15d 100644
--- a/wcs/fields.py
+++ b/wcs/fields.py
@@ -725,7 +725,7 @@ class FileField(WidgetField):

     @property
     def metadata(self):
-        return self.document_type.get('metadata', [])
+        return (self.document_type or {}).get('metadata', [])

     @property
     def file_type(self):
diff --git a/wcs/forms/common.py b/wcs/forms/common.py
index 9a46cbf..87cea9d 100644
--- a/wcs/forms/common.py
+++ b/wcs/forms/common.py
@@ -634,8 +634,8 @@ class FormStatusPage(Directory):
     def display_file_field(self, form_url, field, value):
         r = TemplateIO(html=True)
         validated = None
-        is_fargo_dt = field.document_type.get('fargo', False)
-        has_metadata = bool(field.document_type.get('metadata', []))
+        is_fargo_dt = (field.document_type or {}).get('fargo', False)
+        has_metadata = bool((field.document_type or {}).get('metadata', []))
         if file_validation.has_file_validation() and is_fargo_dt and has_metadata:
             validated = file_validation.is_valid(self.filled, field, value)
             if validated is False:

Le problème me semble venir de formulaire datant d'avant l'ajout du champ document_type, alors ce patch là pourrait aider:

diff --git a/wcs/fields.py b/wcs/fields.py
index c83a813..a1189ed 100644
--- a/wcs/fields.py
+++ b/wcs/fields.py
@@ -890,6 +890,10 @@ class FileField(WidgetField):
         value = data.get(field_id)
         return getattr(value, 'metadata', {})

+    def __setstate__(self, state):
+        self.__dict__ = state
+        self.document_type = self.document_type or {}
+

 register_field_class(FileField)

Oui, ce patch-là fonctionne.

La ligne qui suit peut alors également être simplifiée :

    @property
    def file_type(self):
        return (self.document_type or {}).get('mimetypes', [])

J'ai testé en important un formulaire de bistro (candidature spontané qui contient un champ fichier), aucun souci.

Et j'ai mis en phase le code coté fargo il restait deux bidouilles, renvoyer des dates iso8601 sans microsecondes (le code dans w.c.s. n'aime pas, faudra passer à isodate là aussi) et gérer les cas ou les données du justificatif ne sont plus en phases avec les champs et le template de résumé (KeyError dans ce cas, qui est ignoré en faveur d'un template générique qui concatène tout).

ok.