Produits Entr'ouvert » w.c.s.

On a déjà un paramètre "Types de fichier" dans les champs de type fichier, là on ajoute un "Types de documents"; je verrais plutôt l'extension des "Types de fichier" existants avec les infos de Fargo. (genre ajouter dans le paramétrage de "types de fichier" une sélection parmi les types proposés par Fargo).

Pour savoir si on est dans le backoffice il y a désormais un get_request().is_in_backoffice().

Pour savoir si on est dans le backoffice il y a désormais un get_request().is_in_backoffice().

Qui arrive dans #8306.

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

On a déjà un paramètre "Types de fichier" dans les champs de type fichier, là on ajoute un "Types de documents"; je verrais plutôt l'extension des "Types de fichier" existants avec les infos de Fargo. (genre ajouter dans le paramétrage de "types de fichier" une sélection parmi les types proposés par Fargo).

Il me semble que type de fichier est un champ multiple, j'ai vraiment besoin que le type de document soit unique, la complexité que cela introduirait d'avoir des types de document multiple pour un champ ne me semble pas souhaitable. Ça veut dire refaire le web-service des métadonnées pour accepter une liste de types au lieu d'un seul et de renvoyer éventuellement une liste de structure métadonnées au lieu d'une seule. Coté backoffice w.c.s je vais devoir proposer plusieurs liens ou permettre dans le lien vers le web-service de passer cette liste de types de documents et ainsi restreindre un menu déroulant dans l'écran de validation pour y choisir le bon type, et ensuite modifier mon formulaire en fonction du type choisi. Pour moi le jeu n'en vaut pas la chandelle.

Est-ce qu'on pourrait se permettre de revenir à un champs de fichier unique ? Si on a besoin d'un champ autorisant soit des vidéos soit des images et bien on adaptera la liste des types MIME en conséquence plutôt que de permettre de combiner les types techniques "Fichier Vidéos" et "Fichier Images".

Pour savoir si on est dans le backoffice il y a désormais un get_request().is_in_backoffice().

Ok.

Ok, c'est que j'ai lu trop vite et il m'avait semble que ça gérait déjà la sélection de plusieurs types; ça ne m'ennuierait pas trop de limiter à un seul élément la sélection, je viens de faire une inspection rapide et je trouve un seul formulaire en circulation qui utilise plusieurs types (demarches.vincennes.fr/formdefs/163).

Cela étant, la migration pour passer sur un type de fichier unique n'est pas nécessairement aisée, le plus simple ça doit sans doute être de continuer à utiliser une liste mais de forcer celle-ci à contenir un seul élément (le CheckboxesWidget a déjà un paramètre max_choices, qu'on mettrait à 1).

Par la suite, le CheckboxesWidget pourrait gérer le cas particulier du max_choices mis à 1 et basculer sur des boutons radios dans cette circonstance.

Question vu avec Fred:

Préfères-tu que je génère directement des types de fichier depuis les types de document fargo, ou bien ajouter un menu déroulant pour laisser la personne qui configure w.c.s. associer un type de document à un type de fichier; en somme est-ce que je laisse un indirection au risque de perturber les gens parce qu'il y a deux concepts différents, ou je mélange les deux choses (et je rajouterai un champ slug au type de fichier pour garder la référence vers la définition dans fargo et dans fargo j'ajoute la possibilité de déclarer des types MIME)

Ok pour générer dixit Fred.

J'ai ajouté une migration sur la classe FileField pour renommer file_type en document_type et en changer le format (je stocke un dico décrivant tous les détails du type de fichier, mimetypes, si c'est lié à fargo, etc..).

Si c'est ok je regarderai pour faire un test de la migration.

Comme je le notais plus haut je préférerais vraiment conserver une liste, et poser un max_choices=1 sur le CheckboxesWidget.

Ce n'est juste pas possible, actuellement ce n'est pas la référence au type d'objet qui est stocké dans la liste, c'est directement des types MIME.

Et utiliser un CheckboxesWidget n'a pas été possible non plus parce que j'ai une donnée complexe maintenant hors les CheckboxesWidget ne gère que (clé, label) et la mécanique des formulaires d'admin n'admet pas de transformation sur un POST de formulaire qui me permettrait de convertir les clés en valeur. Le SingleSelectWidget me permet de passer du (valeur, label, clé) et d'avoir directement la valeur de l'objet 'filetype' au retour de parse(). Je pense vraiment que j'ai limité les modifications en faisant cela. C'est la nécessité du migrate qui te pose souci ?

Ok pour ça; donc je regarde la fonction migrate().

if self.file_type == value['mimetypes']:

Mais self.file_type, avant, c'est nécessairement une liste, et value['mimetypes'], maintenant, c'est nécessairement une chaine de caractère (à regarder les exemples dans get_default_document_types()); non ?

Mais self.file_type (bis), c'est de toute façon pas l'ancien attribut mais une propriété qui retourne self.document_type.get('mimetypes').

_~~

Pour aider les tests, voici une valeur réelle de cfg['filetypes'] (demarches.vincennes.fr)

{1: {'mimetypes': ['application/pdf', 'application/vnd.oasis.opendocument.text', 'application/msword', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'application/vnd.oasis.opendocument.spreadsheet', 'application/vnd.ms-excel', 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'], 'label': 'Document'}}

et le dict d'un champ de formulaire :

>>> f.fields[10].__dict__
{'extra_css_class': None, 'max_file_size': None, 'prefill': {'type': 'none'}, 'hint': None, 'file_type': ['image/*', 'application/pdf,application/vnd.oasis.opendocument.text,application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document,application/vnd.oasis.opendocument.spreadsheet,application/vnd.ms-excel,application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'], 'varname': None, 'required': False, 'label': 'Joindre un document', 'in_listing': False, 'type': 'file', 'id': '15'}

_~~

get_admin_attributes, pas besoin d'une variable intermédiaire.

L'attribut document_type, il faudrait l'initialiser à {} sinon je pense que l'import/export xml peut échouer.

_~~

wcs/file_validation.py : manque l'entête gpl. Le json_encode_helper() on l'a maintenant dans misc (il me semblait avoir vu un patch l'utilisant). Détail, entre les fonctions, une seule ligne. La ligne 108 est bien trop longue et les chaines devraient être traduites individuellement, il faut éviter le markup dedans.

Les fonctions qui retournent une valeur, je préfère quand elles sont explicites dans leur "return None" (pas juste "return", pas juste laisser la fonction se terminer).

À ce sujet, validation_link pourrait retourner une chaine vide, ça permettrait un systématique r += self.file_validation_status(f, value) dans common.py

_~~

Dans les points "ce qui reste à faire" du premier commentaire, il y a des trucs qui peuvent aller dans d'autres tickets mais il faudrait au moins ne pas afficher la validation hors backoffice.

_~~

Dans les points qui restent à faire, un truc qui n'a pas été identifié et est pourtant important, c'est qu'on permet à l'admin d'aller modifier les types de fichier dans settings/filetypes/, et qu'une fois modifié, il faut aller mettre à jour l'ensemble des formdefs (pour le moment cf FormDef.update_mimetypes).

(il y a déjà un test qui vérifie que ça fonctionne correctement). (test_admin_pages/test_settings_filetypes_update)

On pourrait aussi ne conserver qu'une référence et ne plus se prendre le choux (je fais déjà un migrate), il restera juste le cas d'un filetype supprimé.

Ce n'est volontairement pas une référence pour permettre à l'import/export de fonctionner sans avoir à se soucier du paramétrage. C'était plus facile ainsi mais ça pourrait être une référence, l'export devrait alors quand même contenir l'intégralité du paramétrage et à l'import il y aurait à trouver l'entrée de paramétrage qui corresponde, et à la créer si jamais celle-ci n'existait pas.

Je n'avais pas pensé à l'import/export, en regardant export_to_xml je me dis qu'actuellement document_type n'est pas exportable, car c'est un dico mais une des clés a pour valeur une liste, la clé mimetypes... Il faut soit que je remplace complètement export_to_xml sur FileField (je ne pense pas que je puisse le spécialiser pour un seul champ) soit que je change de manière de stocker pour quelque chose de plus à plat.

Je n'ai pas traité le update_mimetypes, je m'y attelle.

Première visite sur la page d'accueil après les patchs, exécution du code de migration :

Exception:
  type = '<type 'exceptions.KeyError'>', value = ''mimetypes''

Stack trace (most recent call first):
  File "/home/fred/src/eo/wcs/wcs/fields.py", line 777, in migrate
   775                 document_types = self.get_document_types()
   776                 for key, value in document_types.iteritems():
>  777                     if self.file_type == value['mimetypes']:
   778                         self.document_type = value.copy()
   779                         self.document_type['id'] = key

  locals: 
     file_type = 'image/*'
     self = <wcs.fields.FileField object at 0x7fee0c608550>
     key = 'justificatif-de-domicile'
     value = {'fargo': True, 'id': 'justificatif-de-domicile', 'label': 'Justificatif de domicile'}
     document_types = {'_image': {'mimetypes': ['image/*'], 'id': '_image', 'label': 'Fichiers image'}, '_video': {'mimetypes': ['video/*'], 'id': '_video', 'label': 'Fichiers vid\xc3\xa9o'}, 'justificatif-de-domicile': {'fargo': True, 'id': 'justificatif-de-domicile', 'label': 'Justificatif de domicile'}, '_audio': {'mimetypes': ['audio/*'], 'id': '_audio', 'label': 'Fichiers son'}}

Je propose ça pour ne pas avoir une vue du frontoffice dans la popup :

diff --git a/wcs/root.py b/wcs/root.py
index 8eb6ee3..9382c9d 100644
--- a/wcs/root.py
+++ b/wcs/root.py
@@ -309,9 +309,8 @@ class RootDirectory(Directory):
         return forms.root.RootDirectory()._q_lookup(component)

     def reload_top(self):
-        r = TemplateIO(html=True)
-        r += htmltext('<script>window.top.document.location.reload();</script>')
-        return r.getvalue()
+        get_response().filter = {}
+        return htmltext('<html><body><script>window.top.document.location.reload();</script></body></html>')

     admin = None
     backoffice = None

_~~

Il faudra penser à ajouter le ('reload-top', 'reload_top') dans auquotidien (j'ai le patch en local).

_~~

À part ça, je n'afficherais pas le lien de validation pour les documents qui sont déjà validés; aussi je trouverais super d'avoir l'info sur le statut de validation (quand c'est pertinent) dans une classe du <div> d'au-dessus.

            r += htmltext('<div class="value">')  # <--- ce <div> là.
            s = f.get_view_value(value)
            s = s.replace(str('[download]'), str('%sdownload' % form_url))
            r += s
            if isinstance(f, FileField) and get_request().is_in_backoffice():
                r += htmltext(self.file_validation_status(f, value))

La classe pourrait être posée qu'on soit ou pas dans le backoffice.

_~~

(la description du patch 0002- a une longue trop longue, faudrait rewrapper, mais par contre le commentaire dans wcs/fields.py a lui des lignes trop courtes (ça tient sur deux lignes en respectant la limite à 80 caractères). (et s/overload/overload/)

_~~

Pour les tests j'ai donné plus haut un extrait d'une vraie valeur trouvée à Vincennes, il pourrait y avoir un test sur celle-ci ?

Euh je n'ai toujours rien poussé, j'attends un ack.

Dans 0002, s/overloaf/overload/.

Dans 0003, dans les tests, en ajouter un dans test_backoffice_pages et un autre dans test_form_pages, pour couvrir display_file_field.

Dans 0003 :

            if isinstance(f, FileField):
                r += htmltext(self.display_file_field(f, value))

Ah oui dsl je ne devais pas être dans la bonne branche, faudra que je pense à traffiquer un peu mon zsh.

    with file(os.path.join(pub.app_dir, 'site-options.cfg'), 'w') as site_option:
        site_option.write('''[options]
fargo_url = http://fargo.example.net/
''')

Ça va écraser le site-options.cfg qui peut exister quand les tests s'exécutent en mode SQL.

Par ailleurs, dans test_form_pages, je dois relire ce qu'on écrivait mais il me semblait qu'on n'affichait rien concernant la validité des pièces, du coup, pourquoi un appel à fargo ?

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

[...]

Ça va écraser le site-options.cfg qui peut exister quand les tests s'exécutent en mode SQL.

Ok donc test de présence/lecture/écriture ?

Par ailleurs, dans test_form_pages, je dois relire ce qu'on écrivait mais il me semblait qu'on n'affichait rien concernant la validité des pièces, du coup, pourquoi un appel à fargo ?

Tu disais:

À part ça, je n'afficherais pas le lien de validation pour les documents qui sont déjà validés; aussi je trouverais super d'avoir l'info sur le statut de validation (quand c'est pertinent) dans une classe du <div> d'au-dessus.
[...]
La classe pourrait être posée qu'on soit ou pas dans le backoffice.

Pour pouvoir afficher cette classe en front-office, je dois faire un appel à Fargo.

Ça passe chez toi ?

tests/test_backoffice_pages.py::test_backoffice_file_field_validation[pickle] FAILED
tests/test_backoffice_pages.py::test_backoffice_file_field_validation[sql] FAILED
...
tests/test_form_pages.py::test_file_field_validation[pickle] FAILED
tests/test_form_pages.py::test_file_field_validation[sql] FAILED
...

Ouaip :

(wcs)bdauvergne@dor-lomin:~/Code/wcs$ PYTHONPATH=$(pwd) py.test -vv -k file_field --capture=no tests
============================================================================= test session starts ==============================================================================
platform linux2 -- Python 2.7.9 -- py-1.4.30 -- pytest-2.6.3 -- /home/bdauvergne/.virtualenvs/wcs/bin/python2
plugins: random
collected 729 items 

tests/test_backoffice_pages.py::test_backoffice_file_field_validation[pickle] PASSED
tests/test_backoffice_pages.py::test_backoffice_file_field_validation[sql] PASSED
tests/test_form_pages.py::test_form_file_field_submit[pickle] PASSED
tests/test_form_pages.py::test_form_file_field_submit[sql] PASSED
tests/test_form_pages.py::test_file_field_validation[pickle] PASSED
tests/test_form_pages.py::test_file_field_validation[sql] PASSED
tests/test_formdata.py::test_file_field[pickle] PASSED
tests/test_formdata.py::test_file_field[sql] PASSED
tests/test_formdef.py::test_file_field_migration PASSED
tests/test_formdef_import.py::test_file_field PASSED

==================================================================== 719 tests deselected by '-kfile_field' ====================================================================
================================================================== 10 passed, 719 deselected in 8.75 seconds ===================================================================

(wcs)bdauvergne@dor-lomin:~/Code/wcs$ pip freeze
beautifulsoup4==4.4.1
feedparser==5.2.1
funcsigs==0.4
mechanize==0.2.5
mock==1.3.0
pbr==1.8.1
psycopg2==2.6.1
py==1.4.30
pytest==2.6.3
pytest-random==0.2
python-dateutil==2.4.2
qrcode==5.1
scgi==1.8
six==1.10.0
vobject==0.6.6
waitress==0.8.10
-e git+git@git.entrouvert.org:wcs@cfd721045a207ffadfbb6468d99b73ce3f9e3368#egg=wcs-wip_file-validation
WebOb==1.5.1
WebTest==2.0.18

Ok, go.