It doesn't look like what I'm seeking is possible with cake's ACL. Am 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 <[email protected]> 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 <[email protected]> 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 [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
