Ce modèle permet de recenser les souscriptions des collectivités (communes, agences, CCAS…) aux prestations fournies par les centres de gestion dont leur territoire dépend. Il permet également de générer des courriers à envoyer par voie postale en fonction de la prestation concernée.
Retrouvez la dernière version du modèle sur le dépôt Git ci-dessous :
Bonjour à toustes !
Un CDG que nous accompagnons à Open Source Politics voudrait migrer son publipostage de Word vers un document Grist. En s’inspirant du modèle de publipostage d’@audezu (Template Grist : Factures personnalisées), nous avons donc bricolé cette solution à base de HTML et de CSS, qui s’avèrent tout à fait adaptés à formater des pages pour l’impression (si le sujet vous intéresse, je vous renvoie à cette page de l’excellent site de Julien Bidoret).
Ce modèle Grist est cependant encore fragile : il nous a fallu utiliser des widgets Markdown qui ne sont pas vraiment faits pour éditer du code, et ce dernier aurait certainement besoin d’être factorisé avant qu’on ne s’amuse à créer une multitude de types de courrier aux en-têtes identiques. C’est pourquoi, là encore, vos contributions sont plus que bienvenues ! Si vous travaillez vous-même au sein d’un CDG, votre expertise sera précieuse pour nous aider à définir les prestations communes à ces organismes.
il nous a fallu utiliser des widgets Markdown qui ne sont pas vraiment faits pour éditer du code
Est-ce que tu pourrais détailler stp pourquoi vous devez utiliser du code dans le widget markdown, et ce qui bloque ?
Et je ne sais pas si tu as vu, mais le modèle de publipostage dispo sur les instances DINUM et ANCT permet de gérer plusieurs modèles de lettres (merci @vincent.viers !):
Est-ce que tu pourrais détailler stp pourquoi vous devez utiliser du code dans le widget markdown, et ce qui bloque ?
À la base, c’était pour faire pareil que sur le modèle de Vincent : utiliser une vue Markdown pour avoir un aperçu HTML (en principe, la vue HTML dédiée aurait dû suffire, mais elle était buguée à l’époque).
Mais dans notre cas, les choses sont un peu différentes : on a mis le CSS dans une case à part, du coup la vue Markdown n’affiche plus un aperçu fidèle du rendu final (ce qui a priori ne me dérange pas trop, car de mon point de vue, c’est l’aperçu avant impression qui doit faire foi). De fait, elle sert plutôt à éditer le contenu de la case qui contient le code HTML, et donc de masquer la colonne « code HTML » qui, lorsqu’elle est affichée, augmente considérablement la hauteur des lignes du tableau et rend son usage inconfortable. Pour ça, le bouton « Edit » de la vue est parfait, mais une fois dedans, le risque est que l’utilisateurice se mette à utiliser les boutons de mise en forme (gras, italique, etc) et à injecter du Markdown alors qu’il n’en faut pas ici.
On envisage de faire une vue custom « éditeur de texte brut », sans boutons de mise en forme (peut-être basée sur browserpad ?) qui permettrait d’éditer le HTML et le CSS sans ambiguïté, et qui viendrait donc remplacer les vues Markdown.
