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.
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.
Qual é o status atual da ativação desse recurso? Encontrei esse tópico depois de descobrir que apenas administradores podem executar as consultas. Ter acesso a algumas consultas aprovadas por administradores seria fantástico para parte do trabalho que estamos fazendo no nosso fórum.
Há uma parte maior que acredito que preferiria construir aqui. Ela está na minha lista de desejos, mas ainda não foi agendada.
Gostaria que fosse permitido “expor” a execução de uma consulta para um grupo arbitrário. A criação continuaria sendo algo apenas para administradores, pois não pretendo mudar isso. Mas a execução… pode ser feita por qualquer grupo.
Isso libera diversas possibilidades, como a capacidade de adicionar relatórios personalizados ao nosso painel de mods, algo que @j.jaffeux tem demonstrado interesse há algum tempo.
Se alguém da comunidade estiver interessado nesse tipo de projeto, por favor, poste algumas capturas de tela de mockups mostrando como a UX funcionaria, como você “concederia permissão de execução” para um relatório específico a um grupo. Onde você veria isso? E assim por diante…
Adoraria tentar implementar esse recurso. Preparei algumas capturas de tela do meu mockup.
A primeira captura de tela mostra a visão de edição de um relatório. O administrador pode adicionar grupos para ter acesso ao download dos resultados do relatório.
A maior dúvida para mim é como apresentar os relatórios aos usuários dentro de um grupo. Minha ideia inicial era mostrar apenas os botões JSON e CSV para usuários não administradores, o que executaria o relatório se ele ainda não tivesse sido executado, mas impediria que um usuário não administrador executasse uma consulta repetidamente.
@sam, deixe-me saber o que você acha dessa direção. (Posso postar apenas 1 imagem por post, então vou postar a outra imagem em um post seguinte)
Acho que você quer permitir que os membros do grupo tenham acesso ao botão Executar.
Eis o motivo: se você não pode confiar nos usuários para não tentarem desativar o site reexecutando a consulta, então você não deve adicioná-los ao grupo. Na maioria das vezes, as consultas do Explorador de Dados são úteis na UX, não para baixar e depois analisar em outra ferramenta. Além disso, a exibição faz Coisas Ótimas (como exibir user_id e topic_id de maneiras úteis que são difíceis de replicar se você baixar os dados.
Isso faz sentido. A funcionalidade de execução simplesmente espelharia o que os administradores veem ao pressionar run, com os resultados sendo exibidos abaixo.
Seria útil exibir também o horário da última execução para o grupo?
Gosto muito de como você encontrou um lugar natural para isso nos grupos. No entanto, acho que deveríamos ter uma aba dedicada na página dos grupos, pois não creio que isso se encaixe em “Atividade”.
Talvez entre “Mensagens” e “Gerenciar”: se houver 1 ou mais relatórios (e você for um membro explícito do grupo), a aba aparecerá.
Isso também oferece um pouco mais de largura para trabalhar.
Pessoas com acesso a um relatório devem poder “adicionar parâmetros” se for um relatório parametrizado e executá-lo com os mesmos controles que temos no admin. Estou em dúvida se elas devem ver o SQL, então por enquanto acho que não.
Sobre onde colocar as permissões: prefiro que seja menos intrusivo na página de admin. Acho que podemos começar por lá, mas com menos texto.
Dito isso, fique à vontade para começar se todo esse feedback fizer sentido!
As consultas padrão (já presentes quando o plugin é instalado) não são editáveis.
Nas minhas capturas de tela, a capacidade de expor uma consulta a um grupo é acessada por meio da edição da consulta. As consultas padrão também devem ser expostas a grupos?
Se sim, estou pensando que o design pode precisar mudar um pouco para acomodar ambos os tipos de consulta.
Sim, acho que metadados sobre a consulta, como quando foi executada pela última vez, quem tem permissão para executá-la etc., devem estar em uma tabela dedicada. Você também deve poder definir permissões para consultas integradas (elas possuem IDs estáveis).
Gostaria de compartilhar o que fiz e receber algum feedback.
Aqui estão capturas de tela funcionando a partir do índice de administração de consultas, adicionando um grupo e, em seguida, visualizando a consulta do lado não administrador.