Produits Entr'ouvert » w.c.s.

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

Ça pourrait être une donnée de traitement à l'identifiant particulier (magie, mais on a toute l'infra pour), ou un paramètre du formdef (mais à créer et moins souple), ou autre chose encore. (?)

Pour moi, plutôt un paramètre du formdef, qui sera par défaut vide, et qui est un template sur le formdata. Lors du formdata.store() on recalcule sa description.

Je pensais que à quelque chose comme formdef.get_display_id_format() (qui n'a jamais été très loin). Quand la description existe elle est utilisée par formdata.get_display_name() ; sinon on reste sur "name #id"

Use case sympas : « Demande de réservation AquaGym du vendredi soir pour Francis Kunz (n°123-33) », « Demande d'inscription scolaire de Sidonie », etc. A noter que je pense à un remplacement du nom de la demande partout où il est affiché, en frontoffice comme en backoffice.

De mon côté c'est une information qui doit venir en plus de ce qu'on a déjà (nom du formdef / identifiant du formdata). (parce que visuellement ça doit ensuite être présenté différemment).

Et pour rappeler un problème du display_id, le problème de poser cette info au niveau du formdef, c'est qu'il est attendu (était attendu pour le display_id) qu'un changement touche l'ensemble des demandes existantes. (ce qui peut aussi être vu comme un avantage mais complique davantage encore l'affaire).

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

(...) repris en description de la sortie ics.

Et la sortie geojson, tiens.

En première lecture, ce qui manque, je trouve, c'est de voir dans l'UI (hors de l'API) la possibilité d'usage de ce "digest". Je serais pour au moins afficher form_digest dans la liste des variables disponibles, dans les Substitutions.register de formdata.py ; et que ça soit '' et pas None ('form_digest': self.digest or ''). Si possible mettre à jour help/fr/api-user.page et help/fr/misc-substvars.page.

Pour l'instant je n'ai pas d'idée d'un autre affichage utile dans l'UI, mais il faudrait y penser, peut-être dans l'interface de traitement, afin que cette fonctionnalité ne devienne pas juste un gadget auquel on ne pense que dans des usages "tordus". Par exemple pourquoi ne pas afficher ce digest comme résumé de la demande lorsque celui-ci est replié. Bref, si tu as souvenir de la demande initiale de « Il y aurait souhait de remonter ... » comme tu dis dans le ticket.

[...] moins afficher form_digest dans la liste des variables disponibles,

Quand un template a été défini (avantage il y aura quelque chose dans la variable) ou tout le temps (avantage ça montre que ça existe) ?

Bref, si tu as souvenir de la demande initiale de « Il y aurait souhait de remonter ... » comme tu dis dans le ticket.

Très simple, dans les dernières maquettes GNM, dans les demandes en cours, pour un permis de construire on affiche à côté l'adresse.

_~~

Cela étant pour GNM il me revient que ça ne sera pas suffisant, que j'ai réuni deux besoins, on voudrait aussi remonter (dans la liste des demandes ouvertes) une autre info disponible en donnée de traitement; et j'en viens à me dire que plutôt, modifier l'API pour qu'elle retourne de manière systématique toutes les variables de traitement, ça ferait le taf attendu. À suivre.

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

Cela étant pour GNM il me revient que ça ne sera pas suffisant, que j'ai réuni deux besoins, on voudrait aussi remonter (dans la liste des demandes ouvertes) une autre info disponible en donnée de traitement; et j'en viens à me dire que plutôt, modifier l'API pour qu'elle retourne de manière systématique toutes les variables de traitement, ça ferait le taf attendu. À suivre.

Si le digest est (re)calculé à chaque formdata.store() il suffit d'y inclure le {{form_var_donnee_de_traitement|default:"encore inconnu"}} concerné, non ?

Si le digest est (re)calculé à chaque formdata.store() il suffit d'y inclure le {{form_var_donnee_de_traitement|default:"encore inconnu"}} concerné, non ?

Si on a besoin d'une seule donnée, oui; le truc étant de remonter deux infos, genre le type de signalement et la commune qui assure le traitement.

Dans set_auto_fields, un cas limite, si on utilise {{form_number}} dans le digest, mais qu'on redéfini aussi id_display, alors self.get_substitution_variables() ne sera pas bon. Pour ça il faudrait calculer d'abord self.id_display puis le digest à partir des nouvelles variables de subst... Bref, on s'interdit à mon sens d'utiliser form_number dans le digest. Je ne sais pas si c'est grave.

Pour le mode pickle, afficherait-on un message "Existing forms are not updated" ?

Dans l'idée qu'on aurait bientôt aussi des templates pour geojson, geojson_frontoffice, ics, ... : est-ce qu'on ne voudrait pas partir comme pour la geolocalisation, avec un formdef.templates qui serait un dico, construisant autant de colonnes que nécessaires ?

Bref, on s'interdit à mon sens d'utiliser form_number dans le digest. Je ne sais pas si c'est grave.

Je dirais que non, pas grave, parce que le numéro on le reprend déjà indépendamment dans les différents endroits.

Pour le mode pickle, afficherait-on un message "Existing forms are not updated" ?

Pourquoi pas, oui.

(...) formdef.templates qui serait un dico, construisant autant de colonnes que nécessaires.

Ça me va plutôt de faire des attributs distincts.

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

Bref, on s'interdit à mon sens d'utiliser form_number dans le digest. Je ne sais pas si c'est grave.

Je dirais que non, pas grave, parce que le numéro on le reprend déjà indépendamment dans les différents endroits.

Ça roule ; ce n'est rien d'impossible à corriger au cas où.

Pour le mode pickle, afficherait-on un message "Existing forms are not updated" ?

Pourquoi pas, oui.

Au plaisir de voir ça.

(...) formdef.templates qui serait un dico, construisant autant de colonnes que nécessaires.

Ça me va plutôt de faire des attributs distincts.

Ok aussi (pour la geoloc on imaginait permettre à terme le stockage de différentes géoloc selon les données et/ou le workflow ; ce n'est pas le cas ici, les templates seront tous toujours dispo partout).

• un «digest» qui fait un appel webservice, 1 ou 2 secondes
• un formulaire qui a une démarche avec des milliers de demandes... mais quasi toutes anonymisées (et qui resteront là ad-vitam, sur 2 ou 3 ans, pour cause de stat)
  et dans ce cas, le premier cron va passer quelques heures bloqué sur cette reindexation.

Je me demande si on ne devrait pas limiter la re-indexation aux demandes non anonymisées ? Ça peut faire l'objet d'un autre ticket/patch (quoique c'est bien lié à cette arrivée d'un template calculé lors du store(), qui peut potentiellement fortement ralentir la réindexation).

Ultra détail sans conséquence, juste pour montrer que je relis, dans le test, des digest_template = 'digest of number {{form_number}}' mais comme évoqué plus haut, et même si on peut se le permettre dans le test, form_number devra éviter de se retrouver dans un digest. Voilà, j'arrête de pinailler.

This change will be applied to new and modified forms. → ... only applied to ... ?

Number → Reference, ok, passons ça ici.

Bref, ack, avec ces petits trucs ou pas.