I wondered about that user row as well. But the reasoning is that to
determine the permissions for the user, it looks up the user record to
find the complete permissions path in the ARO table and it does this
without knowledge of what group the user is in until it starts this
process.
What really irks me is that given the use of two hierarchical trees:
* you would think that ACOs could live at multiple levels in multiple
places... and you would especially think that AROs/Users could live at
multiple levels in multiple places. Real world permissions are not a
simple factor of which group you're in, but a combination of factors
that often includes department, seniority, job function, clearance....
* you would think that for every model A that "hasMany" model's B, all
permissions for models B would inherit from those for model A... and
likewise, for every _id that shows up in the user table, for which the
corresponding model has an actsAs requester, complex permissions would
be made to take membership in all those groups into account. And in
your user model you could link them together as "AND" or "OR' so that
the user either must belong to A&B&C in order to access AROs mapped to
all three, OR that the user can belong to X or Y or Z to access a
record if it belongs to any of the three.
* you would think that you could make any model actsAs both a
requester and controlled so that projects could be assigned to
departments and users too and ACL permissions would allow access based
on belonging to the department
* you would think that for every record created by a user, ACL would
by default assign full CRUD permissions for that record to that user,
but that this could be overridden by the presence of a var $create =
array('read','edit') in the model.
* you would think that a user would by default be barred from creating
or editing a record that belongs to a record the user has no access.
* you would think that indexes and select menus would by default
populate with filtered data so that if you don't have access to those
records, they don't show up in an index or a select menu.
But ACL can do nothing remotely like this. Frankly, I have trouble
understanding what the point of the tree-stucture with the bridge
table is, since as soon as you try leveraging it, you run into ACL
limitations. The best you can really do is setup a bunch of groups
and put any user into each group once. That's not normalized or DRY
since the relationships already exist in the Users table.
A much simpler method, one that wouldn't have caused so much hope,
consternation and disappointment, would have simply been to make ACL
use one special table called groups and in it, and one called
groups_models, which defines which models each group is explicitly
denied access to, and then have four columns for create, view, edit,
or delete per definition. Anything not appearing here is granted
permission.
No MPTT needed. And easier to parse and understand and setup. And no
one would get their hopes up that ACL was some lofty complex and
powerful permissions tool.
On Oct 4, 10:06 am, Jeremy Burns | Class Outfit
<[email protected]> wrote:
> I'm generally with you on that - although it's a shame. I love the concept
> but to my chagrin I have never got it working and haven't had the brain space
> to root through the code and queries to understand why. It also seems really
> odd to have to have a User row in the ACL tables when the User already
> belongs to a Group - and it is the Groups that I usually want to assign
> permissions to. Am I just being dim (it is possible!)?
>
> Jeremy Burns
> Class Outfit
>
> [email protected]http://www.classoutfit.com
>
> On 4 Oct 2010, at 17:55, calzone wrote:
>
>
>
> > The most maddening thing about ACL is that it is so close yet so far.
> > If ever there was something you could call half-baked, ACL is it.
>
> > What you seek is the kind of thing it should handle easily out of the
> > box, yet it can't. Cake's ACL feels like it was a brilliant thought
> > started by someone on the team who never finished it and no one else
> > wanted to touch it. ACL is so limited in practical real-world
> > applicability that it's not worth your time to fight with it.
>
> > If you want a flat permissions scheme that hardly justifies using a
> > two tree models and a bridge table, go ahead and use ACL... but it
> > will be faster to handle it yourself in app_controller.php or
> > app_model.php and probably perform better than invoking an MPTT
> > system. And if you want something as robust as you seek, sadly, you
> > have no choice than to roll your own.
>
> > On Oct 4, 1:47 am, Jeremy Burns <[email protected]> wrote:
> >> I am building a site where a user can be assigned one or more roles
> >> within an organisation; for example org unit manager, regional
> >> manager, Head of Function and so on. I want to create a permissions
> >> model - ideally using ACL (although I've never really 'got' ACL before
> >> and have never successfully deployed it <embarrassed>) - that mirrors
> >> this structure.
>
> >> My constraints are that:
> >> - each user can be assigned more than one role
> >> - each role has different rites on objects in the system
> >> - if a user is in two roles that have different permissions on the
> >> same object he/she gains the most privileged rites
> >> - the permissions apply at a row level (e.g. an org unit manager can
> >> manage his/her org unit, but no others)
>
> >> I have successfully built this in another system in ASP where I rolled
> >> my own permissions model that did exactly what I wanted it to do and
> >> it was easy to administer.
>
> >> Is this achievable with Cake out of the box, or should I roll my own
> >> again? If it can be done with Cake's ACL, which is the best guide to
> >> refer to (not the online book - I know about that)?
>
> > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others
> > with their CakePHP related questions.
>
> > You received this message because you are subscribed to the Google Groups
> > "CakePHP" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected] For more options, visit this group
> > athttp://groups.google.com/group/cake-php?hl=en
Check out the new CakePHP Questions site http://cakeqs.org and help others with
their CakePHP related questions.
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
