Development #8273
données structurées supplémentaires, "champs backoffice"
0%
Description
Objectif : permettre d'avoir des informations enregistrées par les agents qui gèrent une demande. Equivalent au "cadre réservé à l'administration".
Utiles pour :- compléter une demande
- «redresser» une information
- préparer des éléments pour une réponse
Ensemble de champs à définir dans le formdef, sur le même mode/ergonomie que les options de workflows.
Les champs sont affichés dans la sidebar d'une demande. Un bouton "modifier" est dispo si l'agent est destinataire (ou possède un autre rôle, défini dans le formdef, sur le même principe que les rôles de saisie backoffice ?)
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Thomas Noël il y a plus de 8 ans
- on les place dans le formdef ou dans le workflow ? ça pourrait être pertinent dans le workflow (un même workflow défini les champs de traitement pour "n" formulaires)
- ces champs définissent des form_backoffice_var_* ?
- quid de l'affichage dans les listing ?
- un pre-remplissage des valeurs devrait être effectué lors de la soumission du formulaire
Mis à jour par Frédéric Péters il y a presque 8 ans
- Sujet changé de champs backoffice à données structurées supplémentaires, "champs backoffice"
Sur des discussions la semaine dernière :
- Définition des champs au niveau du workflow
- Stockage dans le formdata.data, avec un id préfixé (c'est vraiment ce qui rend facile le reste)
- Méthode get_all_fields() dans formdef, qui fait formdef.fields + formdef.workflow.more_fields, utilisée à la place de formdef.fields où c'est pertinent.
- Action de workflow avec deux paramètres, 1) sélection du champ, 2) formule donnant ce qui ira dedans (expression python, ezt, etc.)
Mis à jour par Frédéric Péters il y a presque 8 ans
- Fichier 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Ça fait tout, il me semble, sauf les afficher (en barre latérale ?).
Mis à jour par Frédéric Péters il y a presque 8 ans
Plutôt les afficher dans un nouveau panneau, entre "Résumé" et "Historique".
Mis à jour par Frédéric Péters il y a presque 8 ans
Appeler la méthode get_all_fields plutôt que get_fields, pour qu'elle ait moins l'air d'être un simple retour du self.fields.
Mis à jour par Frédéric Péters il y a presque 8 ans
- Fichier 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch ajouté
Voilà, avec affichage dans un panneau sous le "Résumé" (appelé "Backoffice Data", en français je pensais à "Informations de traitement"). Et quelques tests en plus.
Mis à jour par Thomas Noël il y a presque 8 ans
Il y a un get_fields qui traine dans sql.py (ligne 464).
Utiliser formdef.workflow.get_backoffice_fields dans formdef.get_all_fields ?
A priori il n'y a pas ici de code pour la gestion des variables de substitution ou de l'api : tu imagines ça dans un patch à venir ?
Dans l'action, peut-être imaginer permettre de poser plusieurs valeurs d'un seul coup, comme pour l'action d'edition du profil ?
Mis à jour par Frédéric Péters il y a presque 8 ans
- Fichier 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch ajouté
Thomas Noël a écrit :
Il y a un get_fields qui traine dans sql.py (ligne 464).
Yep, corrigé en local et oublié d'attacher le nouveau patch.
Utiliser formdef.workflow.get_backoffice_fields dans formdef.get_all_fields ?
Yep.
A priori il n'y a pas ici de code pour la gestion des variables de substitution ou de l'api : tu imagines ça dans un patch à venir ?
J'avais oublié un s/fields/get_all_fields/. Tu penses à quoi pour l'API ?
Dans l'action, peut-être imaginer permettre de poser plusieurs valeurs d'un seul coup, comme pour l'action d'edition du profil ?
ok.
Patch à jour, sans ce dernier point.
Mis à jour par Frédéric Péters il y a presque 8 ans
- Fichier 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch ajouté
Voilà avec l'action modifiée pour pouvoir concerner plusieurs champs.
Mis à jour par Thomas Noël il y a presque 8 ans
Frédéric Péters a écrit :
Je me demandais si on séparait les variables du formulaire (form_var_*) et celles liées à son traitement (form_bvar_* ?), dans les variables de substitution et/ou dans l'API. Et donc, ma "réflexion":A priori il n'y a pas ici de code pour la gestion des variables de substitution ou de l'api : tu imagines ça dans un patch à venir ?
J'avais oublié un s/fields/get_all_fields/. Tu penses à quoi pour l'API ?
- pour les variables, laisser des form_var_* est sans doute le plus simple à expliquer et utiliser. Il faudra vérifier qu'en cas d'homonymie du varname, la valeur backoffice écrase la valeur du formulaire (ça pourrait être très pratique pour permettre à un agent d'amender une demande) ;
- pour l'API en revanche, on pourrait avoir un ['workflow']['fields'] séparé.
Mis à jour par Frédéric Péters il y a presque 8 ans
- Fichier 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch ajouté
pour les variables, laisser des form_var_* est sans doute le plus simple à expliquer et utiliser. Il faudra vérifier qu'en cas d'homonymie du varname, la valeur backoffice écrase la valeur du formulaire (ça pourrait être très pratique pour permettre à un agent d'amender une demande) ;
J'interdirais, par convention, les varnames identiques. (je vois déjà arriver le moment où les champs ne sont pas de même type).
pour l'API en revanche, on pourrait avoir un ['workflow']['fields'] séparé.
Fait dans le patch attaché.
Mis à jour par Thomas Noël il y a presque 8 ans
Frédéric Péters a écrit :
pour les variables, laisser des form_var_* est sans doute le plus simple à expliquer et utiliser. Il faudra vérifier qu'en cas d'homonymie du varname, la valeur backoffice écrase la valeur du formulaire (ça pourrait être très pratique pour permettre à un agent d'amender une demande) ;
J'interdirais, par convention, les varnames identiques. (je vois déjà arriver le moment où les champs ne sont pas de même type).
Ca me va très bien.
pour l'API en revanche, on pourrait avoir un ['workflow']['fields'] séparé.
Fait dans le patch attaché.
Parfait.
Je teste tout cela "à la main".
Mis à jour par Frédéric Péters il y a presque 8 ans
Mis à jour par Frédéric Péters il y a presque 8 ans
Mis à jour par Frédéric Péters il y a presque 8 ans
Mis à jour par Thomas Noël il y a presque 8 ans
Ack.
Notes pour plus tard, tickets à faire au cas où:- tester les affectations pour les champs de type date, fichier, etc.
- seuls les champs complétés sont affichés en backoffice (page de traitement d'un formdata) : il serait préférable d'afficher tous les champs marqués obligatoires, même s'ils sont vides
- toujours sur la page de traitement d'un formdata, afficher les champs de type titre/sous-titre/commentaires
- en revanche, ne pas lister les champs titre/sous-titre/commentaires dans l'action "Set Backoffice Fields"
- idem, ne pas lister les champs titre/sous-titre/commentaires dans la case "Backoffice Fields (changer)" de définition d'un workflow
- à noter, crash tardif dans sql.py si la formule est « =4+4 » alors que le champs est de type texte
Mis à jour par Frédéric Péters il y a presque 8 ans
- Statut changé de En cours à Résolu (à déployer)
commit 687a2456cea7e5eac42d8fa3ddda4d8a3eadb709
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Mon Jun 6 18:55:21 2016 +0200
general: add support for backoffice fields (#8273)
Mis à jour par Frédéric Péters il y a presque 8 ans
- Lié à Development #11443: champs backoffice de présentation (titre/etc.) dans la sélection de l'action "set backoffice fields" ajouté
Mis à jour par Frédéric Péters il y a presque 8 ans
- Lié à Development #11442: champs de présentation (titre/...) dans les champs backoffice ajouté
Mis à jour par Frédéric Péters il y a presque 8 ans
- Lié à Development #11441: affichage des champs backoffice obligatoires ajouté
Mis à jour par Frédéric Péters il y a presque 8 ans
- Lié à Development #11440: champs backoffice non textuels ajouté
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Statut changé de Résolu (à déployer) à Fermé
general: add support for backoffice fields (#8273)