[patch] Assign to mod: get valid users from specified Active Directory group(s)

[Morris]

(I ​mentioned this on an existing ticket relating to Assign To functionality)

Summary: you're serving on Windows and want to get your list of assignable-to users from Active Directory groups that you specify.

Requires:

• Windows-based Trac installation;
• Trac ≥0.11dev-r5883 (might work with lower revs, but this is what I built from);
• LDAP/Active Directory server available that has the groups w/users defined;
• pywin32 and ​active_directory modules installed

Several new [ticket] keys are used by this code:

[ticket]
## this is a variant of the trac default restrict_owner 
##  flag -- instead of restricting ticket assignments 
##  to people who have logged in, it restricts assignments 
##  to members of the LDAP groups specified in ldap_valid_owner_groups (below)
ldap_restrict_owner_by_groups = true

## this is the LDAP user object attribute to use in the 
##  drop-down list -- e.g., sAMAccountName, uid, etc.
ldap_show_user_attribute = sAMAccountName

## ldap_valid_owner_groups should be a comma-delimited 
##  list of group CNs from your LDAP/AD 
ldap_valid_owner_groups = IT Apps Dev,IT Apps Support

Given the above configuration, the AssignTo dropdown on a ticket would now list the sAMAccountName of each user in each of those groups (where the users are UNIONed using sets, so there shouldn't be any dupes).

CAVEATS

• the patch I've submitted adds imports for both ​active_directory and pythoncom (a pywin32 component) to /trac/ticket/default_workflow.py, with no error handling and no platform checking — this definitely needs to be added, but I wasn't sure if there were any conventions or what. Put another way, if you apply this patch and you don't have both ​active_directory and pywin32 installed, trac (in all likelihood) will not work at all
• I have not done extensive testing with this, so please give it a spin and either post any problems you have or upload a tweaked patch

NOTE: If your AD server requires authentication for read-only access (e.g., searching), then you will need to tweak your Windows Apache service to run as an authenticated user, not under the SYSTEM account (which is the default).

[Emmanuel Blot]

Note: at least the LDAP part should be implemented as a plugin, not in Trac core.

[anonymous]

Replying to eblot:

Note: at least the LDAP part should be implemented as a plugin, not in Trac core.

Gotcha. After further reflection however, I'm thinking this functionality would be a more appropriate submission to ​trac-hacks. I'll stew on whether or not to rewrite this as a plugin or just stick it on trac-hacks (and see if anyone else on t.e.o has any other input in the meantime…)

[Emmanuel Blot]

I think this feature is tied to IUserDirectory interface. Really need to implement this long lasting ticket…

[Morris]

Replying to eblot:

I think this feature is tied to IUserDirectory interface. Really need to implement this long lasting ticket…

Absolutely. I read over all the IUserDirectory interface info I could find before spending much time on this work, hoping that there was something more to start with. Along those lines, I'm more than willing to help out in either a development and/or testing capacity with the IUserDirectory effort.

[ThurnerRupert]

does this also work on unix, connecting to the windows ad?

[Morris]

Replying to ThurnerRupert:

does this also work on unix, connecting to the windows ad?

Well, there's no reason that just connecting to a Windows AD shouldn't be able to be done from *nix …but this particular patch isn't *nix compatible, as it requires a Windows-only module, pywin32.

I'd love to be able to not have to depend on the active_directory module (and, transitively, the pywin32 module), but I'm an LDAP noob. Perhaps someone else can take this patch as a starting place and replace the Win32-dependent pieces with OS-independent code …or maybe when I'm less of an LDAP ignoramus I'll come back and do it.

[Emmanuel Blot]

Replying to Morris:

I'd love to be able to not have to depend on the active_directory module (and, transitively, the pywin32 module), but I'm an LDAP noob. Perhaps someone else can take this patch as a starting place and replace the Win32-dependent pieces with OS-independent code …or maybe when I'm less of an LDAP ignoramus I'll come back and do it.

Have a look at the ​th:wiki:LdapPlugin if it can help

[Morris]

OK — I've revisited this concept. What I really needed was some generic way to allow specification of the users available in the "Assign To" dropdown — so I've created a plugin that does just that. The general idea is that after installing this plugin, which I'm calling FlexibleAssignTo, you write your own plugin that implements a getUsers() method that is called by FlexibleAssignTo. Your own getUsers() method can get a user list from wherever it needs to — in my case, that's LDAP/AD, but you could write your getUsers() to return users from wherever.

As luck would have it, trac-hacks is down — so until it's back up and I've got a proper plugin page in place, check out the ​FlexibleAssignTo thread on the trac-users list.

[sid]

Good concept, and glad to see it go into a plugin. Did you ever get this on TracHacks? If so, can you provide a link here and then we'll close this ticket?

[Morris]

Aye: ​http://trac-hacks.org/wiki/FlexibleAssignToPlugin

The plugin ended up being different than what I originally described here; namely, it allows you to write a (relatively) simple additional plugin component to provide access to the user data source of your choice — LDAP/AD or otherwise. The plugin comes with example code as well.

[sid]

Thanks for the plugin link. Closing.