What is a one sentence summary of your feature request?
Document the scripting runtime environment.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
We are able to see only that a DTM object is exposed, and there are 4 optional ‘tools’ that can be imported. We also know that three objects from the Imanami.DTM namespace are imported. None of these objects/classes/etc have any documentation about what methods or properties are present. This almost makes the scripting capabilities entirely useless. Additionally, in V11, a python scripting option was added, but with even LESS documentation. Not so much as a v10 example script (obviously since V10 didnt support python). The only way that I am aware of to move an object in AD is with scripting and the activedirectory tool, but there is no documentation at all for that tool.
How do you currently solve the challenges you have by not having this feature?
The workaround in place at this point is to put MOST of the logic into the SQL view that feeds into groupid, but there are still decisions that need to be made in runtime based on information that is not available in the SQL database. For instance, checking to see if the samaccountname collides with an existing user, or checking if the user is already in the correct OU etc. So far I don’t have a workaround for all of the edge cases, but I am able to handle the samaccountname collision issue. Now that the scripting environment has been excised entirely from the product this documentation becomes even more critical since we would need a way to test a script before having groupid attempt to run it. This is especially due to the groupid runtime environment not logging anything about what actuall caused a script to fail, just a vague reference to check the logs.