ACL des groupes

J’ai vu quelques discussions en cherchant sur Google à ce sujet, mais je n’ai trouvé aucune indication claire.

Je prévois de passer de vBulletin3 à vBulletin5, puis d’explorer la possibilité de passer à Discourse. La seule chose importante que j’attendais d’une solution moderne comme Discourse était la possibilité de gérer/créer des groupes et de leur attribuer un accès granulaire, mais il semble que ce ne soit pas le cas.

Me trompé-je et manque-t-il simplement la fonctionnalité dans les paramètres ?
Dans le cas où j’ai raison, y a-t-il un plan officiel pour éventuellement supporter cela ou un plugin qui offre quelque chose de ce genre ?

Merci

1 « J'aime »

Je ne suis pas sûr de la granularité que vous souhaitez ?

Voici ce qui est actuellement disponible dans Discourse : Understanding groups and category permissions

2 « J'aime »

Salut, merci pour le lien, je vais le lire.

Ce que je voulais dire, c’est quelque chose comme la plupart des CMS, qui consiste à lister toutes les actions possibles effectuées par les administrateurs, comme les opérations CRUD sur les utilisateurs, les catégories, les sujets, etc.

C’est l’un des pires cauchemars en termes d’interface utilisateur, mais c’est un outil très puissant en termes de personnalisation.

Cela nécessiterait d’avoir des tables dédiées comme :
Utilisateurs ← → Groupes_Utilisateurs ← → Groupes ← → Groupes_Actions ← → Actions

Ainsi, les utilisateurs peuvent appartenir à un ou plusieurs groupes et les groupes peuvent avoir une ou plusieurs actions.
Ma préoccupation est qu’il s’agit d’une fonctionnalité si “centrale” que je ne sais pas si un plugin pourrait faire quelque chose comme ça.
C’est pourquoi je demandais si quelque chose est prévu ou existe déjà pour Discourse lui-même.

Vérifier le lien que vous suggérez explique comment déterminer “où” les rôles prédéfinis peuvent agir, mais “ce qu’ils peuvent faire” est assez figé et très basique : “voir, lire, répondre”. C’est bien pour le travail de “front office”, mais il n’y a pas grand-chose en termes de travail de “back office”.

Le travail de back office concerne essentiellement toute la maintenance de la plateforme elle-même en termes d’administration et de modération. La granularité pourrait être :

  • Peut gérer les utilisateurs (toutes opérations)
  • Peut approuver les utilisateurs
  • Peut bannir/faire taire les utilisateurs
  • Peut accéder aux paramètres de personnalisation
  • Peut accéder aux paramètres (même plus détaillés éventuellement)

Ce ne sont que des exemples, bien sûr, mais j’espère que vous comprenez ce que je veux dire.

1 « J'aime »

Users ← → Users_Groups ← → Groups existe,

Mais actions_groups est codé en dur et voici comment il est codé en dur : Trust Level Permissions Reference

2 « J'aime »

Oui, j’imaginais bien. C’est pourquoi je demandais s’il y avait quelque chose dans la feuille de route concernant la refonte de cette fonctionnalité pour l’améliorer.

Certaines permissions ont été progressivement migrées vers SiteSettings, nommant un seul groupe. Les modérateurs de catégorie existent, nommant un groupe chacun. Mais dans la plupart des cas, la seule permission dynamique est l’accès à la catégorie.

2 « J'aime »