Development #471
Généraliser la disponibilité des tags
80%
Description
Généraliser la disponibilité des tags. Actuellement, tous les courriels et textes n'ont pas accès aux mêmes informations. Par exemple, pour les trois courriels de notifications à l'utilisateur les tags disponibles ne sont pas les mêmes (voir les descriptions sous le champ de création des champs de notification).
Fichiers
Demandes liées
Historique
Mis à jour par Thomas Noël il y a presque 13 ans
Il faut voir au cas par cas, il n'y a pas de "cas général" pour le traitement des tags, cela dépend du moment ou du type d'action.
En gros : il faut une description du problème plus précise ;)
Mis à jour par Frédéric Péters il y a presque 13 ans
Je pense ça viendrait avec un nettoyage des variables proposées, qu'on peut imaginer en plusieurs catégories,
- globales au site, hostname, admin_email, email_as_username…
- propres à un utilisateur, ce serait fournir des user_name, user_email… et user_var_foobar (pour les champs utilisateurs)
- propres à un formulaire, ce serait des données du formdata
- les var_foobar, mais aussi form_url, form_backoffice_url,
- et celles de l'état du workflow, genre form_current_status_name ou form_previous_status_name
- et celles du formdef, par exemple form_name
- locales à l'action, par exemple un nouveau mot de passe
Ensuite, une méthode comme get_html_text() regarderait les contextes présents et ajouterait leurs variables au dictionnaire de substitution (on peut imaginer qu'il s'agirait d'ajouter sur l'objet request de nouveaux attributs formdef, formdata, à l'image du user qui y est déjà).
Comme cela fait exploser le nombre de variables disponibles, on ne listerait plus dans la définition du texte/courriel que les variables locales à l'action, et on pointerait vers une page de documentation pour le détail.
Mis à jour par Frédéric Péters il y a presque 13 ans
- Fichier plone-varnames.png plone-varnames.png ajouté
- Sujet changé de Options de paramétrages des textes et des courriels à Généraliser la disponibilité des tags
- Statut changé de Solution déployée à Nouveau
Pour information, comment c'est présenté dans Plone…
Mis à jour par Frédéric Péters il y a presque 13 ans
- % réalisé changé de 0 à 50
C'est alimenté avec deux variables pour le moment (site_name et site_title), ce qu'il reste encore d'important à faire c'est d'appeler la méthode feed() quand un user, un formdef ou un formdata se trouve attaché au contexte, et leur ajouter des méthodes get_substitution_variables.
Ensuite de passer sur les différentes textes et courriels pour essayer de déterminer les contextes auxquels ils auront accès, et limiter le tableau à ceux-ci.
Voir le patch : r2112
Author: fpeters Date: 2011-06-21 14:29:10 +0000 (Tue, 21 Jun 2011) New Revision: 2112 Log: First step in generalizing access to substitution variables
Mis à jour par Victor Claudet il y a presque 13 ans
Ce serait cool d'adapter ce mode de fonctionnement au module d'export rtf. Comme ça on utilise les mêmes règles de nommage partout et on dispose des mêmes variable pour ça aussi.
Mis à jour par Benjamin Dauvergne il y a presque 13 ans
redmine@entrouvert.com écrivait:
La demande #471 a été mise à jour par Victor Claudet.
Ce serait cool d'adapter ce mode de fonctionnement au module d'export
rtf. Comme ça on utilise les mêmes règles de nommage partout et on
dispose des mêmes variable pour ça aussi.
Ok je m'y attèlerai, en attendant il faudrait ajouter à FormData
l'interface attendu pour les source dynamique de variables de
substitutions.
Mis à jour par Victor Claudet il y a presque 13 ans
Dans les variables peut-on prévoir différents formats pour les affichages de date ?
Actuellement on a "24/02/2011 16:52" c'est bien pour l'horodatage, mais peut on prévoir de n'afficher que la date sans les heures et minutes ?
Mis à jour par Frédéric Péters il y a presque 13 ans
- % réalisé changé de 50 à 80
Je viens (r2154) d'ajouter la publication des variables de formulaire, ça donne:
Form [form_details] Form Details Form [form_name] Form Name Form [form_number] Form Number Form [form_receipt_date] Form Receipt Date Form [form_receipt_time] Form Receipt Time Form [form_status_url] Form Status URL Form [form_url] Form URL Form [form_user_display_name] Form Submitter Name Form [form_user_email] Form Submitter Email Form [form_user_var_lenom]
Ainsi qu'aux form_var_name, form_field_whatever et form_f12 (qui ne peuvent pas être listés dans un tableau reprenant les variables toujours disponibles).
Mis à jour par Benjamin Dauvergne il y a presque 13 ans
Frédéric Péters a écrit :
Je viens (r2154) d'ajouter la publication des variables de formulaire, ça donne:
[...]
Ainsi qu'aux form_var_name, form_field_whatever et form_f12 (qui ne peuvent pas être listés dans un tableau reprenant les variables toujours disponibles).
Est-ce qu'à terme je pourrai utiliser get_subsitution_html_table() dans le paramètrage des workflows pour remplacer l'actuel listing des variables exportées par un formulaire ? Ça semble poser problème car la classe FormData n'ést qu'une metaclass comme tu le dis bien dans un commentaire et qu'il faudrait "enregistrer" la classe du formulaire en cours.
Mis à jour par Thomas Noël il y a presque 13 ans
Frédéric Péters a écrit :
Ainsi qu'aux form_var_name, form_field_whatever et form_f12 (qui ne peuvent pas être listés dans un tableau reprenant les variables toujours disponibles).
Je propose de ne pas envoyer de form_field_whatever et form_f12, ça me parait des trucs pas très stables à l'usage.
Ne laisser que les form_var_name.
En parallèle, faire en sorte que tous les fields aient un varname pre-rempli (modifiable, mais pas vide par défaut, quoi).
Mis à jour par Frédéric Péters il y a presque 13 ans
C'est plus de code pour ne pas fournir ces variables → objection. :)
Mis à jour par Thomas Noël il y a presque 13 ans
Frédéric Péters a écrit :
C'est plus de code pour ne pas fournir ces variables → objection. :)
Ok tant qu'on les affiche(ra) pas, ça me va (je viens de lire FormData.get_substitution_variables_list())
Sinon, pour ajouter un varname précalculé (on dérape du sujet du ticket, mais bon), je propose :
--- wcs/admin/fields.ptl (révision 2154)
+++ wcs/admin/fields.ptl (copie de travail)
@@ -380,6 +380,7 @@
fields.get_field_class_by_type(form.get_widget('type').parse())(
label = form.get_widget('label').parse(),
type = form.get_widget('type').parse(),
+ varname = misc.simplify(form.get_widget('label').parse(), space = '_'),
id = id))
elif form.get_widget('form').parse():
formdef = FormDef.get(form.get_widget('form').parse())
Mis à jour par Thomas Noël il y a plus de 12 ans
- Statut changé de Nouveau à Fermé
Considérant que le système des vars de substitution est en place, je ferme ce ticket.
Si des bogues apparaissent relatifs aux vars de subst, on créera de nouveaux tickets.