Brian Beck wrote:
>> (I'd have to do
>> string transformation on every permission, and it wouldn't be indexed
>> as efficiently).
>
> Forget this part, storage stuff is taken care of by the remote
> provider, not my model. Here's a clearer example of why fitting group
> roles into Identity might not be so easy:
>
> Is this person the president of the TurboGears club?
> All(has_permission('president'), in_group('Turbogears Club'))
> This won't work because it will succeed if the user is president of
> another club.
>
> Okay, use tuples for permissions instead...
> has_permission(('TurboGears Club', 'president'))
> This works.
>
> But then, granting access based on holding a role in any group...
> Is this person the president of any clubs?
> has_permission((*BZZT! Doesn't work with tuples then...*, 'president'))
>
> Soooo, if I write my own provider model, I guess I could check the
> types of the arguments for when it determines if a user has a
> permission (tuple vs. string)... but I think extending the identity
> model to support group roles more "natively" might be not much more
> work and would help people in my situtation. (*gears turning*)
>
> Anyway, back to codin.
Take a look at TurboPeakSecurity[1]. It might prove better suited to
your needs.
Cheers,
Simon
[1]
http://groups.google.com/group/turbogears/browse_thread/thread/bcbac0746978887d/50b3df27e97e13a6
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" 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-trunk
-~----------~----~----~----~------~----~------~--~---
