Règles de champs pour devis/factures/avoirs
On a parfois besoin de champs qui n'apparaissent que pour certains types d'affaires. Et chaque CAE doit pouvoir paramétrer ça. Ce besoin est issu de #1339 (closed) mais ne s'y limite pas.
Exemples connus
Lieu d'exécution (existe déjà)
Ce champ est déjà utilisé mais s'appelle systématiquement (lieu d'exécution des travaux), ce qui peut être parfois bizarre.
- par défaut : facultatif pour devis et factures, « lieu d'exécution »
- chantier : « lieu d'exécution des travaux », obligatoire pour devis et factures
#1339 (closed) )
Durée de validité du devis (cf- par défaut : obligatoire pour devis, « limite de validité du devis », absent avoir/facture
- voyage : renommé en « durée d'option »
#1804)
Participant·e·s (n'existe pas encore cf- par défaut : absent
- voyage : obligatoire devis & facture, renommé « voyageurs », absent avoirs
- formation : optionnel, renommé « stagiaires »
#1340 (comment 500303))
Date de premiere visite (une seconde date) (n'existe pas encore cf- par défaut : absent
- chantier : obligatoire
Champs spécifiques au voyage
Contre-exemple : « Devis » qui devient « bon de commande » et « bon pour accord » qui devient « bon pour travaux »
Dans la mesure où ça n'apparaît pas dans la zone de mentions du devis, on ne gère pas ça via les mentions mais via des champs
Autres ??
Implémentation
Une approche serait de reprendre et d'étendre le système de mentions réglables actuel.
Différences entre les règles de champs (le sujet de ce ticket) et réglage des mentions (implémenté actuellement)
- niveau formulaire+texte d'aide+PDF, les libellés rattachés à une mention sont les mêmes quel que soit le type d'affaire
- niveau formulaire, une mention est ON/OFF, on ne peut pas y saisir de données spécifiques au document (exemple : la date de validité du devis).
Étendre les mentions : déroulé d'implémentation
a. Champs associés
Permettre optionnellement d'associer une mention à un ou plusieurs champ du document (pour afficher ou non le champ dans le formulaire).
Les champs associés sont proposés dans une liste déroulante (<select>
). Cette liste est nécessairement finie, car il faut pour chaque champ :
- qu'il soit exposé dans le contexte de la template de mention
- qu'il bénéficie d'un rendu de son/ses champs de formulaire dans la vue d'édition, qui peut être complexe (me semble difficilement configurable).
b. Champ associé : formulaire
Que se passe-t-il côté formulaire (nb: vue FullJS + API) ?
Les champs associés sont de toutes façon ajoutés à l'API et éditables, l'enjeu au niveau du formulaire constitue juste à les afficher ou à les masquer (pas d'enjeu de sécu, aucun impact si quelqu'un·e parvient à remplir un champ normalement désactivé).
Concernant l'activation des mentions facultatives
- On garde la checkboxlistwidget pour activer ou non les mentions facultatives
-> ça ne change rien
Concernant les champs associés
Dans le code de rendu du formulaire, certains champs sont conditionnés aux mentions : on n'affiche leur champ d'édition que si une des mentions associée à ce champ est activée (càd : soit c'est une mention Obligatoire soit c'est une mention facultative ET activée via le CheckBoxListWidget
).
Les champs associés peuvent se situer dans la section « Plus d'options » ou ailleurs, selon ce qui est pertinent.
b. Injection de mentions côté PDF
On injecte toujours dans la même zone où les mentions sont actuellement injectées. C'est fourre-tout, mais au moins c'est relativement prédictible en terme de rendu. Le code de template mako ne change pas, puisque c'est simplement du contexte supplémentaire qui est fourni pour le rendu des templates de mentions.
Par contre il faut rajouter du contexte… Pour couvrir tous les cas dont on peut avoir besoin je pense qu'il suffirait d'ajouter au contexte actuel des mentions :
- la Task
- le business
Ce qui donne accès à tous leurs champs.
Points de vigilance
- Attention au Désactivation/changement des mentions pour l'existant.
-
Persistence : est-ce qu'on copie les valeurs de la mention dans la task ou est-ce qu'on les link (FK) ?non, on fait le rendu à la volée, comme c'est le cas actuellement avec les quelques variables à dispo (IBAN & cie). - Dans la conception, sans l'implémenter actuellement, essayer d'avoir quelque-chose que l'on pourra dans le futur transposer à des types de docs hors
Task
(ex NDD)