Quelque part dans mon document des fichiers-image sont téléchargés dans une colonne de type Pièce jointe. Ceci fonctionne bien, pas de souci! Mais je voudrais visualiser ces images en utilisant un Custom widget builder à l’intérieur d’une balise html IMAGE (Custom widget builder qui par ailleurs est une mini-application javascript ajoutant des annotations à l’image).
La solution je la connais, elle a (très bien) fonctionné jusqu’en juillet 2025.
On affecte à SRC de l’image l’url de la pièce jointe calculé par la formule ${baseUrl}/attachments/${ID}/download?auth=${token}
où ID identifie le fichier image souhaité et baseUrl+token sont renvoyés par grist.docApi.getAccessToken(…).then(response…) appelé après appel de grist.ready({ requiredAccess: ‹ full › }).
Tout cela a fonctionné parfaitement, mais maintenant j’ai l’erreur 403 qui dit que le serveur ne veut pas que je télécharge le fichier image. Il ne veut plus le bougre, bien que voulant bien auparavant!
Si quelqu’un-e a une idée, une piste, un soupçon de direction vers où chercher… je lui serais très reconnaissant car ça bloque toute l’application que je suis en train de finaliser, et qui fonctionnait parfaitement en juillet 2025 : application que j’ai présentée et qui a intéressé plus qu’énormément autour de moi tant verticalement (ma hiérarchie) qu’horizontalement (mes collègues proches ou éloignés).
S’est-il passé un changement dans le fontionnement d’autorisation du GRIST de la DINUM, ou l’erreur est-elle de mon côté?
Downloading them is already well-supported with grist.docApi.getAccessToken(), which gives a short lived token and works great for displaying images or files in a secure way.
Oui j’y ai pensé, mais c’est pas ça car justement le but de la fonction grist.docApi.getAccessToken() c’est de calculer le token et baseUrl quand on en a besoin. C’est dynamique, le token est pas déclaré statiquement et calculé 1 seul fois puis enregistré.
D’ailleurs c’est comme ça que c’était programmé avant juin dernier et ça fonctionnait sans problème. J’ai le même code c’est ça qui est dérangeant et me fait penser qu’à la DINUM ils ont « bougé » quelque chose.
Merci de l’idée quand même.
Yves Bélec, Rectorat de Toulouse.
PS : l’application que j’écris est importante et a fait son effet à la présentation.
Elle permet de construire pour chaque école de Haute-Garonne le document officiel PPMS Plan Particulier de Mise en Sécurité pour toutes les écoles.
Dedans on y met des photos (plan de l’école, vue satellite, etc.) dont certaines doivent être annotées de façon réglementaire. J’ai résolu tout ça en développant en javascript, dans un Custom widget Builder, un logiciel permettant d’annoter les photos et on récupère ces annotations dans le PPMS de l’école. Tout fonctionnait bien jusqu’au moment où plus moyen que les photos téléchargées s’affichent. Elles sont bien là pourtant car en allant dans la table qui les contient on les voit et quand on double clic dessus elles s’affichent en grand. J’y comprend rien.
Bonjour, je cherche à récupérer des URL de PJ pour les afficher dans une vue widget HTML et je serais preneuse d’une explication détaillée de votre façon de faire (même si pour le moment cela ne marche plus) - étant novice en programmation je ne pense pas pouvoir me baser sur votre code avec les informations fournies à l’heure actuelle. Si cela vous semble convenable bien sûr! Je reste bloquée à l’étape du token qui est temporaire et donc l’image s’affiche seulement quelques heures (et mon appel à l’API est manuel donc j’ai hâte de comprendre vos formules!). Pour essayer de faire avancer votre problématique, même si je suppose que vous avez déjà consulté les mises à jour de GRIST d’août, je vous renvoie tout de même cette capture d’écran à tout hasard.
La liste des mises à jour de la dernière version est disponible ici : Releases 1.7.x [Aout 2025]
Bon courage dans votre recherche de solution, votre application semble effectivement très prometteuse et je pense que d’autres académies (dont la mienne) s’en empareraient aussi avec joie.
Je viens d’upgrade un de mes widgets pour afficher des images à partir d’une colonne pièce-jointe, et ça marche so far, mais effectivement, j’ai pas exactement la même formule, peut-être qu’il y a eu une mise à jour de l’API, que sais-je, voilà ce que j’ai utilisé :
côté html (du Custom widget builder) on met : dans la balise pour charger la librairie
côté javascript on attaque par : grist.ready({ requiredAccess: ‹ full › });
ensuite (ou avant c’est pas important puisque c’est une fonction définie et pas encore appelée) on définit une fonction permettant de modifier l’attribut SRC de la balise qu’on a mise dans le html :
async function updateImageUrl(id_jpg_joint) {
// =============
try {
const tokenInfo = await grist.docApi.getAccessToken({ readOnly: true });
const url = ${tokenInfo.baseUrl}/attachments/${id_jpg_joint}/download?auth=${tokenInfo.token};
imageElt.src = url; // Set the URL as the image source
} catch (error) {
console.error(‹ Erreur accès attachement: ›, error);
}
}
enfin on appelle cette fonction en lui transmettant un entier = l’ID de la pièce jointe .jpg déposée quelque part dans une colonne Plan_ecole de type Pièce jointe de la table liée au Custom widget builder :
grist.onRecord(record => {
id_jpg_joint = record.Plan_ecole[0];
updateImageUrl(id_jpg_joint);
});
rq : on met [0] car ce champ Pièce jointe peut recevoir un nombre indéfini de pièces jointes qui sont record.Plan_ecole[0], …Plan_ecole[1] etc.
rq : on appelle dans le grist.onRecord(record => {} pour réagir au changement de ligne dans la table.
Voyez, c’est relativement simple.
Ben chez moi, ça fonctionne plus du tout mais une personne du forum (Amandine) m’a dit qu’avec elle ça gaze bien.
Allez y comprendre quelque chose.
Cordialement
attention! le widget personnalisé est un Custom widget builder permettant les styles et le javascript ce que ne peut pas faire l’autre widget html offert parmi les widgets personnalisés
Récupérer les liens pour les utiliser dans un template HTML (avec le widget HTML, pas cusom widget) est un cas d’usage tellement courant que j’ai créé un widget spécifique.