Les paramètres de requête sont excellents pour des raisons évidentes. Cependant, lorsque vous rendez les requêtes Data Explorer accessibles à des utilisateurs moins techniques, ils peuvent parfois être confus par le nom (même s’il ne s’agit que d’un nom de variable avec un trait de soulignement).
Pouvez-vous donner un alias à un paramètre de requête afin qu’il apparaisse avec un nom plus agréable sous la requête ?
Salut @jordan-violet 
Je pense qu’on peut faire quelque chose comme ça - Est-ce ce que tu veux dire ?
SELECT column_name AS alias_name
FROM table_name;
...
ou comme
SELECT column_name(s)
FROM table_name AS alias_name
....
Oh désolé, j’ai mal compris votre question ! Hmm 
Je pense que vous pouvez modifier la requête dans l’Explorateur de données et ajouter une description sur la façon de définir le paramètre. Elle s’affichera lors de l’exécution du rapport :
Oui, je l’ai maintenant, mais ce n’est tout simplement pas aussi soigné lorsque vous essayez de rendre ces rapports conviviaux pour des personnes très peu techniques dans des départements comme les ventes, le marketing, etc.
En fait, ce serait bien si cela allait plus loin et vous donnait également la possibilité de définir une description pour une info-bulle/une icône d’information.
DE est très brut… construire une interface utilisateur différente (qu’il s’agisse d’une page Web, d’une feuille de calcul ou d’une application) est probablement une bonne idée.
Un excellent exemple est Grafana !
Grafana propose une démo en direct de rapports sur sa communauté extraits de Data Explorer en temps réel.
Oui, nous utilisons Tableau dans notre entreprise et nous exportons toutes les données de Discourse afin qu’elles puissent y être utilisées.
Mais j’aime intégrer les utilisateurs, y compris en interne, à la plateforme. J’essaie toujours de promouvoir l’utilisation du moins d’outils possible et d’éviter une prolifération excessive.
Pour information, j’aime beaucoup cette idée. Je pense qu’avoir une « étiquette/placeholder conviviale » serait un bon ajout. Je ne suis pas sûr de la manière d’y parvenir cependant.
Tant d’options !
L’une des solutions les plus simples serait de vérifier une variable d’étiquette facultative dans le format actuel que vous utilisez tous, par exemple :
-- [params]
-- text :user_group
-- label: "Le nom du compte Salesforce du client que vous souhaitez rechercher dans cette requête."
-- text :topic_id
Je concède que je n’ai pas été un développeur à temps plein depuis plus de 5 ans et que je ne le suis plus maintenant, donc je ne peux pas prétendre connaître les spécificités de l’implémentation actuelle ni les complexités possibles de cette prochaine suggestion… mais ce serait génial si vous implémentiez Front Matter au début de la requête SQL. Front Matter peut être en yaml, toml, ou même json et est certainement plus joli que l’implémentation actuelle. Visuellement, il semble qu’il serait plus facile d’ajouter des options aussi, à mon avis. Une requête avec une implémentation théorique de Front Matter pourrait ressembler à ceci :
---
user_id:
description: "Le nom du compte Salesforce du client que vous souhaitez rechercher dans cette requête."
tooltip: "Obtenez ceci du compte Salesforce des utilisateurs, généralement associé à leur domaine de messagerie. Il doit s'agir d'une correspondance exacte."
topic_id:
description: "C'est l'ID du sujet que vous souhaitez examiner."
event_attendance_type:
default: 0
---
SELECT ue.user_id, u.name, u.title, ue.email
FROM discourse_post_event_invitees ei
JOIN posts p ON p.id = ei.post_id
JOIN user_emails as ue ON ue.user_id = ei.user_id
JOIN users as u on ei.user_id = u.id
WHERE p.topic_id = :topic_id
AND ei.status = 0