Linicks wrote:
>
> 2)Grant Specific rights on objects, "schedules" , that the user
> owns. Here are some scenarios:
> - Lest say that user A would like to give user B the ability to view
> their schedule, but nothing else.
> - User A would like to give user C the ability to view and edit their
> schedule.
> - User B would like to give everyone the ability to view there
> schedules(make it public).
>
There are some "built-in" identity conditions ('in_group',
'not_anonymous', 'has_permission'), but there is nothing preventing you
from setting up your own conditions. If you had a function called
"can_view_schedule", and that function determined whether or not
another user could see a particular schedule, you could then decorate
your controller like:
@expose(template="some_template")
@identity.require(can_view_schedule())
def show_schedule(self):
#your logic
Of course, the logic to 'can_view_schedule' is specific to your app,
but once you set it up, identity can use it pretty seamlessly.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---