CiviCRM Community Forums (archive)

Bonjour Lionel,

Bienvenue à CiviCRM!

En plus des permissions du CMS (Joomla) qui permettent de "voir tous les contacts", on peut aussi décocher cette permission, puis utiliser les ACL de CiviCRM comme tel. Par contre, je préfère mettre en garde: ce n'est pas la fonctionnalité la plus facile à configurer, mais ça fonctionne bien une fois qu'on a compris le principe.

La première étape consiste à identifier comment on regroupe les contacts sur qui l'on définira les contrôles d'accès. En général, on évite d'avoir à ajouter chaque contact dans un groupe spécifique. À moins que ce soit automatique, les gens oublieront d'ajouter au bon groupe, puis n'auront plus accès à leurs contacts.

Par exemple, souvent on restreint l'accès par zones géographiques. Dans ce cas là, on peut définir un groupe pour les "contact dans la région X", puis un autre groupe "admins de la région X". On ajoute ensuite un ACL de CiviCRM qui permette aux "admins de X" de modifier les "contacts de X".

Si c'est pour restreindre selon la personne qui a créé le contact, on peut créer des groupes dynamiques par la recherche avancée (ou "recherche multi-critère" selon la traduction). Dans la critères de recherche, déplier l'onglet: "Journal", choisir l'option "ajouté" (plutôt que "modifié"), puis entrer le nom d'une personne/employée. Cliquer "rechercher", puis dans les actions, choisir "créer un nouveau groupe dynamique", et nommer le groupe, par exemple, "contacts de X". (voir la saisie d'écran en pièce-jointe). Il faudra répéter la procédure pour chaque employé.

On peut aussi combiner des critères de recherche. Par exemple: "contacts créé par X", et "champ personnalisé dont la valeur est X", comme ça on peut aussi donner accès à certains contacts à X, mais qui n'ont pas nécessairement été créés par X.

Enfin, si jamais il y a beaucoup de groupes (ex: beaucoup de régions, employés, etc), on peut implémenter les règles d'accès de façon programmatique, en PHP. Il faut voir du côté des "hooks" de CiviCRM, plus spécifiquement hook_civicrm_aclGroup et hook_civicrmWhereClause. Par exemple, si on définit un champ personnalisé pour les zones géographiques, et un autre champ personnalisé où l'on indique à quelle zone les employés ont accès, les hooks peuvent générer le SQL nécessaire pour s'assurer que les deux champs correspondent. De cette façon, pas besoin de créer deux groupes pour chaque zone géographique.

Pour référence, la documentation en anglais:
http://gitbook.civicrm.org/initial-set-up/permissions-and-access-control.html

Il y a aussi:
http://wiki.civicrm.org/confluence/display/CRMDOC/Access+Control

Les "hooks":
http://wiki.civicrm.org/confluence/display/CRMDOC/Hook+Reference

Bonjour Lionel,

Je viens de penser à un truc.. ce serait possible d'utiliser les relations de CiviCRM.

Les relations ont le concept de permissions. "tel contact est relié à tel-autre, et la relation donne des permissions sur le contact". Par contre, par défaut cette case à cocher ne donne pas beaucoup de permissions. Il y a une extension qui permet d'aller plus loin, et de faire fonctionner les relations comme de vrais ACLs:
https://civicrm.org/extensions/relationship-permissions-acls

À noter que cette extension dépend de:
https://github.com/eileenmcnaughton/nz.co.fuzion.entitysettings

Avec ces extensions, on donc créer des contacts et les relier à qui ils "appartiennent". La seule chose qu'il faudrait peut-être programmer, c'est un hook_civicrm_post(), pour créer automatiquement une relation lorsqu'on crée un nouveau contact. Avec hook_civicrm_post(), et l'API "Relationship.create", ça devrait être que quelques lignes de code dans une extension (http://wiki.civicrm.org/confluence/display/CRMDOC/Create+an+Extension).

Sinon, je recommanderais fortement de regarder du côté des hooks des ACLs pour éviter d'avoir à créer des groupes dynamiques. Les saved-search n'ont pas un bon API d'exposé (de mémoire), donc ça peut briser assez facilement. L'extension "relatedpermission" est un bon exemple d'utilisation de ces hooks.

Mathieu