Ceci ressemble à un sujet de #fonctionnalité - #développement, je ne suis pas sûr de l’endroit où il devrait se trouver.
Y a-t-il un moyen de modifier les paramètres du site dans un plugin ? Je suis sûr à 99 % que non, mais j’aimerais juste le confirmer.
S’il n’y en a pas, puis-je proposer une suggestion pour ne pas le rendre immuable ? Ou peut-être, avoir une API ou un moyen de « déverrouiller » la propriété immuable de SiteSettings ?
Un cas d’utilisation possible que j’envisage est d’inclure une liste de catégories protégées dans un paramètre afin qu’il soit plus facile pour l’administrateur de les inclure/exclure.
Voulez-vous simplement changer la valeur des paramètres du site ? Faites simplement SiteSetting.whatever='new value. Ou voulez-vous changer quelque chose à leur sujet ?
Ne voulez-vous pas simplement ajouter un paramètre pour cela ? Ajoutez-le simplement à config/settings.yml ? quelque chose comme
[quote=“NateDhaliwal, post:1, topic:389676”]Un cas d’utilisation possible que j’envisage est d’inclure une liste de catégories protégées dans un paramètre afin qu’il soit plus facile pour l’administrateur de les inclure/exclure.
[/quote]
Commençons par là et travaillons de l’extérieur vers l’intérieur.
Pouvez-vous d’abord décrire le cas d’utilisation du point de vue de la communauté ? Qu’essaient-ils d’accomplir et qu’est-ce qui rend cela difficile à faire actuellement ? Quelle fonctionnalité imaginez-vous résoudre leur besoin plus efficacement (indépendamment de la manière dont elle est implémentée) ?
Ensuite, nous pourrons déterminer si cela doit être fait de préférence dans un plugin ou comme fonctionnalité de base.
Ensuite, nous pourrons discuter des suggestions sur la manière de l’implémenter.
J’avais supposé à tort que puisque les paramètres sont immuables dans les TC, ils le sont aussi dans les plugins en Ruby. Je vais essayer ça.
Il serait bon de les rendre modifiables dans les TC. Mon cas d’utilisation (pour lequel j’utilise actuellement un plugin) est que je prends tous les sujets et messages dans toutes les catégories par défaut et que je fais certaines choses avec eux, mais je ne voudrais pas inclure les catégories protégées (comme un paramètre excluded_categories).
Cependant, s’il était possible d’ajouter des catégories protégées au paramètre, puis d’y accéder par la suite, ce serait plus facile. De cette façon, les administrateurs peuvent inclure certaines catégories protégées s’ils le souhaitent en les supprimant du paramètre.
Avec l’idée de @pfaffman, cela pourrait probablement être fait, mais pas dans les TC.
Le problème avec cela est que je ne connais pas les catégories protégées à l’avance.
Si vous êtes connecté en tant qu’administrateur, un composant de thème pourrait modifier les siteSettings via l’API.
Alors, créez simplement un paramètre de composant de thème et ajoutez ces catégories ? Vous ne faites pas référence à un paramètre de site protected_categories auquel je ne pense pas, n’est-ce pas ? Donc quelque chose comme ceci ?
J’aimerais en savoir plus. Je pense que cela m’aiderait à mieux contextualiser cette demande.
Êtes-vous prêt à partager plus d’informations sur votre communauté ?
Êtes-vous l’utilisateur principal de cette fonctionnalité ou d’autres membres de votre équipe en ont-ils besoin ? Avez-vous une documentation destinée aux utilisateurs pour le flux de travail qui dépend de cette fonctionnalité ? Si oui, à quoi ressemble-t-elle ? Sinon, pouvez-vous décrire brièvement à quoi elle pourrait ressembler ?
@mcwumbly@pfaffman D’accord, laissez-moi essayer d’expliquer cela autant que possible.
Je développe un plugin qui prend des sujets et des messages et les publie sur GitHub sous forme de fichiers Markdown (comme une archive).
Cependant, je ne voudrais pas inclure les catégories privées (je pense que c’est le terme correct maintenant ?) là-dedans, puisqu’elles sont « privées ».
Par conséquent, je cherche un moyen de pré-remplir un paramètre avec la liste des catégories privées, ce qui ne peut pas être défini dans le paramètre default, car je ne connaîtrais pas les catégories privées à l’avance.
Dans l’éventualité où cela peut être fait en modifiant directement SiteSetting en Ruby, peut-on faire de même avec les settings d’un Composant de Thème ? Je suis presque certain que ce dernier est immuable. Y a-t-il un moyen de le modifier dans un Composant de Thème ?
Ce n’est pas vraiment une question de communauté. J’essaie à ma manière ceci (avec également un travail de remplissage). Cela enregistre chaque sujet et chaque message sous forme de fichier Markdown dans un dépôt.
Je ne sais toujours pas ce que signifie « privé » pour vous. Voulez-vous dire que vous ne voulez que les catégories visibles par tout le monde, ou par les utilisateurs anonymes ? Ou avez-vous une autre définition ?
Si vous voulez celles-là, alors votre plugin peut obtenir uniquement celles-ci, peut-être par une recherche à laquelle vous passez un utilisateur (ou peut-être en appelant un gardien), ou simplement en vérifiant les permissions.
Ou si « privé » est une opinion, vous pouvez ajouter un paramètre.
Et vous voulez probablement faire cela dans une tâche qui s’exécute quotidiennement ou autre ?
Si vous envoyez des choses sur GitHub, je penserais que vous voudriez que Discourse le fasse lui-même plutôt que de vous embêter à faire en sorte que votre navigateur pousse des données vers Discourse ? Je ne vois pas comment ni pourquoi vous feriez cela avec un composant de thème.
Je veux dire des catégories comme Staff, et d’autres qui sont limitées par des groupes. Je pense que c’est possible avec un plugin, mais je suppose que les paramètres de TC ne peuvent pas être modifiables alors ?
Encore une fois, je pense que plus vous aborderez cela du point de vue du résultat final sur lequel vous travaillez, plus il sera facile de vous conseiller.
Donc merci d’avoir partagé ce lien :
Peut-être pouvons-nous l’utiliser comme point de départ pour clarifier davantage la spécification fonctionnelle que vous avez implicitement définie jusqu’à présent.
La façon dont je comprends cela maintenant est que vous souhaitez :
créer une archive html statique d’un site Discourse
la maintenir à jour à mesure que de nouveaux contenus sont créés
exclure certaines catégories
Et la conception que vous explorez actuellement est :
créer un plugin qui :
permet aux administrateurs de :
configurer explicitement les catégories à exclure
configurer une URL git pour stocker le contenu statique
exécute une tâche de fond périodiquement qui :
crée des fichiers markdown pour les sujets et les messages
les stocke dans une certaine structure de fichiers/dossiers dans un dépôt git
pousse cela vers GitHub
les utilisateurs finaux peuvent voir le contenu sur GitHub sous forme de html
Ai-je bien compris que vous faites référence à la méthode Category.where(...) pour obtenir ces catégories « privées » ? Mais que se passe-t-il si l’administrateur souhaite inclure (certaines d’)entre elles - dois-je avoir un paramètre include categories qui annule les catégories « privées » définies dans le code ? Cela ne serait-il pas contre-productif ?
Je ne comprends toujours pas cela. Oui, vous pouvez ajouter ces paramètres dans un SiteSetting et oui, le plugin pourrait lire ce paramètre, et même le modifier. Mais pourquoi aurait-il besoin de modifier le paramètre étant donné le scénario ci-dessus ?
En supposant que j’ai 5 catégories : A, B, C, D et E. Disons maintenant que B et C ne sont disponibles que pour certains groupes. Pour empêcher que les sujets privés ici ne soient partagés lors du téléchargement sur le dépôt, B et C sont ajoutés au paramètre excluded_categories, ainsi que d’autres comme Staff.
Maintenant, supposons que l’administrateur du site est d’accord pour que les sujets de B soient partagés, il peut supprimer B du paramètre, tout en laissant C.
Ainsi, excluded_categories devrait être modifié au départ pour ajouter les catégories « privées » B et C. Je ne suis pas sûr si cela a du sens ?
Bien que ce soit tout à fait possible d’un point de vue technique, je pense que l’approche serait trop compliquée, surtout parce que « au début » est difficile à définir/détecter, et vous voulez éviter que le plugin ne continue d’ajouter B après que l’administrateur du site l’ait supprimé. De plus, lorsqu’une nouvelle catégorie privée est ajoutée, le plugin devrait l’ajouter, mais il devrait être capable de voir la différence entre une nouvelle catégorie (ajouter) et une catégorie qui a été précédemment supprimée par l’administrateur (ne pas réajouter).
Je choisirais une option include_private_categories qui commence vide, et le plugin traiterait simplement toutes les catégories publiques, AINSI que les catégories dans include_private_categories. Cela vous évitera bien des maux de tête.
Une autre conception alternative que je pourrais imaginer ici serait d’avoir deux dépôts séparés : un pour le contenu public et un pour le contenu privé.
Le dépôt de contenu privé pourrait lui-même être conservé en privé (vous pourriez déterminer qui y a accès indépendamment).