[geeklog-devel] For my friend, Vinny
vfuria at gmail.com
Thu May 29 18:17:01 EDT 2008
Like in GL 1.4.x, you'd have to resolve the total set of group membership
before doing the query. Since you're caching credentials anyway, you could
cache the total group membership as well. So, in your example, a user in
group 3 would have a total group membership of 3, B, 2, 1, A. The the query
would check for rights for all those groups, and "and" the results together
(getting the highest level of access granted to those groups).
There a couple of levels where we can cache this data. It probably makes
sense to keep it denormalized in the user table or the group table and
update all users when a group memberships are modified. It can also be
cached in the session, but then you run the risk of updating groups
membership not being recognized until the session expires.
Let me know if additional/better explanation is needed. I'm not sure I did
all that good a job of describing what I meant.
On Thu, May 29, 2008 at 2:57 PM, Tony Bibbs <tony at tonybibbs.com> wrote:
> Lol, so we are getting serious for the GL2 alpha and the ACL stuff is
> mostly done minus one real PITA. For reference there's been this page:
> So we've done some incarnation of everything there minus the last section
> "Selecting Multiple Items Based on Permissions"
> Any chance you have the "how" part of that? My brain is hurting. Why:
> Groups can be tied in a complex web (not necessarily hierarchical). For
> Group B belongs to Group A
> Group C belongs to Group B
> Group 2 belongs to Group 1
> Group 3 belongs to Group 2
> Group 3 belongs to Group B
> That's a worst case scenario but me-thinks it'd be awful hard to do in SQL.
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geeklog-devel