Je voudrais avoir environ 20 000 groupes dans mon instance Discourse, est-ce possible et cela affecterait-il les performances du site web d’une quelconque manière ?
Combien d’utilisateurs aurez-vous ?
Quel problème 20 000 groupes résolvent-ils ?
Voici le scénario. J’utilise Discourse pour créer une plateforme de discussion pour des articles de recherche. Chaque article est représenté par une étiquette avec son identifiant. Tous les sujets créés sous cette étiquette apparaissent sur la page de l’étiquette pour cet article.
Le problème est que la fonctionnalité suivante me manque :
J’ai un processus d’approbation manuelle pour les auteurs des articles téléchargés sur le système. Je veux leur donner la possibilité de modifier les publications étiquetées avec leur article. Mais j’ai appris qu’il n’est pas possible de donner des permissions basées sur les étiquettes.
J’ai alors eu l’idée d’avoir un groupe par article et les auteurs d’un article appartiendront au même groupe. Mais je ne suis même pas sûr si cela résout mon problème car je ne sais pas comment donner la possibilité de modifier certaines publications.
J’apprécierais d’entendre s’il existe un moyen élégant d’avoir cette fonctionnalité. Merci.
Vous souhaitez que l’auteur puisse modifier les publications des autres s’il s’agit d’une réponse à son article ?
Et vous parlez de publications et non de sujets ?
Oui, le fait qu’un message soit une réponse ou lié à leur article est actuellement déterminé par l’étiquette.
Mais je peux aussi créer un groupe par article si cela peut aider.
Et idéalement, les messages et les sujets devraient être modifiables.
Les groupes sont très légers, vous pouvez en avoir plusieurs milliers sans problème.
Avoir 20 000 catégories en revanche posera un problème de performance.
Les messages n’ont pas de balises, les sujets en ont.
Je ne comprends pas pourquoi vous voulez que les gens puissent modifier les messages des autres. Vous pouvez en faire des wikis, mais alors n’importe qui peut les modifier.
Ou peut-être voulez-vous que le sujet de l’utilisateur soit un wiki afin que n’importe qui puisse le modifier.
Je ne comprends tout simplement pas quel est le modèle dans lequel il est logique de changer les mots de quelqu’un d’autre.
J’ai aussi commencé à remettre en question les mérites que l’édition apporte après avoir considéré plusieurs scénarios. Cependant, il serait agréable d’avoir un mécanisme pour voir si une personne qui répond est l’auteur de l’article auquel le sujet est lié et je pense que ce n’est toujours pas possible avec les groupes.
Plus explicitement : Disons qu’un utilisateur a créé un post taguant l’article avec l’id 5. Si l’auteur de l’article 5 poste une réponse à ce sujet : La fonctionnalité idéale serait d’indiquer d’une manière ou d’une autre (cela peut être un flair, un titre, un petit texte par défaut en haut du post) que l’utilisateur qui répond est l’auteur de l’article discuté.
Si chaque document est un sujet, et que vous attribuez le sujet OP à l’auteur, il est trivial de créer une règle CSS pour ajouter une différenciation visuelle aux réponses de l’OP sur ses réponses ultérieures.
Pourquoi ne pas avoir un seul sujet par article ? Il n’y aurait alors aucune confusion. Vous n’auriez pas besoin de tags ou de groupes.
De plus, il semble que vous confondiez le sens de sujet dans Discourse (une collection de messages) et un message (un seul message d’une seule personne qui réside dans un sujet).
Mais maintenant, @falco m’a devancé…
@pfaffman @falco Techniquement, chaque article est une étiquette. La raison est qu’un sujet ne suffit pas pour avoir toutes les discussions ou questions sur un article. Il y a de nombreux aspects différents à discuter et la principale motivation de ce forum est d’avoir une source unique de toutes les discussions qui ont eu lieu autour d’un article. Par conséquent, chaque article est une étiquette et tous les sujets créés sous l’étiquette d’un article peuvent être vus depuis la page /tag/:paper_id.
Est-il possible de faire le truc CSS dans ce scénario ? Je peux créer une base de données externe définissant la relation entre les étiquettes et leurs « utilisateurs auteurs » respectifs si nécessaire.
Oui, vous pourriez avoir un fichier CSS qui serait automatiquement généré à partir de l’analyse de ladite base de données.
Vous pourriez également faire tout cela dans Discourse en utilisant un plugin personnalisé. Il apporterait un champ supplémentaire dans le sérialiseur de sujet pour les publications où l’auteur de la publication correspond, qui pourrait ensuite être exploité par l’application front-end.
Je vois, je suis tout nouveau dans les plugins mais je vais essayer de voir ce qui peut être fait. Merci beaucoup pour vos conseils !
N’hésitez pas à ouvrir des sujets sur Dev lorsque vous êtes bloqué.
Vous comprenez donc que les sujets ont des tags, pas les messages. Je pense que vous utilisez le mot « message » alors que vous voulez dire « sujet ».
Je ne pense pas que vous ayez répondu à cela. Si vous ne voulez pas que les gens modifient les messages des autres, je ne pense pas que vous ayez de problème. Je ne peux pas imaginer pourquoi vous voudriez que les gens modifient les messages des autres, mais si c’est le cas, en faire un wiki pourrait être la solution.
Taguer les sujets qui portent sur un papier particulier avec un tag de papier (comme un DOI, mais je suppose qu’il n’y a peut-être pas de DOI à ce stade de la vie du papier) est une excellente idée et vous pouvez le faire dès maintenant avec l’API. De plus, les utilisateurs qui peuvent modifier le sujet (niveau de confiance 3, et le propriétaire du sujet) peuvent ajouter le tag ; d’autres peuvent le signaler et demander qu’il soit tagué (mais celui qui a lancé le sujet ne sait-il pas qu’il porte sur le papier ?).
Je ne suis pas clair sur ce pour quoi vous avez besoin d’un plugin à ce stade.
Pourriez-vous me dire où se manifesteraient les problèmes de performance ? C’est-à-dire, est-ce sur des pages spécifiques, ou est-ce un problème général ? Si chaque catégorie est liée à un ou deux groupes, et que l’utilisateur moyen n’a accès qu’à 10 à 20 catégories au total, est-ce toujours un problème d’avoir 20 000 catégories ?
Pour mon cas d’utilisation (hypothétique), il s’agit de permettre la discussion de sujets publics via des MP de groupe. Cette approche pourrait être utilisée de différentes manières pour tenter de générer des discussions publiques productives autour de sujets polarisants. Essentiellement, les discussions pourraient être gamifiées en demandant aux gens de rejoindre des équipes (groupes) liées à un sujet spécifique, puis de suivre un ensemble de règles pour répondre au sujet public en équipe.
Je suis prêt à gérer les problèmes d’interface utilisateur que des milliers de groupes pourraient créer pour le personnel du site. Je réalise que c’est un cas d’utilisation inattendu pour les groupes Discourse, je poste donc à ce sujet ici au cas où il y aurait des problèmes de performance évidents qui m’échapperaient.
Eh bien, cela a plus de sens que ce que j’imaginais. ![]()
Je pense qu’il y a une fonctionnalité de groupe créé par l’utilisateur en préparation, mais je soupçonne qu’elle n’est pas pour tout de suite.
Ce serait génial, mais pour l’instant, cela peut être fait avec l’API.
Ooh. Je commence à m’éloigner du sujet, mais vous pourriez utiliser l’une de ces choses d’API qui reçoivent un webhook pour chaque nouveau sujet et créent ensuite un groupe pour celui-ci. Aucun plugin requis. Je ne sais pas pourquoi je n’avais pas pensé à avoir Discourse des deux côtés de l’un de ces services auparavant.
Et GitHub - triggerdotdev/trigger.dev: Trigger.dev – build and deploy fully‑managed AI agents and workflows est tombé sur mon bureau aujourd’hui. Il semble que vous pourriez lui faire faire le travail plutôt que de payer l’un de ces services. Je doute qu’il ait un support Discourse prêt à l’emploi, mais il devrait être assez facile de le faire fonctionner.