Looking forward to it! On Oct 5, 12:58 am, Joshua Muheim <psybea...@gmail.com> wrote: > Yaaaaay that would be great! Good luck, Jeremy! > > On Tue, Oct 5, 2010 at 9:31 AM, Jeremy Burns | Class Outfit > > > > <jeremybu...@classoutfit.com> 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 > >> <jeremybu...@classoutfit.com> 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 <jeremybu...@classoutfit.com> 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.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@googlegroups.com > >>>> To unsubscribe from this group, send email to > >>>> cake-php+unsubscr...@googlegroups.com 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@googlegroups.com > >> To unsubscribe from this group, send email to > >> cake-php+unsubscr...@googlegroups.com 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@googlegroups.com > > To unsubscribe from this group, send email to > > cake-php+unsubscr...@googlegroups.com 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 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
