In this Cool Solution series we will see how we can set up the workorder driver together with a loopback driver to activate and deactivate user accounts based on the starting date and end date of the user account.

In part 1 we will go through the basic add event of a new user.

There are some good cool solutions written about the WorkOrder driver before:

• Making Sure Your Work Orders Work!

• Cool Blog: Workorder Introduction

• WorkOrder Details

• Using the WorkOrder Driver in IDM

• IDM 3.5 Work Order Driver Example: Inactivating and Deleting Users

We will be using the WorkOrder driver and setup from the documentation Identity Manager 3.6.1 WorkOrder Driver Implementation Guide but instead of having a HR driver we will have a loopback driver providing the same functionality.

So what needs to be done?

First we need to make sure that the users are created with a loginActivationTime set, that is a normal eDirectory attribute but it is seldom referenced to in the documentation, if it is set the account will not be useful before that date. The account also needs to have a loginExpirationTime set if deprovisioning is to occur.

When that is done we can start to build the logic for the loopback driver.

The purpose for the loopback driver is to create the workorderobjects that the workorder driver monitors and to update them in case of change.

Besides that it can be utilized for all kind of maintenance, in this case maybe adding some attributes at activation time or sending an e-mail to the user and / or manager at activation time.

Here is our first rule that will create one workorderobject for each created user, it goes into the event transformation policy set of the subscriber channel:

<rule>
		<description>Create Work Order for User Add</description>
		<conditions>
			<and>
				<if-src-dn op="in-container">Idv\Inactive\newusers</if-src-dn>
				<if-operation mode="nocase" op="equal">modify</if-operation>
				<if-class-name op="equal">User</if-class-name>
				<if-attr name="Login Disabled" op="equal">True</if-attr>
			</and>
		</conditions>
		<actions>
			<do-set-local-variable name="order-dest-dn" scope="policy">
				<arg-string>
					<token-src-dn/>
				</arg-string>
			</do-set-local-variable>
			<do-add-src-object class-name="DirXML-WorkOrder">
				<arg-dn>
					<token-text xml:space="preserve">Idv\res\workorders</token-text>
					<token-text xml:space="preserve">\WorkOrder-</token-text>
					<token-attr name="CN"/>
				</arg-dn>
			</do-add-src-object>
			<do-add-src-attr-value class-name="DirXML-WorkOrder" name="DirXML-nwoContent">
				<arg-dn>
					<token-text xml:space="preserve">Idv\res\workorders</token-text>
					<token-text xml:space="preserve">\WorkOrder-</token-text>
					<token-attr name="CN"/>
				</arg-dn>
				<arg-value type="string">
					<token-local-variable name="order-dest-dn"/>
				</arg-value>
			</do-add-src-attr-value>
			<do-add-src-attr-value class-name="DirXML-WorkOrder" name="DirXML-DueDate">
				<arg-dn>
					<token-text xml:space="preserve">Idv\res\workorders</token-text>
					<token-text xml:space="preserve">\WorkOrder-</token-text>
					<token-attr name="CN"/>
				</arg-dn>
				<arg-value type="string">
					<token-attr name="loginActivationTime"/>
				</arg-value>
			</do-add-src-attr-value>
			<do-set-src-attr-value class-name="DirXML-WorkOrder" name="DirXML-nwoDeleteDueDate">
				<arg-dn>
					<token-text xml:space="preserve">Idv\res\workorders</token-text>
					<token-text xml:space="preserve">\WorkOrder-</token-text>
					<token-attr name="CN"/>
				</arg-dn>
				<arg-value type="string">
					<token-convert-time dest-format="!CTIME" dest-tz="UTC" offset="2" offset-unit="day" src-format="!CTIME" src-tz="UTC">
						<token-attr name="loginActivationTime"/>
					</token-convert-time>
				</arg-value>
			</do-set-src-attr-value>
			<do-add-src-attr-value class-name="DirXML-WorkOrder" name="DirXML-nwoStatus">
				<arg-dn>
					<token-text xml:space="preserve">Idv\res\workorders</token-text>
					<token-text xml:space="preserve">\WorkOrder-</token-text>
					<token-attr name="CN"/>
				</arg-dn>
				<arg-value type="string">
					<token-text xml:space="preserve">pending</token-text>
				</arg-value>
			</do-add-src-attr-value>
			<do-add-src-attr-value class-name="DirXML-WorkOrder" name="DirXML-woType">
				<arg-dn>
					<token-text xml:space="preserve">Idv\res\workorders</token-text>
					<token-text xml:space="preserve">\WorkOrder-</token-text>
					<token-attr name="CN"/>
				</arg-dn>
				<arg-value type="string">
					<token-text xml:space="preserve">user add</token-text>
				</arg-value>
			</do-add-src-attr-value>
		</actions>
	</rule>
	

This is a image from designer of the same rule:

Click to view.

What that rule does for us is to create a object of the class DirXLM-workorder in the context Idv\res\workorders if a user is created in Idv\Inactive\newusers and is login disabled.
The wo object will have some attributes set:

workorder cn = workorder- the cn of the user ex. Workorder-jdoe

DirXML-nwoContent= CN of the user ex. jdoe

DirXML-DueDate= loginActivationTime , this is when the wo will be executed.

DirXML-nwoDeleteDueDate= loginActivationTime 2 days, this is the time when the wo object will self destruct. It will actually be deleted by the wo driver and this is a great way of doing automatic clean up.

DirXML-nwoStatus=pending, just to tell the diver that there is work to do.

DirXML-woType= User add, this is a field you can use as a trigger field.

With that done lets see what the wo driver looks like in response to the created object.

In the command transformation policy set of the publisher channel we create a policy with this rule in it:

<rule>
		<description>Modify User on Work To Do Add</description>
		<conditions>
			<and>
				<if-operation op="equal">add</if-operation>
				<if-attr mode="nocase" name="DirXML-woType" op="equal">user add</if-attr>
				<if-class-name op="equal">DirXML-WorkToDo</if-class-name>
			</and>
		</conditions>
		<actions>
			<do-set-local-variable name="order-dest-dn">
				<arg-string>
					<token-attr name="DirXML-nwoContent"/>
				</arg-string>
			</do-set-local-variable>
			<do-add-dest-attr-value class-name="User" name="Login Disabled">
				<arg-dn>
					<token-local-variable name="order-dest-dn"/>
				</arg-dn>
				<arg-value type="string">
					<token-text xml:space="preserve">False</token-text>
				</arg-value>
			</do-add-dest-attr-value>
			<do-veto/>
		</actions>
	</rule>
	

This is a image from designer of the same rule:

Click to view.

What this rule does is that on the due date it looks for wo objects with the woType of user add and then sets the Login Disabled attribute to False.

In the next part we will start with giving the new user a password and moving the user to the active users container.

We will then see how the deprovisioning workorder will work.