J’ai configuré une catégorie pour le suivi des bogues sur notre serveur Discourse. Je souhaite suivre à la fois les soumissions de bogues publiques des utilisateurs et les bogues soumis en interne au même endroit.
Je veux que les bogues publics soient visibles par tout le monde (donc les sujets privés ne sont pas une solution). De cette façon, nous pouvons réduire les doublons et les gens peuvent commenter ou élaborer sur un sujet existant.
Je veux également que nos équipes internes puissent soumettre des bogues, mais je ne veux pas qu’ils soient visibles par le grand public, sauf si nous le souhaitons spécifiquement pour un sujet donné.
Nous pouvons activer le murmure sur les réponses, mais pas sur le sujet lui-même. Existe-t-il donc un moyen de définir la visibilité par sujet?
Définir le sujet comme ‘Non répertorié’ fait presque ce que nous voulons, sauf que nous avons un groupe de développeurs qui doivent les voir mais qui ne sont pas définis comme modérateurs ou administrateurs, ils font juste partie d’un groupe.
Pouvez-vous avoir deux versions de cette hiérarchie d’arborescence ? Une pour l’interne et une pour l’externe. Vous pouvez utiliser des étiquettes (ou des étiquettes automatiques) pour aider l’équipe interne à voir quels bogues existent à la fois en interne et publiquement.
Alternativement, si vous êtes un client entreprise, vous pourriez avoir des catégories de troisième niveau activées.
Je suis auto-hébergé, donc je peux y mettre un autre niveau si je le souhaite, mais encore une fois, ce n’est pas la solution la plus simple pour l’utilisateur.
Ce que j’entends, c’est que ma demande n’est pas possible.
C’est dommage. Cela serait résolu en ayant un paramètre de site pour “Autoriser ces groupes à voir les sujets non répertoriés. Les administrateurs et les modérateurs peuvent toujours voir ces sujets”.
Quelle importance accordez-vous au fait que d’autres utilisateurs ne lisent pas ces sujets ?
Je doute que les sujets non répertoriés soient vraiment une solution pour vous. Lorsque vous suivez une catégorie, vous recevez également une notification pour chaque sujet non répertorié qui est créé. Cette notification contient le lien afin que vous puissiez visiter et lire le sujet.
Les sujets ne seraient donc pas seulement visibles par le groupe spécifique.
Seules les catégories contrôlent l’accès, mais si vous souhaitez une version plus souple, vous pourriez faire quelque chose avec CSS pour obtenir un résultat…
Ah. Peut-être devriez-vous modifier vos autorisations afin que les développeurs (qui sont trop stupides, paresseux ou négligents pour placer les choses dans la bonne catégorie) n’aient pas de droits de création dans la catégorie de bugs publique. Ensuite, si quelque chose doit être public, quelqu’un qui a suffisamment d’attention pour être digne de confiance peut les déplacer vers la catégorie publique.
Cela va un peu à l’encontre du but de ma demande initiale. Je veux une seule catégorie de bogues et le contrôle de la visibilité des sujets individuels au sein de cette catégorie.
Cela semble réalisable, mais d’après les commentaires, peut-être pas.
Je pense que tout processus impliquant « peut être public, peut être privé » comportera un risque d’erreur humaine chaque fois que quelqu’un crée un sujet. Qu’il s’agisse de choisir la bonne catégorie, de se souvenir de cliquer sur « murmure » ou d’ajouter une balise qui effectue ensuite une magie CSS pour la masquer, etc. Il y a un point où vous devez faire ce choix et une opportunité correspondante de le gâcher.
Je pense qu’une sous-catégorie est la bonne approche pour avoir confiance dans les protections de visibilité. Si vous ne souhaitez pas activer les sous-sous-catégories pour cela (ou ajuster votre structure de catégorie de niveau supérieur avec une alternative comme Category Groups), vous pouvez avoir une sous-catégorie supplémentaire dans Support pour #internal-bug-reports, puis utiliser le filtre de sujet pour créer une liste de sujets personnalisée incluant les sujets des deux catégories, que vous pouvez ensuite ajouter à la barre latérale pour que vos développeurs l’utilisent.
Juste pour le plaisir, j’ai testé si je pouvais changer le post_type d’un OP via l’API. Et bien que cela ait fonctionné, il est toujours apparu dans la liste des sujets pour un utilisateur de test non-murmure et a ensuite généré une erreur lorsqu’il a cliqué dessus. Il semble donc qu’un travail de développement supplémentaire serait nécessaire pour lisser cela (et il peut également y avoir d’autres conflits pour le comportement inattendu lorsque vous commencez à explorer).
Ce n’est peut-être pas si grave. Je ne suis pas sûr que cela me dérange si les utilisateurs réguliers peuvent voir les titres.
Mon contournement actuel est similaire :
Créer un sujet avec un nom descriptif approprié.
Le corps consistera en « Suivi du bug n° ».
Enregistrer
Modifier le message et y mettre le # de l’URL, de sorte que le corps dise maintenant « Suivi du bug n°138 ».
Mettre en whisper toutes les réponses supplémentaires.
Maintenant, j’ajoute simplement mon groupe de développement à la liste « Groupes autorisés en whisper ».
Ce n’est pas aussi élégant que je le souhaiterais, mais la rédaction de la procédure opérationnelle standard est assez simple.
Cela a l’avantage supplémentaire de permettre à un utilisateur régulier d’ajouter un message au sujet s’il a un bug qui semble similaire au titre.
Il semble donc qu’un travail de développement supplémentaire serait nécessaire pour lisser cela (et il peut également y avoir d’autres conflits pour le comportement inattendu lorsque vous commencez à explorer).