Jeremy, I need something like this for a project as well. I'm glad I
haven't yet started trying to figure out how to incorporate ACL into
my project, because it seems like it would be a lost cause!
What I'm after is something pretty simple like the permission schemes
in JIRA (issue tracking software) - you have users, groups and roles
(which came after groups in JIRA's development; sort of groups on a
per-project basis), and you can assign permission to perform certain
operations to either a user, group or role.
Very interested to hear back on what you come up with. Keep us
PS - read your blog post on dynamic navigation menus today and was
wondering if you ever did happen to make it into a plugin?
On Oct 5, 8:31 pm, Jeremy Burns | Class Outfit
> I'm going to roll my own and if I am successful (which I have to be because I
> need this to work) I'll publish the code.
> Jeremy Burns
> Class Outfit
> On 4 Oct 2010, at 19:39, calzone wrote:
> > 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 andACLpermissions would allow access based
> > on belonging to the department
> > * you would think that for every record created by a user,ACLwould
> > 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.
> > ButACLcan 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 intoACL
> > 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 makeACL
> > 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 thatACLwas some lofty complex and
> > powerful permissions tool.
> > On Oct 4, 10:06 am, Jeremy Burns | Class Outfit
> > <jeremybu...@xxxxxxxxxxxxxxx> 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 theACLtables 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
> >> jeremybu...@xxxxxxxxxxxxxxxxxxx://www.classoutfit.com
> >> On 4 Oct 2010, at 17:55, calzone wrote:
> >>> The most maddening thing aboutACLis that it is so close yet so far.
> >>> If ever there was something you could call half-baked,ACLis it.
> >>> What you seek is the kind of thing it should handle easily out of the
> >>> box, yet it can't. Cake'sACLfeels like it was a brilliant thought
> >>> started by someone on the team who never finished it and no one else
> >>> wanted to touch it. ACLis 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 useACL... 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 <jeremybu...@xxxxxxxxxxxxxxx> 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 usingACL(although I've never really 'got'ACLbefore
> >>>> 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'sACL, which is the best guide to
> >>>> refer to (not the online book - I know about that)?
> >>> Check out the new CakePHP Questions sitehttp://cakeqs.organdhelp 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 cake-php@xxxxxxxxxxxxxxxx
> >>> To unsubscribe from this group, send email to
> >>> cake-php+unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group
> >>> athttp://groups.google.com/group/cake-php?hl=en
> > 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 cake-php@xxxxxxxxxxxxxxxx
> > To unsubscribe from this group, send email to
> > cake-php+unsubscribe@xxxxxxxxxxxxxxxx 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
To post to this group, send email to cake-php@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
cake-php+unsubscribe@xxxxxxxxxxxxxxxx For more options, visit this group at