Development #13973
Permettre la construction d'indicateurs personnalisés multi-formulaires
0%
Description
Ça va être important pour Nancy mais sans doute ailleurs. J'ai une dizaine de formulaires qui vont avoir une variable de traitement "quartier" qui apparaît dans la liste déroulante "Regroupements" quand je les prends individuellement. Mais je voudrais faire un indicateur pour l'ensemble de ces 10 formulaires. Or en passant par "tous les formulaires", même si je sélectionne les formulaires en question, j'ai pas "quartier" dans la liste déroulante des regroupements.
(11:51:05) bdauvergne@im.libre-entreprise.com: il faudrait écrire un modèle pour bijoe pour lui expliquer que ces 10 formulaires ont ce champs en commun et qu'on peut donc s'en servir pour les indexer tous (en fait il faudrait faire d'abord une vue SQL union des 10 tables des formulaires puis écrire de la conf JSON à la main pour bijoe). En gros il faudrait arriver à décrire quelque part que des formulaires ont des champs dont la sémantique est commune et à partir de cette information générer ce qu'il faut au niveau de la construction de la base BI par wcs-olap et de la config de bi-joe.
(11:54:46) pcros@im.libre-entreprise.com/23403287631479199901952315: ET on peut pas se baser juste sur un élément dans le nom de variable du champs pour ça, genre le fait d'ajouter un "common" dans le nom de variable ? Ça voudrait dire que tous les champs qui ont ce "common" apparaissent dans la fameuse liste déroulante mais ça en fera jamais des caisses
(11:55:48) bdauvergne@im.libre-entreprise.com: ça pourrait mais faut aussir s'assurer que les données collent, ex. qu'on a la même liste de quartiers dans tous. c'est bien si le champ est un champ item avec la même source de donnée.
Cette dernière règle on peut l'imposer aux concepteurs de démarches, oui.
Historique
Mis à jour par Benjamin Dauvergne il y a environ 7 ans
- Statut changé de Nouveau à Rejeté
Piste abandonnée pour un stockage non structuré en JSON (type elastic search).