Thanks for the reply, > permission changes are diffent thing... the compiled > permissions are intended to be notified and recalculated > whenever the permissions for any of the principals it > has been created for is modified. if that doesn't work > it's a bug. Agreed. I think permissions changes for existing principals are working fine. > > what the TODO refers to is: > the permissions are compiled for the set of principals > that have been set to the Subject (most probably upon > login). the default implementation retrieves the set > from the principal provider configured for that login > module... that's the reason for my doubts... forcing > the recalculation of the compiled permissions was > more or less straight forward: close the existing one > and create a new one with the new set of principals. The issue we have is that Sling maintains a session pool - we'd need to ditch the entire session pool every time a new group was created in order to be sure everyone was working with the same set of permissions. Having recently-logged-in users see a different world to everybody else is causing a fair bit of confusion.
I can try raising the issue with Sling. It might be that the best approach is to have the session pool listen for principal creation / removal. I just wanted to be sure that there wasn't a less expensive approach first. Thanks again for the help, Arthur
