nossa empresa utiliza o Discourse para dar suporte aos nossos clientes e fortalecer o relacionamento com eles. Para o onboarding de funcionários, criamos documentação usando Categorias de Documentos e DiscoTOC, o que funciona muito bem.
No entanto, gostaria de solicitar um recurso que permita exportar as fontes da documentação – especificamente o texto bruto incluindo marcação – para um arquivo de texto simples.
Estou ciente da opção de impressão em PDF do navegador, que não ajuda quando fontes brutas são necessárias em vez de fontes analisadas. Também sei sobre a função de backup integrada e as consultas ao banco de dados, mas estas não são soluções práticas para administração de frontend.
Por enquanto, meu fluxo de trabalho é: Editar a postagem → STRG-A, STRG-C → criar / abrir um arquivo de texto → STRG-V, STRG-S → Descartar Edição… próxima postagem.
Uma opção de exportação em massa integrada proporcionaria vários benefícios:
manutenção muito mais fácil para bases de conhecimento
melhores fluxos de trabalho de backup e versionamento para administradores no frontend
reutilização flexível de conteúdo fora do Discourse
Tal recurso seria um ganho real de produtividade para comunidades que usam o Discourse como um centro de documentação, não apenas para suporte.
Isso é bem fácil de automatizar com algumas ferramentas de linha de comando. Uma inteligente obteria o json do tópico para ver quantas postagens havia e então as obteria todas, talvez pausando para lidar com limites de taxa.
Um componente de tema poderia fornecer links para o texto bruto de cada postagem. Um plugin poderia fazer o que você quer.
Obrigado pela dica, Richard Vou dar uma olhada no Data Explorer e nas chamadas de API quando tiver uma chance. Ainda assim, isso é apenas um “gancho”, não um recurso.
Pegue o plugin Doc Categories como exemplo: para construir documentação, tudo o que você tecnicamente precisa é de um post de índice contendo os links para todos os tópicos. Mas o plugin adiciona algo extra: navegação automática de página.
É exatamente o tipo de solicitação de recurso que estou fazendo: uma funcionalidade adicional que ajuda usuários regulares – não apenas outra solução alternativa para usuários avançados ou pessoal de TI.
Se eu estivesse desejando tal recurso, gostaria que ele me fornecesse um arquivo zip contendo todas as fontes markdown referenciadas pelo índice do documento.
Como os arquivos individuais deveriam ser nomeados nesse caso?
Você poderia descrever seu fluxo de trabalho pretendido com mais detalhes?
Se eu fosse construir um fluxo de trabalho de documentação como você descreve, eu preferiria criar uma opção para montar markdown bruto no sistema de arquivos, o que permitiria que outras ferramentas automatizadas trabalhassem nele.
Eu não entendo este ponto.
Por que você não quer apresentar sua documentação via Discourse?
Olá Thomas, um contêiner zip funcionaria perfeitamente, é claro Não há um fluxo de trabalho por trás disso, apenas o desejo de manter um backup simples.
Talvez você possa me dar um bom exemplo em vez de responder com um ad hominem. Até mesmo sua postagem inicial fala sobre administradores e pessoas que gerenciam bases de conhecimento.
Desculpe, você compartilhou suas opiniões pessoais e eu estava apenas respondendo – nenhuma ofensa pretendida.
Por exemplo, pessoas que gerenciam bases de conhecimento, como gerentes de conhecimento que criam conteúdo como administradores, mas têm histórico técnico limitado, querem lidar com seu conteúdo sozinhas e poder fazer backup dele localmente.
Sua solicitação de recurso parece interessante! Acho ótimo ter este tópico disponível para que outras pessoas com uma configuração semelhante possam contribuir. Talvez eventualmente algo assim chegue à interface do usuário. Mas acho que você ainda não apresentou um argumento para que seja um recurso amplamente útil.
Você é novo aqui, então deixe-me explicar algumas coisas que podem não ser óbvias para você. Adicionar recursos leva tempo e recursos, então, normalmente, novos recursos são adicionados ao Discourse quando um de nossos clientes corporativos os solicita ou quando há muita demanda por eles, por exemplo, regra de três. Eles também costumam começar como plugins ou componentes antes de eventualmente chegarem ao nosso produto principal.
Para muitos casos únicos, a API do Discourse e o explorador de dados fornecem soluções rápidas e “suficientes”. Reconheço que não é o que você está pedindo aqui! Mas, às vezes, tentar resolver um problema usando a API ou uma consulta do explorador de dados pode ajudar a justificar a adição de funcionalidades ou a encontrar uma maneira melhor de resolver um problema específico.
Você já viu como as consultas do explorador de dados podem ser disponibilizadas para grupos e ter uma interface para especificar parâmetros? Isso é adequado para “usuários regulares” e pode funcionar para você e sua equipe como uma solução temporária e para ajudá-lo a defender sua nova ideia de recurso aqui. Não sei se já existe uma consulta adequada para você começar - o lugar para procurar é Data & reporting.
@rgj Acho que você é um cara normal, não importa o que mais alguém diga!
Obrigado pelas boas-vindas, pelos esclarecimentos e pelas dicas, Tobias.
Não tenho tanta certeza sobre recursos amplamente utilizados – existem muitas opções e configurações no Discourse em que me perguntei: “quem em sã consciência precisa disso?”
As pessoas tendem a usar as ferramentas que estão disponíveis e são familiares. Se você já tem um martelo, pode se perguntar para que serve uma marreta.
Talvez outros usuários vejam um caso de uso para o recurso proposto e participem da discussão.
Estou ciente da opção de impressão em PDF do navegador, que não ajuda quando fontes brutas são necessárias em vez de fontes analisadas. Também sei sobre a função de backup integrada e as consultas ao banco de dados, mas estas não são soluções práticas para administração de frontend.
Tal recurso seria um ganho real de produtividade para comunidades que usam o Discourse como um centro de documentação, não apenas para suporte.
Vou dar uma olhada no 
