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 ?)
Files
Related issues
Associated revisions
History
Updated by Thomas Noël over 7 years ago
- 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
Updated by Frédéric Péters almost 7 years ago
- Subject changed from champs backoffice to 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.)
Updated by Frédéric Péters almost 7 years ago
- File 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch added
- Status changed from Nouveau to En cours
- Patch proposed changed from No to Yes
Ça fait tout, il me semble, sauf les afficher (en barre latérale ?).
Updated by Frédéric Péters almost 7 years ago
Plutôt les afficher dans un nouveau panneau, entre "Résumé" et "Historique".
Updated by Frédéric Péters almost 7 years ago
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.
Updated by Frédéric Péters almost 7 years ago
- File 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch added
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.
Updated by Thomas Noël almost 7 years ago
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 ?
Updated by Frédéric Péters almost 7 years ago
- File 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch added
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.
Updated by Frédéric Péters almost 7 years ago
- File 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch added
Voilà avec l'action modifiée pour pouvoir concerner plusieurs champs.
Updated by Thomas Noël over 6 years ago
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é.
Updated by Frédéric Péters over 6 years ago
- File 0001-general-add-support-for-backoffice-fields-8273.patch 0001-general-add-support-for-backoffice-fields-8273.patch added
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é.
Updated by Thomas Noël over 6 years ago
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".
Updated by Thomas Noël over 6 years ago
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
Updated by Frédéric Péters over 6 years ago
- Status changed from En cours to 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)
Updated by Frédéric Péters over 6 years ago
- Related to Development #11443: champs backoffice de présentation (titre/etc.) dans la sélection de l'action "set backoffice fields" added
Updated by Frédéric Péters over 6 years ago
- Related to Development #11442: champs de présentation (titre/...) dans les champs backoffice added
Updated by Frédéric Péters over 6 years ago
- Related to Development #11441: affichage des champs backoffice obligatoires added
Updated by Frédéric Péters over 6 years ago
- Related to Development #11440: champs backoffice non textuels added
general: add support for backoffice fields (#8273)