> (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.
--
Brian Beck
Adventurer of the First Order
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
