Hi!

If you created the action using the admin-generator, you could have a
look at 
http://www.symfony-project.com/uploads/assets/sfAdminGeneratorRefCard.pdf
.
Fields can also have a credential attribute, so you could deactivate
the ID property for members.

The best way might be:
- overriding the used select method in the Peer class: add a Criteria
for the ID depending on the user credentials
- overriding the the doInsert and doUpdate methods of the Peer class:
they should check whether the current user has the credentials to
change the object


On 21 Apr., 01:48, adventex <[EMAIL PROTECTED]> wrote:
> Using sfGuard I have configured various credentials that a user might
> have: members, employees, admins.
>
> For a given action: member/edit, I want admins to be able to always
> execute this action, and for members I want them to be able to access
> this action only for their own id. Simply setting credentials for this
> action in security.yml will certainly handle the case for admins but
> it doesn't for a member who should only be able to edit their own
> account.
>
> The obvious solution is to allow both member and admins permission to
> the member/edit action and then code a special case where it checks
> that the member's editing their own data however this is not a clean
> way to set this up as I'll have many other actions needing this same
> special case.
>
> What is the best way to handle this case?
> Is there a way to augment symfony's security filter?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony users" 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/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to