The process basically contains two steps:
- Creation of a custom resource object that facilitates the request and approval workflow
- Creation of a provisioning workflow that sets the group membership
The child table manipulation can be done either through the APIs (see below) or by target system group memberships through access policies
The API that will let you do this is in the tcFormInstanceOperationsIntf class and the methods are called addProcessFormChildData and removeProcessFormChildData.
If for example you would like to support request based addition to AD groups and already have one of the later versions of the AD connector installed you would need to do the folowing:
- Create a new RO called "AD group membership add"
- Add an object form that lets the user indicate what AD groups they would like to become member of.
- Add a process form and data sink or prepop from the object form
- Add approval process (if needed)
- Add provisioning process that basically calls a task that uses the addProcessFormChildData AD group identifier (group name if I remember correctly) to the AD group childtable that is attached to the main AD resource object.
There is a couple of downsides to this approach that are worth mentioning. As you are using a single RO the resources view of the user will show up as a collection of "AD group membership add" resources. The name of the group is available on the process form but it is not directly visible to an admin without an additional click. Likewise if you use attestation (access recertification) the attestation events will be less than helpful for the certifier as they only see the resource name. Same thing for certain out of the box reports.
Code example for adding rows to a child table of a process form
Thanks Martin. This blog is very good.
ReplyDelete- Karthik