Savez-vous si ce plugin fonctionne avec ActiviyPub ?
Je n’ai pas testé cela. Ce plugin remplace les vérifications d’accès et de visibilité, il fonctionne donc généralement bien avec d’autres plugins. J’imagine que le plugin ActivityPub s’accroche à des endroits qui (involontairement) contournent ces vérifications. La seule façon de le savoir est de le tester.
Cela dit, je ne vois pas de cas d’utilisation où les catégories de sujets privés seraient éligibles pour ActivityPub.
2 « J'aime »
Ah, je vois. J’avais mal compris ce que cela faisait.
Encore mieux.
2 « J'aime »
Merci pour ces excellents plugins, il nous manquait cela depuis longtemps.
Nous avons essayé de coupler cela avec la fonctionnalité « email in ». Cela fonctionne bien dans les cas simples, mais les cas plus complexes ne fonctionnent pas très bien :
- Si quelqu’un envoie un e-mail à 2 catégories d’e-mails « sujets privés », il apparaît dans une seule (assez normal dans le fonctionnement de Discourse, mais pas compréhensible pour les personnes utilisant l’e-mail)
- Idem si l’utilisateur envoie à plusieurs e-mails liés à des groupes et d’autres à des catégories
- Si l’utilisateur envoie à des e-mails externes et à l’e-mail de la catégorie « sujet privé », lorsque nous répondons, les autres e-mails externes ne reçoivent pas la réponse. (Les messages de groupe prennent en charge cela, car nous pouvons inviter quelqu’un dans la conversation)
Ces problèmes ne sont pas spécifiques à ce plugin mais constituent un inconvénient général des sujets de catégorie par rapport aux boîtes de réception de groupe. Ce plugin ne vise pas à résoudre tous ces problèmes.
1 « J'aime »
Correction : La recherche sémantique de Discourse AI pouvait contourner la protection. Ceci est maintenant résolu. Si vous utilisez ce plugin avec le plugin Discourse AI, assurez-vous de le mettre à jour !
3 « J'aime »
Je viens de voir ce plugin. Très cool.
1 « J'aime »
Merci pour le plugin @RGJ, il semble répondre à ma fonctionnalité nécessaire. 
Deux problèmes que j’ai rencontrés lors des tests :
- Si j’« ouvre » une catégorie existante A (jusqu’à présent accessible uniquement au groupe A) en activant dans les paramètres de sécurité la case « activer les sujets privés » et en ajoutant des droits à un autre groupe B pour qu’il puisse poster ses sujets privés, il semble que tous les sujets existants des autres utilisateurs du groupe A soient visibles par les membres du groupe B. Il semble donc que la fonctionnalité de sujet privé ne fonctionne que pour les sujets créés après l’activation du plugin, mais pas pour les sujets existants, créés avant l’activation du plugin. Quelqu’un peut-il confirmer cela ?
Mon fonctionnement attendu/souhaité serait que les sujets existants restent/soient cachés aux utilisateurs du groupe B (comme cela fonctionne pour les nouveaux sujets). Sinon, je ne suis pas sûr de la manière de migrer. - Lors des tests, j’ai remarqué qu’après avoir créé un sujet par un utilisateur appartenant au groupe A (propriétaire de la catégorie), le compteur
Nouveau (1)dans la vue de la catégorie était affiché pour un utilisateur du groupe B. Comme le sujet était (correctement) caché à l’utilisateur, cette notification par le compteur semble être un bug et pourrait irriter les utilisateurs.
discourse 3.2.0.beta5-dev (cef6aca6e5)
plugin 1.5.3 (709df2c)
Le plugin n’affecte pas seulement les sujets créés après son activation, il fonctionne pour tous les sujets dans ces catégories.
Je ne suis pas sûr de ce que
signifie. S’il s’agit du sélecteur de groupe sous la case à cocher, ce n’est pas ce que fait ce paramètre.
Les sujets sont visibles par le créateur du sujet et par les utilisateurs des groupes suivants
Lorsque vous y ajoutez le groupe B, vous donnez à tous les membres du groupe B le pouvoir de voir tous les sujets. Ceci est destiné, par exemple, à votre équipe de support.
Si cela ne concerne pas ce sélecteur de groupe, veuillez décrire votre configuration plus en détail.
Désolé, je me suis mal exprimé.
Je n’ai pas ajouté le groupe B là-bas. J’ai seulement ajouté le groupe B aux paramètres de sécurité génériques pour leur permettre de voir la catégorie et de poster des sujets.
Description de configuration plus détaillée :
Paramètres de la catégorie avant d’activer le plug-in :
- Seul le groupe A a accès à la catégorie (voir, répondre, poster).
Paramètres de la catégorie après avoir activé le plug-in :
- Ajout de l’accès au groupe B à la catégorie (voir, répondre, poster)
- Activation des sujets privés pour cette catégorie
- Ajout du groupe A à Les sujets sont visibles pour le créateur du sujet et pour les utilisateurs des groupes suivants : (en fait, il avait déjà été ajouté par défaut)
Tout d’abord, je viens de pousser un correctif pour Ember5, mais cela n’aurait pas dû influencer le fonctionnement du plugin. Pour être sûr à 100%, veuillez reconstruire et configurer le plugin à partir de zéro.
Je ne peux pas reproduire cela.
- Configurez-le comme vous l’avez dit, avec l’utilisateur A dans le groupeA et l’utilisateur B dans le groupeB.
- L’utilisateurA a créé un message
- Configurez le plugin
- L’utilisateur B a créé un message
- L’utilisateur A a créé un autre message
Vue de l’administrateur
L’utilisateur A voit
L’utilisateur B voit
Donc, cela se comporte comme prévu.
De plus, c’est très étrange, il n’y a pas d’ajout de groupe par défaut ici.
1 « J'aime »
Merci pour vos commentaires et tests rapides, @RGJ ! Et désolé pour ma réponse tardive, d’autres tâches m’ont éloigné du problème pendant quelques jours. J’ai mis à jour le plug-in et re-testé avec une autre catégorie. Je ne peux plus le reproduire moi-même, donc cela semble fonctionner comme prévu. Seuls les sujets créés par un administrateur sont affichés dans la catégorie (probablement intentionnellement et de manière judicieuse), je m’en suis peut-être embrouillé lors de mon premier test. Désolé pour le bruit !
Le problème avec le compteur « nouveau » pour les nouveaux sujets semble persister : l’utilisateur d’un groupe autorisé uniquement à voir ses propres fils de discussion a un compteur « nouveau », mais ne peut pas voir les nouveaux fils de discussion si un utilisateur du groupe « support » (autorisé à voir tous les sujets) publie un nouveau sujet. Voir la capture d’écran ci-dessous : « Neu (5) » pour l’utilisateur sans droits
Vue pour l’utilisateur de support avec droits :
1 « J'aime »
Correct, ceci est contrôlé par le paramètre private topics permitted groups « Toujours afficher les sujets initiés par un membre de ces groupes »
Oui, c’est un problème connu. Les PR ou les pistes sont les bienvenus.
1 « J'aime »
Une question, même si je connais peut-être la réponse.
Que se passe-t-il si le plugin doit être désactivé, en raison de conflits, etc. ? Tous les sujets et messages seront-ils alors visibles par tout le monde ou cette catégorie sera-t-elle restreinte à tout le monde ?
Parce que la première option est quelque chose qui est totalement hors de question pour moi, trop de données sensibles. Mais si la seconde… je peux vivre avec.
Lorsque vous désactivez le plugin, tous les sujets de la catégorie seront visibles par tout le monde.
Si vous souhaitez l’éviter, vous devriez modifier les autorisations de la catégorie pour qu’elles soient plus strictes, avant de désactiver le plugin.
1 « J'aime »
Comme je m’y attendais. Il y a donc un énorme risque : l’erreur humaine. Si je dois le désactiver, je devrais me souvenir dans ce chaos d’ajuster également les restrictions de groupe. C’est vraiment un gros point d’interrogation en fait.
Évitez le chaos et tout ira bien 
1 « J'aime »
C’est très vrai 
Mais les problèmes de plugins et d’environnement sont hors de mon contrôle (sinon ce serait… passionnant 
)
Je réfléchis juste à une idée… s’il y avait une mesure de sécurité, comme un composant compagnon qui aurait une et une seule tâche : surveiller le statut du plugin et informer immédiatement l’administrateur (ou les administrateurs) que la catégorie est visible par tout le monde.
Je suis un petit acteur, mais je me demande si ces forums d’entreprise, qui l’utilisent, et qui ont souvent plus d’un administrateur, sont pleinement conscients de ce risque 
1 « J'aime »
Sans en connaître beaucoup sur les possibilités, donc peut-être juste une pensée non pertinente, comment atténuer le risque : Avant/pendant la désactivation du plugin, afficher un dialogue à l’utilisateur, lui rappelant les conséquences de la désactivation du plugin et de vérifier à nouveau les paramètres de sécurité de la catégorie.
Juste mon avis : En général, je suppose que le problème est plutôt mineur, car je suppose que les gens ne désactivent pas aveuglément un plugin dont ils ont besoin, mais réfléchiront à la manière de répondre à leurs besoins s’ils doivent désactiver le plugin…
La raison la plus courante est que le forum est hors service. Et je ne connais pas beaucoup d’administrateurs qui continuent à réfléchir quand ils connaissent la cause et que la solution consiste à désactiver un plugin. J’aime Category Lockdown mais comme il est cassé, je l’ai retiré en une seconde. À ce stade, je devrais maintenant me souvenir quelles sont les limites d’un plugin spécifique qui s’est bien comporté pendant longtemps.
C’est le même problème qu’avec les sauvegardes. Nous savons tous à quel point les sauvegardes sont importantes. Mais si cela dépend d’un travail manuel et de la mémoire… alors il n’y a pas de sauvegardes ou celles-ci sont vraiment anciennes.
Le facteur humain est le plus grand risque jamais connu.
Quoi qu’il en soit. Le plugin lui-même est merveilleux mais je dois un peu réfléchir aux avantages et aux inconvénients. Je suis soumis à différentes réglementations et l’exposition de ces données peut coûter cher de plus d’une manière.
2 « J'aime »