I wrong? This seems like it should be a common use of ACL:
Let's say you work for CRM R Us and have a multi-corporate CRM app:
John is a Client Manager who works in Marketing for IBM (usergroup =
Manager)
Rob is an Artist who works in Marketing for IBM (usergroup = User)
Janet is a Parts Manager who works in Parts Warehouse for IBM
(usergroup = Manager)
Bill is a Client Manager who works in Sales for Coca Cola (usergroup =
Manager)
Sally is a Client Executive who works in Sales for Coca Cola
(usergroup = Manager)
Fred is an Executive Travel Assistant who also works in Sales for Coca
Cola (usergroup = User)
Jennifer works is a Support Technician in IT for CRM R Us (usergroup =
Admin)
John can create and edit contacts and companies that belong as
customers to IBM
Rob can only view companies that belong as customers to IBM
Janet can view but not edit, only companies and contacts that belong
as SUPPLIERS to IBM
Bill can create and edit contacts and companies that belong as
customers to Coca Cola
Sally can also create and edit contacts and companies that belong as
customers to Coca Cola
Fred can view but not edit contacts and companies that belong as
vendors to Coca Cola
Jennifer can view but not edit all contacts and companies both
suppliers and customers for both IBM and Coca Cola
So for ACL to handle this correctly, it would need to support having
AROs exist in more than one group (three in this case, Company,
Department, and UserGroup) and then it needs support having ACOs exist
in more than one group (two in this case: companies and contacts would
be categorized under both Company and Department), and then grant
access based on examining the permissions for all instances of the
ARO.
In other words, from the example above: John's user id is found under
three separate ARO groups: Company/IBM, Department/Marketing,
UserGroup/Manager
When pulling up, say, a contact record in the application, in order to
determine if John has access, we need to see if the record is also
under Company/IBM and Department/Marketing. The final piece of the
puzzle then is examining what kind of access UserGroup/Manager has on
contact records.
From trying to get ACL working the way I want, it sure doesn't look
like it supports something like that.
On Sep 28, 2:18 pm, calzone <calz...@gmail.com> wrote:
> So the answer to my first question is that apparently you can't use
> actsAs = array('Acl' ...) and define more than one form of 'Acl' -- I
> tried every combination of nested arrays I could think of and it never
> worked. It looks like I have to choose one (in my case that will be
> the ARO table), and then manually update the other (ACO) in the
> controller.
>
> Next up: can I get the groups to work with the departments as AND
> permission conditions? If anyone has any insights to share, please
> do.
>
> On Sep 28, 10:14 am, calzone <calz...@gmail.com> wrote:
>
>
>
> > I apologize for asking this before trying. I haven't yet had time to
> > get to this and I'm curious if there's a quick answer that will save
> > me some time. Otherwise, I will test it out and report back later.
>
> > Question:
>
> > A user belongs to one or more departments.
> > Projects belong to a department.
>
> > Any user that belongs to department A should be able to access any
> > projects that belong to department A. Conversely, the user should not
> > be allowed to access any projects that belong to a department the user
> > is not also a part of. I wanted to see if I could define the behavior
> > for department to act as both an ACO and an ARO so that it updates the
> > ACOs and AROs automatically whenever a department is created or
> > updated.
>
> > ***
>
> > Bonus points:
>
> > My ACL is actually more complicated than that. The user belongs to a
> > user group as well as a department. The group defines what CRUD
> > actions the user can do in absolute terms. For example, admins are
> > allowed to create and edit company records, but users can only view
> > them. What makes it more complicated is that AMONG those absolute
> > permissions, which specific records you are allowed to edit or view
> > are filtered by the department criteria above.
>
> > So the user belongs to one or more departments, and the user belongs
> > to a single group. Access is dependent on both department AND group.
> > That means in the ARO table, I would see the same user appear under
> > two different branches (one branch is for all departments, and the
> > other is for all groups). The trouble is that I predict this means ACL
> > will see the user in either one OR the other and give much higher
> > permission than desired. In short, I'm hoping for an AND link but
> > expecting it will only do OR.
>
> > ****
>
> > Super bonus points:
>
> > My ACL is currently keyed off of just group. I see that ACL queries
> > easily outweigh all other queries in terms of time eaten up. I'm
> > wondering if, even were I to succeed in making my complex ACL tree
> > above work correctly, would the performance hit make it infeasible?
> > Should I just hardcode some things instead?
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
No comments:
Post a Comment