Je fais :
acl create aro ‘Group’, 1, null, ‘Administrateur’

Et je reçois un beau message d’erreur :

Error: Could not find parent node using reference “‘Group’,”

As-tu une vague idée du problème ?

return $data['Group']['parent_id'];

au lieu de :

return array(’model’ => ‘Group’, ‘foreign_key’ => data['Group']['parent_id']);

Pour reprendre :

1) Oui, en fait je me suis emmêlé les pinceaux en voulant taper un petit exemple… C’était en fait pour savoir comment différencier deux actions qui se nomme pareil mais se trouvant dans deux contrôleurs différents lorsque qu’on assigne les droits via allow(). Il faut en fait y accéder via ‘nomModèle.nomAction’ dans ce cas.

2) Merci pour votre explication, je vois mieux le but de la séparation !

3)4) Si j’ai bien compris les comportements (avec le $actsAs) : cela permet lors d’une action CRUD sur le modèle contenant le comportement ACL d’ automatiquement mettre à jour les infos de la table ARO ou ACO. Donc ici, lorsqu’on ajoute un utilisateur via la méthode save() du modèle User, il y aura également d’office une entrée enregistrée dans les ARO. De la même façon pour la lecture, mise à jour et suppression d’utilisateurs j’imagine.

Merci encore !

1) “J’ai un contrôleur Articles avec une action admin_ajouter et une action admin_supprimer. En toute logique, je devrais faire : $this->Acl->allow(’Redacteurs’, ‘Articles’, array(’read’, ‘create’));
Hors, en faisant comme cela, l’utilisateur n’a pas du tout accès au contrôleur”.
> Il s’agit ici d’un problème de nommage des fonctions. Il faut rester dans la norme anglaise et rebaptisez les actions en admin_add et admin_del ou admin_delete.

2) “vous utilisez une table group, mais elle semble faire doublons avec les infos de la table ARO”
> On peut très bien imaginer des groupes distincts qui ont exactement les mêmes droits, par exemple dans les gestion d’une usine, le groupe Equipe de Nuit et le groupe Equipe de Jour ont tous deux le même rôle Equipe, inutile de dupliquer les droits.

3) “Si j’ai bien compris, les utilisateurs ne font pas directement parti des AROs mais par l’intermédiaire des groupes”
> Les utilisateurs peuvent tout à fait avoir un ARO associé, tout en appartenant à un groupe qui lui-même a un ARO, d’où la souplesse de la solution.

4) “En revanche pour les groupes, je vois l’utilité. Le problème, est qu’à l’ajout d’un groupe (méthode save() sur le modèle Group) , Cake ajoute bien une entrée dans les AROs, mais l’alias du groupe et son éventuel parent restent vides dans la tables des AROs…”
> Je ne suis pas sûr d’avoir bien compris, voudriez-vous préciser ? L’idéal serait même de fournir une portion de code via http://bin.cakephp.org/