Re: Complex ACL Auth
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Complex ACL Auth
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 -~--~~~~--~~--~--~---
Re: Complex ACL Auth
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 -~--~~~~--~~--~--~---
Complex ACL Auth
I was hoping to get good pointers as to the best way to tackle our problem: We have 4 roles. (4 'aros') However, the permissions depend on the project status. While the status is 'draft' some aros can edit/delete etc. But when the project status is submitted or finalize, the permissions would change to only allow view. Our How would you approach this within the ACL and Auth in CakePHP 1.2 RC2? Thank you. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Complex ACL Auth
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
