Bonjour,
Nous avons besoin de créer des groupes de travail : ces groupes n’ont aucun rapport avec les groupes de droits habituels. Ils servent à :
-
regrouper des utilisateurs pour affecter des tâches en commun (une tâche affectée au groupe doit apparaître comme affectée à chacun de ses membres)
-
restreindre la visibilité de certains items métier (une ligne d’objet affectée à un groupe ne doit être visible que par les membres de ce groupe) cf Filtering d’objet selon l’utilisateur
Ces groupes seront créés dynamiquement en runtime (par les utilisateurs eux-mêmes via l’application), pas définis en dev.
Nous avions prévu de redévelopper tout un système de groupes de zéro, mais je me rends compte que l’objet natif Group offre déjà beaucoup de ce dont nous avons besoin : hiérarchie entre groupes, association utilisateur-groupe, et surtout des méthodes Java déjà implémentées pour vérifier l’appartenance d’un utilisateur à un groupe. Plutôt que de tout réécrire, je voudrais créer un objet hérité de Group dédié à nos groupes de travail.
Deux points me bloquent :
- Isolation des groupes de travail vis-à-vis des groupes existants
Comment structurer cet objet hérité pour que sa liste (recherche, sélection, etc.) n’affiche que les groupes de travail créés via ce nouvel objet, sans faire apparaître les groupes de droits ni les autres groupes déjà présents dans la table Group (type workflow, documentaire, notification, service à souscrire, partage de tableau de bord) ? Le mécanisme d’héritage garantit-il nativement ce cloisonnement au niveau des lignes (via un marquage technique lié à l’objet créateur), y compris pour des lignes créées dynamiquement en runtime via API/formulaire (pas seulement en dev) ?
- Absence d’effets de bord côté droits
En associant un utilisateur à un groupe de travail (instance de mon objet hérité), puis-je être certain que le moteur de droits de Simplicité ne va jamais interpréter cette appartenance comme une appartenance à un groupe de droits, et donc n’accorder aucune permission non prévue à l’utilisateur ?
Question subsidiaire
Le champ type de l’objet Group (droit, workflow, documentaire, notification, service à souscrire, partage de tableau de bord) — au-delà de son usage évident pour les groupes de droits et de workflow — a-t-il un impact fonctionnel réel sur d’autres sous-systèmes (ex : un groupe de type “notification” est-il automatiquement consommé par un mécanisme de notification existant), ou s’agit-il uniquement d’un filtre utilisé pour peupler certains sélecteurs dans l’UI d’administration ?
Merci d’avance pour vos retours, notamment si certains d’entre vous ont déjà mis en place un pattern similaire de “groupes fonctionnels” distincts des groupes de droits.