Thanks Mark, The permissions are based on 2 things. 1. The status (state) of the project. 2. The user roles. (user can have multiple roles, but most of the permissions would be set this way)
If it was one or the other, we would be ok using the built in ACL, but since we are running permissions on 2 distinct processes, we're not sure of the best way to approach that. IE: An "approver" cannot edit a project, only a "reviewer" - so permissions are mainly set that way (by user roles). However, the reviewer can only edit the project as long as he hasn't submitted it. So it is a completely different set of permissions based on the status as well. On Aug 29, 11:06 am, mark_story <[EMAIL PROTECTED]> wrote: > On Aug 29, 1:16 pm, Colombian <[EMAIL PROTECTED]> wrote: > > > > > We don't want anybody to do it for us - just a ideas on what the best > > approach would be. > > The Aros are: > > Reviewers > > Approvers > > Administrators > > Seniors > > > The ACO on the other hand is where things get tricky, so we're just > > trying to get ideas, not code. Because in theory we have 2 separate > > ones. > > The normal one would just have the models to control access to the > > CRUD. > > The normal ACO would include things like: > > Projects > > Proposals > > BudgetWorksheet > > Etc. > > > However, we would want to restrict access to Proposals based on the > > Proposal.status > > So Full CRUD access on the ACL most of the time, but when the > > Proposal.status = 'submitted', the CRUD privileges would be gone, and > > they could only view that. > > > We're just thinking of rolling our own thing on top of the Auth/ACL, > > but we're even considering dropping the use of the ACL since it > > doesn't seem to be flexible on that way. We've been rolling our own, > > but we were going to test out 1.2 Auth/ACL. > > > Since we're also assuming this is a fairly common scenario, we were > > hoping someone could point us in the right direction. > > The common scenario being - a web application that changes permissions > > depending on the status of whatever important item. Like you can only > > edit certain things before they are finalized. As I said, we are > > comfortable rolling our own, we're just trying to get ideas for how we > > would roll this using Cake's things. > > > On Aug 28, 4:45 pm, Rafael Bandeira aka rafaelbandeira3 > > > <[EMAIL PROTECTED]> wrote: > > > Paste your code and your approach, a test approach at least. I don't > > > think someone will actually *do* it for you. But many people can point > > > out what you're missing > > Are all your permissions based on the state of the Project? If so > make 'project states' aros and do your perms there. So you could get > a project, get its status and do an acl check then. Remember that if > you build your Acl carefully / properly it can be used for much more > than storing users/groups and controllers/actions. > > -Mark --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
