Project

General

Profile

Development #8273

données structurées supplémentaires, "champs backoffice"

Added by Thomas Noël about 7 years ago. Updated almost 6 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
Start date:
16 September 2015
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:

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

0001-general-add-support-for-backoffice-fields-8273.patch (19.2 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 06 June 2016 11:17 PM
0001-general-add-support-for-backoffice-fields-8273.patch (30.4 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 11 June 2016 08:33 AM
0001-general-add-support-for-backoffice-fields-8273.patch (32.3 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 17 June 2016 12:29 PM
0001-general-add-support-for-backoffice-fields-8273.patch (36.2 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 19 June 2016 11:27 AM
0001-general-add-support-for-backoffice-fields-8273.patch (38.5 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 20 June 2016 11:07 AM
0001-general-add-support-for-backoffice-fields-8273.patch (38.5 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 20 June 2016 02:12 PM
0001-general-add-support-for-backoffice-fields-8273.patch (39.2 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 20 June 2016 02:29 PM
0001-general-add-support-for-backoffice-fields-8273.patch (39.2 KB) 0001-general-add-support-for-backoffice-fields-8273.patch Frédéric Péters (de retour le 10/10), 20 June 2016 03:09 PM

Related issues

Related to w.c.s. - Development #11443: champs backoffice de présentation (titre/etc.) dans la sélection de l'action "set backoffice fields"Fermé20 June 2016

Actions
Related to w.c.s. - Development #11442: champs de présentation (titre/...) dans les champs backofficeFermé20 June 2016

Actions
Related to w.c.s. - Development #11441: affichage des champs backoffice obligatoiresFermé20 June 2016

Actions
Related to w.c.s. - Development #11440: champs backoffice non textuelsFermé20 June 2016

Actions

Associated revisions

Revision 687a2456 (diff)
Added by Frédéric Péters (de retour le 10/10) over 6 years ago

general: add support for backoffice fields (#8273)

History

#1

Updated by Thomas Noël about 7 years ago

Question:
  • 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
#2

Updated by Frédéric Péters (de retour le 10/10) over 6 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.)
#4

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

Ça fait tout, il me semble, sauf les afficher (en barre latérale ?).

#5

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

Plutôt les afficher dans un nouveau panneau, entre "Résumé" et "Historique".

#6

Updated by Frédéric Péters (de retour le 10/10) over 6 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.

#7

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

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.

#8

Updated by Thomas Noël over 6 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 ?

#9

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

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.

#11

Updated by Thomas Noël over 6 years ago

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

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 ?

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":
  • 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é.
#12

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

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é.

#13

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".

#17

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
#18

Updated by Frédéric Péters (de retour le 10/10) 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)
#19

Updated by Frédéric Péters (de retour le 10/10) 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
#20

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

  • Related to Development #11442: champs de présentation (titre/...) dans les champs backoffice added
#21

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

#22

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

#24

Updated by Frédéric Péters (de retour le 10/10) over 6 years ago

  • Target version set to v1.47
#25

Updated by Frédéric Péters (de retour le 10/10) almost 6 years ago

  • Status changed from Résolu (à déployer) to Fermé

Also available in: Atom PDF