Isto é como um tópico de #recurso - #desenvolvimento, não tenho certeza em qual deveria estar.
Existe uma maneira de modificar as configurações do site em um plugin? Tenho 99% de certeza que não, mas gostaria apenas de confirmar.
Se não houver, posso apresentar uma sugestão para não torná-la imutável? Ou talvez, ter alguma API ou uma maneira de ‘desbloquear’ a propriedade imutável de SiteSettings?
Um possível caso de uso que estou analisando é incluir uma lista de categorias protegidas em uma configuração, de modo que seja mais fácil para o administrador incluí-las/excluí-las.
[quote=“NateDhaliwal, post:1, topic:389676”]Um caso de uso possível que estou analisando é incluir uma lista de categorias protegidas em uma configuração, de modo que seja mais fácil para o administrador incluí-las/excluí-las.
[/quote]
Vamos começar por aqui e trabalhar de fora para dentro.
Você pode primeiro descrever o caso de uso do ponto de vista da comunidade? O que eles estão tentando realizar e o que torna isso difícil de fazer agora? Qual recurso você imagina que resolveria a necessidade deles de forma mais eficaz (independentemente de como seja implementado)?
Então, podemos prosseguir a partir daí para determinar se isso é melhor feito em um plugin ou como um recurso principal.
Então, podemos prosseguir a partir daí para discutir sugestões sobre como implementá-lo.
Eu presumi erroneamente que, como as configurações são imutáveis em TCs, elas também o são em plugins em Ruby. Vou tentar isso.
Seria bom torná-las editáveis em TCs. Meu caso de uso (para o qual estou usando um plugin no momento) é que eu pego todos os tópicos e postagens em todas as categorias por padrão e faço algumas coisas com eles, mas não gostaria de incluir categorias protegidas (como uma configuração excluded_categories).
No entanto, se fosse possível adicionar categorias protegidas à configuração e acessá-la depois, seria mais fácil. Desta forma, os administradores podem incluir algumas categorias protegidas, se quiserem, removendo-as da configuração.
Com a ideia do @pfaffman, provavelmente pode ser feito, mas não em TCs.
O problema com isso é que eu não sei as categorias protegidas de antemão.
Se você estiver logado como administrador, um componente de tema pode alterar siteSettings via API.
Então, basta criar uma configuração de componente de tema e adicionar essas categorias? Você não está se referindo a alguma configuração de site protected_categories que eu não estou lembrando, está? Então, algo como isto?
Eu adoraria saber mais. Acho que isso me ajudaria a colocar esta solicitação em um contexto melhor.
Você está disposto a compartilhar mais sobre sua comunidade?
Você é o principal usuário deste recurso ou há outras pessoas em sua equipe que precisam dele? Você tem documentação voltada para o usuário para o fluxo de trabalho que depende desse recurso? Se sim, como ela se parece? Se não, você pode descrever brevemente como ela poderia ser?
Estou desenvolvendo um plugin que pega tópicos e posts e os publica no GitHub como arquivos Markdown (como um arquivo).
No entanto, eu não gostaria de incluir categorias privadas (acho que agora esse é o termo correto?) nisso, já que elas são ‘privadas’.
Portanto, estou procurando uma maneira de pré-preencher uma configuração com a lista de categorias privadas, que não pode ser definida no parâmetro default, já que eu não saberia quais são as categorias privadas com antecedência.
No caso de isso poder ser feito alterando diretamente SiteSetting em Ruby, o mesmo pode ser feito com as settings de um Componente de Tema? Tenho quase certeza de que este último é imutável. Existe alguma maneira de alterá-lo em um Componente de Tema?
Não se trata realmente da comunidade. Estou tentando isto (com um trabalho de preenchimento também) do meu próprio jeito. Isso salva cada tópico e postagem como um arquivo Markdown em um repositório.
Eu ainda não sei o que privado significa para você. Significa que você quer apenas categorias que sejam visíveis para todos, ou para usuários anônimos? Ou você tem alguma outra definição.
Se você quer essas, então seu plugin pode obter apenas essas, talvez por uma busca na qual você passa um usuário (ou talvez chamando um guardião), ou apenas verificando as permissões.
Ou se privado é algo que é uma opinião, então você pode adicionar uma configuração.
E você provavelmente quer fazer isso em um trabalho que é executado diariamente ou o que for?
Se você está enviando coisas para o github, eu pensaria que você gostaria que o discourse fizesse isso em vez de se incomodar em fazer seu navegador enviar dados para o discourse? Eu não vejo como ou por que você faria isso com um componente de tema.
Quero dizer categorias como Staff, e outras que são limitadas por grupos. Eu acho que é possível com um plugin, mas suponho que as configurações do TC não possam ser mutáveis então?
Estou correto ao entender que você está se referindo ao método Category.where(...) para obter essas categorias “privadas”? Mas e se o administrador quiser incluir (algumas) delas - eu preciso ter uma configuração include categories que anule as categorias “privadas” definidas no código? Isso não seria contraproducente?
Eu ainda não entendo isso. Sim, você pode adicionar essas configurações em uma SiteSetting e sim, o plugin poderia ler essa configuração e até mesmo alterá-la. Mas por que ele precisaria alterar a configuração dado o cenário acima?
Supondo que eu tenha 5 categorias: A, B, C, D e E. Agora, digamos que B e C só estão disponíveis para alguns grupos. Para evitar que tópicos privados sejam compartilhados ao serem enviados para o repositório, B e C são adicionados à configuração excluded_categories, juntamente com outros como, digamos, Staff.
Agora, supondo que o administrador do site concorde que os tópicos de B sejam compartilhados, ele pode remover B da configuração, mantendo C lá.
Portanto, o excluded_categories teria que ser alterado no início para adicionar as categorias “privadas” B e C. Não tenho certeza se isso faz sentido?
Embora isso seja perfeitamente possível do ponto de vista técnico, acho que a abordagem seria excessivamente complicada, especialmente porque “no início” é difícil de definir/detectar, e você quer evitar que o plugin continue adicionando B depois que o administrador do site o removeu. Além disso, quando uma nova categoria privada é adicionada, o plugin precisaria adicioná-la, mas precisaria ser capaz de ver a diferença entre uma nova categoria (adicionar) e uma categoria que foi removida anteriormente pelo administrador (não adicionar novamente).
Eu optaria por uma configuração include_private_categories que começa vazia, e o plugin simplesmente processaria todas as categorias públicas E as categorias em include_private_categories. Isso lhe dará muito menos dores de cabeça.
Uma outra alternativa de design que eu poderia imaginar aqui é ter dois repositórios separados: um para conteúdo público e outro para conteúdo privado.
O repositório de conteúdo privado em si poderia ser mantido privado (você poderia determinar quem tem acesso a ele de forma independente).