I’ve installed RT-Extension-LDAPImport and was reading the README.
What jumped out at me is
that there is both a script to run (presumably to bulk-load
identities) and a plug-in. I was
expecting to see a script, but a plugin was unexpected, which lead me
to wonder if this module
is both a method for importing users from ldap, and an on-the-fly
user-creation tool too? If so, that implies I don’t need the 3rd party
ldapauth plug-in I
already have installed. (I’d rather use a module from Best Practical
if I had a choice).
If you look at the script, it is 23 lines long. The plugin is where
the import code is stored and organized, the script is just a wrapper.
I saw that and I get that the script is a wrapper.
What I was wondering is why the import code is stored in a plug-in and
loaded as a plug-in, but I think I figured it out. Basically the import
code is working against the objects and subsystems in RT, and needs those
objects to exist before it’s loaded, so you load your import code indirectly
via by simply loading the RT runtime via the RT Module, which inspects
RT_SiteConfig.pm, initializes the environment, and then eventually loads
your plug-in, thus making your code available to your script within the
context of a complete RT runtime environment.
Okay, so I get that now.
Once I configured the script the first thing I wanted to do was “test the
config”. I was extremely surprised to see there is no “look before you
leap” flag. Rather, just a comment advising “back up your database first”,
which has this sense of playing russian roulette with a revolver with no
empty cylinders. Having looked at the code I can see some ways to work
around that. Not cleanly, since “fetch users” and “load users” are sitting
inside one api call but it shouldn’t be hard to change that.