isn’t it better if this plugin be available for moderators as well?
currently only admins have access to the plugin, and mods get this error when clicking on the plugin: “The data explorer is only available to admins.”
moderators also need to be able to analysis some user behaviors, and direct access to the plugin helps.
This would give them complete read only access to your database. Not recommended in all cases I do not think
For example all they need to do is do
select * from api_keys
With that then they have access to the system & any admin generated API Keys allowing them to perform admin functions.
There is a whole discussion somewhere on meta about admins vs moderators, and how much trust to put in them. The discourse team all have admin privs here on meta, for example, as you can see on the about page. Personally I limit it (just two of us have admin privs) and then the two of us own the hassle of having to run reports and share them with the rest of the team. This is less than ideal - really we just limit the access to avoid having to train everyone on what to stay away from. Not everyone on my team is interested in seeing all the admin features, even if we do trust them with the data.
Can you give an example of the type of analysis moderators need to be allowed to do?
I’ve often wished for the ability to create a query, and then make just that query available to moderators. Or the ability to have the results of a query sent to me (or another discourse user) on a schedule, along the lines of the user export which is niftily delivered by PM.
I don’t know the ETA but AFAIK there are plans to expose Admin vetted queries to Moderators via the dashboard.
I am a moderator at SitePoint, not an admin, so I don’t have access to Data Explorer there. I do have access to Data Explorer on my localhost installs so I have some experience with what it is able to do.
Although the plugin has safety built in as far as protecting the database, it is very powerful in terms of what data it can provide. Some of which should, IMHO, not be available to any other than an admin. (eg. both personal and private information).
On the other hand, there have been a few times I have petitioned our admin to run a query for me and reply back with the results and he has gracefully obliged.
The new dashboard is currently planned for this release (Discourse Version 2.0). Of course that is always subject to change.
What I cannot confirm is if exposing Data Explorer queries is planned for the first release of the new dashboard, or if it will wait until a later improvement pass.
for data analysis, we have a colleague who needs to have access to the user data. he is currently playing with the data to see if he can extract patterns for “topic-user” and “user-user” interactions.
we can user “localhost” or “admin access” in this case as mentioned above, but I was wondering what will happen if moderators have access to the plugin as well. since they already have access to users information in the user section of admin panel.
The plan is for some queries to be marked safe as runnable by staff, but not to expose all of data explorer proper.
Any chance we can mark queries that we make to be exposed to moderators? I’ve been working on a few things on SP that I wouldn’t mind exposing the data of, as it is meant for their eyes, right now I export/copy it to a topic, which requires manual effort.
Yes, that is the plan!
Quel est l’état actuel de l’activation de cette fonctionnalité ? J’ai trouvé ce fil de discussion après avoir découvert que seuls les administrateurs pouvaient exécuter les requêtes. Avoir accès à quelques requêtes approuvées par les administrateurs serait formidable pour certains travaux que nous menons sur notre forum.
Merci.
Il y a une plus grande fonctionnalité que je préférerais développer ici. Elle figure dans ma liste de souhaits, mais n’est pas encore planifiée.
J’aimerais qu’il soit possible d’autoriser l’exécution d’une requête pour n’importe quel groupe. La création resterait une fonctionnalité réservée aux administrateurs, je ne souhaite jamais changer cela. En revanche, l’exécution pourrait être ouverte à n’importe quel groupe.
Cela débloque toutes sortes de possibilités, comme la capacité d’ajouter des rapports personnalisés à notre tableau de bord de modération, quelque chose qui intéresse @j.jaffeux depuis un moment.
Si des membres de la communauté sont intéressés par ce type de projet, veuillez publier des captures d’écran de maquettes montrant comment l’expérience utilisateur fonctionnerait : comment accorder l’autorisation d’exécution pour un rapport donné à un groupe ? Où cela apparaîtrait-il ? Et ainsi de suite…
J’aimerais beaucoup essayer cette fonctionnalité. J’ai préparé quelques captures d’écran de ma maquette.
La première capture d’écran montre la vue d’édition d’un rapport. Les administrateurs peuvent ajouter des groupes pour leur donner accès au téléchargement des résultats du rapport.
La plus grande question pour moi est de savoir comment présenter les rapports aux utilisateurs au sein d’un groupe. Ma première idée était d’afficher uniquement les boutons JSON et CSV aux utilisateurs non administrateurs, ce qui lancerait le rapport s’il n’a pas encore été exécuté, mais empêcherait un utilisateur non administrateur d’exécuter une requête de manière répétée.
@sam Fais-moi savoir ce que tu penses de cette approche. (Je ne peux poster qu’une seule image par message, je posterai donc l’autre image dans un message suivant)
Voici l’autre capture d’écran. Cet onglet serait bien sûr disponible uniquement pour les membres du groupe. -
Je pense que vous souhaitez permettre aux membres du groupe d’accéder au bouton Exécuter.
Voici pourquoi : si vous ne pouvez pas faire confiance aux utilisateurs pour qu’ils n’essaient pas de désactiver le site en relançant la requête, alors vous ne devriez pas les ajouter au groupe. La plupart du temps, les requêtes de l’explorateur de données sont utiles dans l’expérience utilisateur, et non pour les télécharger puis les examiner dans un autre outil. De plus, l’affichage fait de belles choses (comme afficher user_id et topic_id de manière utile, ce qui est difficile à reproduire si vous téléchargez les données.
Cela a du sens. La fonctionnalité d’exécution refléterait simplement ce que les administrateurs voient lorsqu’ils appuient sur run, les résultats étant affichés ci-dessous.
Serait-il utile d’afficher également l’heure de la dernière exécution au groupe ?
J’aime vraiment que vous ayez trouvé une place naturelle pour cela dans les groupes, mais je pense que nous devrions avoir un onglet dédié sur la page des groupes, car je ne pense pas que cela s’intègre bien dans l’activité.
Peut-être entre « Messages » et « Gérer » : si vous avez un ou plusieurs rapports (et que vous êtes un membre explicite du groupe), l’onglet apparaît.
Cela vous donne également un peu plus de largeur pour travailler.
Les personnes ayant accès à un rapport devraient pouvoir « ajouter des paramètres » s’il s’agit d’un rapport paramétrable et l’exécuter avec les mêmes contrôles que ceux dont nous disposons sur l’administration. Je suis indécis quant à savoir s’ils devraient voir le SQL, donc disons non pour l’instant.
Concernant l’emplacement des permissions : je préférerais que cela soit moins intrusif sur la page d’administration. Je suppose que nous pouvons commencer par là, mais avec moins de texte.
Je dis, n’hésitez pas à commencer si tous ces retours ont du sens !
Merci pour ces bons retours. Tout cela a du sens pour moi, et je vais commencer à m’en occuper.
@sam ,
Les requêtes par défaut (déjà présentes lors de l’installation du plugin) ne sont pas modifiables.
Dans mes captures d’écran, la possibilité d’exposer une requête à un groupe s’effectue via l’édition de la requête. Les requêtes par défaut devraient-elles également être exposables aux groupes ?
Si oui, je pense que la conception devra peut-être être légèrement modifiée pour prendre en compte les deux types de requêtes.
Oui, je pense que les métadonnées relatives à la requête, telles que la date de sa dernière exécution, les personnes autorisées à l’exécuter, etc., devraient figurer dans une table dédiée. Vous devriez également pouvoir définir les autorisations pour les requêtes intégrées (qui disposent d’identifiants stables).
Je souhaite partager ce que j’ai réalisé et obtenir des retours.
Voici des captures d’écran illustrant le processus, depuis l’index de l’administrateur des requêtes, en passant par l’ajout d’un groupe, jusqu’à l’affichage de la requête côté non-administrateur.
