Re: ACL and multiple groups
The permissions thing is a work in progress - eta 1 to 2 weeks. I haven't made
a navigation plug in, but revisited it last week for a current project. When
I've made the changes I need to I will create a plug in.
Jeremy Burns
Class Outfit
jeremybu...@classoutfit.com
http://www.classoutfit.com
On 18 Oct 2010, at 01:48, Michael T wrote:
> 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
> updated.
>
> Michael
>
> PS - read your blog post on dynamic navigation menus today and was
> wondering if you ever did happen to make it into a plugin?
> http://articles.classoutfit.com/2009/11/cakephp-dynamic-navigation-bars/
>
> On Oct 5, 8:31 pm, Jeremy Burns | Class Outfit
> wrote:
>> 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
>>
>> jeremybu...@classoutfit.comhttp://www.classoutfit.com
>>
>> 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
>>> wrote:
I'm generally with you on that - although it's a shame. I love the concept
but to my chagrin I h
Re: ACL and multiple groups
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
updated.
Michael
PS - read your blog post on dynamic navigation menus today and was
wondering if you ever did happen to make it into a plugin?
http://articles.classoutfit.com/2009/11/cakephp-dynamic-navigation-bars/
On Oct 5, 8:31 pm, Jeremy Burns | Class Outfit
wrote:
> 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
>
> jeremybu...@classoutfit.comhttp://www.classoutfit.com
>
> 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
> > 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...@classoutfi
Re: ACL and multiple groups
Looking forward to it!
On Oct 5, 12:58 am, Joshua Muheim wrote:
> Yay that would be great! Good luck, Jeremy!
>
> On Tue, Oct 5, 2010 at 9:31 AM, Jeremy Burns | Class Outfit
>
>
>
> wrote:
> > 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
>
> > jeremybu...@classoutfit.com
> >http://www.classoutfit.com
>
> > 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 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
> >> 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
>
> >>> jeremybu...@classoutfit.comhttp://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
Re: ACL and multiple groups
Yay that would be great! Good luck, Jeremy!
On Tue, Oct 5, 2010 at 9:31 AM, Jeremy Burns | Class Outfit
wrote:
> 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
>
> jeremybu...@classoutfit.com
> http://www.classoutfit.com
>
> 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 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
>> 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
>>>
>>> jeremybu...@classoutfit.comhttp://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 faste
Re: ACL and multiple groups
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
jeremybu...@classoutfit.com
http://www.classoutfit.com
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 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
> 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
>>
>> jeremybu...@classoutfit.comhttp://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 choi
Re: ACL and multiple groups
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
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
>
> jeremybu...@classoutfit.comhttp://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 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 dep
Re: ACL and multiple groups
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 jeremybu...@classoutfit.com 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 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 ) - 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 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 cake-php@googlegroups.com > To unsubscribe from this group, send email to > cake-php+unsubscr...@googlegroups.com For more options, visit this group at > http://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 cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: ACL and multiple groups
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 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 ) - 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 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 cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
ACL and multiple groups
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 ) - 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 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 cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: ACL and Multiple Groups
> Is there a way for a user to be part of multiple groups? Yes and no. ARO's and ACO's are organized in a tree-based fashion, so if a node is a child of another node, it inherits that node's permissions as well as the permissions of any node which the parent node is a child of. However, the concept of a node being the child of more than one parent does not exist within the system. > my understanding of windows is, a deny > is teh most powerfull. ie, if one permission says you are denied, the > even if another says you are permitted you are still denied. That sounds like a very inflexible system. Cake's ACL system works off of a similar 'default deny' premise, but it allows you to, for example, deny permissions on an object to a group, but allow permissions on an object to a specific user in a group. By default, users will inherit the permissions settings of their parent node, but you can override any setting at any level. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
ACL and Multiple Groups
I was looking throught the ACL documentation and became very interested in using it. My question is as follows: Is there a way for a user to be part of multiple groups? for example, if i have a user named john, i want him to be in both the UsersA and UsersB group. PageA which allows UsersA should allow john in. what would happen if UsersB is denied from PageA and john tried accessing it? would it act like windows? my understanding of windows is, a deny is teh most powerfull. ie, if one permission says you are denied, the even if another says you are permitted you are still denied. thank you etaham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
