Je suis en train de mettre en place une nouvelle plateforme Discourse et j’aurais besoin de votre aide pour une question particulière. Dans la plateforme Discourse que je souhaite développer, je cherche à implémenter une configuration où seuls le créateur du sujet et les administrateurs peuvent voir le contenu d’une catégorie spécifique. Cette section est destinée à fonctionner essentiellement sur le concept de « Signalement de bug ». Il est crucial que les bugs signalés ne soient pas visibles par les autres utilisateurs et ne puissent donc pas être exploités par eux, mais qu’ils soient exclusivement visibles par le rapporteur et les administrateurs. Comment pourrais-je mettre en place un tel paramètre avec précision ?
Vous pouvez créer un groupe pour les rapporteurs de bugs, puis utiliser les paramètres de sécurité dans la catégorie que vous souhaitez sécuriser pour n’autoriser que ce groupe et les administrateurs à y accéder (ou le personnel si vous souhaitez que les modérateurs y aient accès).
admin - groupes - +nouveau groupe
Sur la page de la catégorie que vous souhaitez sécuriser, cliquez sur l’icône de la clé à molette en haut à droite et vous pourrez accéder aux paramètres particuliers de la catégorie, y compris la sécurité. Vous devriez pouvoir y ajouter le nouveau groupe avec les autorisations souhaitées.
Bonjour @Lillinator, je vous remercie pour votre réponse. Lorsque je testerai votre suggestion, les membres du groupe pourront voir tous les messages. En fait, mon objectif ici est que le sujet ne soit visible que par la personne qui l’a créé. Les autres utilisateurs ne devraient pas avoir connaissance des sujets créés par d’autres utilisateurs et devraient s’abstenir de toute interaction.
Par exemple ; l’utilisateur A a créé un sujet important dans la catégorie “Rapport de bug” pour signaler un problème. Ce sujet ne devrait pas être visible par les utilisateurs B, C ou D du même forum. Seul l’utilisateur A qui a créé le sujet, ainsi que les modérateurs et administrateurs, devraient pouvoir voir le sujet ouvert par l’utilisateur A.
aha je vois. hmmm, je ne suis pas sûr que ce soit possible. peut-être que quelqu’un d’autre le saurait. je me demande si un plugin est possible. mes excuses, j’avais mal compris que vous vouliez uniquement que l’auteur du rapport de bug y ait accès, et non un groupe de rapporteurs de bug.
Je pense qu’une boîte de réception de groupe conviendrait probablement à cela. L’utilisateur A enverrait un message à @bug-report et il apparaîtrait dans la boîte de réception de groupe @bug-report où tout le monde dans le groupe pourrait le voir, mais seuls ceux qui étaient participants du message pourraient voir leurs messages individuels. Est-ce que quelque chose comme ça fonctionnerait ?
Je comprends votre suggestion, mais elle doit être construite comme un sujet similaire à une plateforme de forum. Ce sujet possède un modèle spécifique, et il est attendu que les utilisateurs signalent les bugs en respectant ce modèle.
Les notifications de bugs entrantes sont ensuite examinées par les modérateurs et transmises aux administrateurs. La personne qui a initié le sujet reçoit également des réponses relatives à son rapport directement via le sujet par les administrateurs. Bien qu’il fonctionne exactement comme un forum conventionnel, la seule différence réside dans le fait que le sujet ne peut être consulté que par celui qui l’a créé.
Je pense que les boîtes de réception de groupe sont intrinsèquement défectueuses à plusieurs égards (comme ceci)
Cela devrait être réalisable avec un plugin, bien que cela puisse prendre du temps pour le faire correctement. Je n’ai pas encore trouvé le temps ou la justification pour l’effort (si vous avez un budget et/ou des compétences en développement, parlons-en)
Et ce ne sont pas des autorisations au niveau du sujet, c’est juste une autre catégorie d’autorisations. Je peux imaginer comment certaines parties fonctionneraient, mais il y a un tas de petites choses dont je ne suis pas sûr comment les faire.
Cela semble pouvoir être un projet intéressant. Je ne peux pas aider pour le moment, mais si vous avez du temps dans un mois ou deux, contactez-moi et nous pourrons peut-être travailler dessus ensemble. Bien sûr, si quelqu’un payait, il serait plus facile de trouver le temps !
En vérité, cette fonctionnalité, à l’instar de sa présence sur d’autres plateformes de forum, devrait également être un composant ici. Comme elle répond à un besoin courant, son absence me laisse plutôt perplexe. Par conséquent, j’ai entrepris quelques recherches, cependant, je crains que mes efforts n’aient pas donné les résultats escomptés. L’exigence portera spécifiquement sur la permission Créer/Répondre, bien que seuls l’auteur du sujet et les administrateurs posséderont la permission Voir.
Droit. Il y aurait une permission de création qui n’inclurait pas la lecture, mais qui permettrait de lire les sujets créés par l’utilisateur. Donc un nouveau type serait ajouté ici :
Et ensuite, tout un tas de code qui fait référence à ces types devrait être modifié. Ou pour un plugin, il serait peut-être plus logique d’ajouter CategoryCustomField qui contournerait les restrictions de création et mettrait à jour les sérialiseurs de catégories et de sujets pour inclure les sujets maintenant disponibles.
Peut-être créeriez-vous un sujet dans une catégorie avec des permissions de création et after_create (ou similaire) le plugin le déplacerait dans une sous-catégorie que seul le personnel peut voir. Et ensuite, le sérialiseur de catégorie pourrait être modifié pour extraire les sujets appartenant à l’utilisateur de la sous-catégorie cachée vers la catégorie. Cela ne nécessiterait aucune nouvelle permission de catégorie et si le plugin était supprimé, les sujets seraient simplement des sujets ordinaires dans une catégorie réservée au personnel. Une preuve de concept de cela (sans les spécifications appropriées, etc.) pourrait ne pas prendre trop de temps. Je pourrais y jeter un œil plus tard aujourd’hui (bien que je craigne d’avoir d’autres travaux à faire.)
mes excuses, j’avais mal compris que vous vouliez uniquement que l’auteur du rapport de bug y ait accès, et non un groupe de rapporteurs de bug.