On 03/30/2012 03:50 PM, Scott Seago wrote:
Rather than paste in the entire text, I'm just linking to the
writeup. Please read the whole thing first and if you want to comment on
anything specific, quote it and comment on this thread.
In order not to tie conductor to LDAP for all installations, it
should be a site-wide configuration whether groups come from LDAP or not. We'll need
the conductor UserGroup/membership model anyway for joins in permission queries, so this
configuration will simply determine how the group membership is maintained -- via LDAP
hooks or via UI actions.
Is there any reason why we do not want to support both
cases at the same
time? Probably it would be a better user experience to let the user have
both and indicate the source of a given group in the UI. If we define 2
different scopes on UserGroup (user_defined, ldap_imported), it won't be
much pain to handle both of them.
There are a couple of options available for keeping the UserGroups in
sync with LDAP groups:
* Use delayed_job, cron, or something similar to re-sync on a specified schedule
* Sync on use (with a pre-defined "minimum time between re-sync calls")
would suggest a third approach: there could be some kind of auto
re-sync mechanism, and the user would also have to option to request an
update if he doesn't want to wait for the autoupdate to be called.
The main advantages of sync-on-use are that 1) we make the minimum
number of re-sync calls that still guarantees the data is fresh and 2) we don't
require any external scheduling infrastructure. The main disadvantage is that the first
permissions check after an idle period greater than the refresh interval (or one check per
interval period if the server is under active use) will take longer than usual to return,
as it has to wait for the LDAP group membership queries, any necessary writes for data
changes, and the permission denormalization hooks for any changes to cascade down the
object inheritance hierarchy. If this takes a long time with large datasets (many
instances, images, users, etc), this will impact performance in a user-visible way.
To eliminate the downside of updating on user input, we could use
delayed_job for that, too: instead of re-syncing with the ldap server
during the request, we could just create a delayed_job task for that,
inform the user that the background job has been created through a flash
notice, and wait for the next available worker to pick up the task and
do the autoupdate asynchronously.