It's been noted time and time again that IG&L does not allow for changing the fulfillmentdate of a request. I saw no specific reason why not so I set out to try and setup something that would allow this and a few hours later a POC was working. In this discussion I'll write up what and how I succeeded, list some pros and cons that I can see and then hope for the community to come back with comments on things I've missed or done well. I'll also mention some of the dead-ends I ran into during development. Some of this will be obvious to anyone who has spent more than 5 minutes with the product and some will be a little more advanced. Since this is my text, that's how it goes.
First up, the premise:
When creating a request, in the final page the user has the option to set a Revocation Date. As IG&L does not handle multiple fulfillment dates for a single request, a new request is created for the revocations if a Revocation Date is set. These two requests get the same data, such as notes and description as well as any custom attributes which may have been configured and set. Once created there is no way to change most of the data for either request. Name description and notes as well as anu custom attribute set to be editable. None which affect the execution of the request. That's the first problem: how to change that which cannot be changed.
Once the request is created, a workflow process is created with the relevant data including the fulfillment date. Which is problem number two. Even if we could change the fulfillment date on the request, this would not be reflected in the contained context of the workflow.
When the wait for fulfillment date starts, the entire workflow is paused in a sense. This leads to the third issue. Even if we can change the fulfillment date, and get it reflected in the workflow, the fulfullment node will not start to wait for the new date as it already knows how long to wait.
- Change fulfillment date
- Reflect in workflow
- Update Delay node
All of which impossible out of the box for IG&L, but quite possible to work around.
My first idea was to configure a custom attribute to store the revocation date and keep it editable. This was problematic for atleast one major issue: There would end up being two fields to enter revocation date and, knowing users, this would never work properly. I could hide the original field for revocation date, but this would mean that no revocation request would be created. I would then need to copy this field to the real field or have the delay node respect my custom attribute and there would still be the issue of two fields for fulfillment date. This approach had too many problems and was swiftly considered a dead end, I need something better.
I began looking in the database at the table for change requests, which has the column of delay_date which holds the date for the delay node. As there are no direct ways of changing this from the UI, I began with changing it by hand using my favourite database manager. No errors so it is a possible way forward, but I cannot expect end users to change the database and I definitely don't want to give them full access to the database. Fortunately, there's the option of forms. I created a form with two fields, "Change request id" and "fulfillment date" and set it to use a custom fulfillment workflow which updates the change request with the new date. Success! Part one solved.
For updating the workflow context, I could probably keep looking in the database for the relevant tables, work out how they operate and continue to fiddle with SQL and for a long time. I've spent a fair amount of time in the database but the workflow parts are still a mystery to me. Fortunately I knew from another client that the delay nodes can get their target date from SQL. A useful trick when you need the workflow to sleep for a few seconds. Since we now have the new fulfillment date on the change request and also know the change request id we can have the delay node look up the target date directly on the change request and not rely on the context variables. Great! Part two bypassed.
But what if the workflow is already at the delay node waiting for its date? This is a problem. Once the delay has started, it does not care for anything but waiting for the target date. We can however restart the node. Using a select node to check if the fulfillment date on the change request is in the past or future, we can either allow the workflow to continue to fulfillment or sent it back to the delay node which now makes a new lookup of the fulfillment date and starts to wait for the new target. Fantastic! Part 3, worked around.
Improve the form to use a dropdown with webesrvices to only get the relevant change requests and possibly restrict it to only return the change requests the user has access to.
Add a comment in the notes whenever a change is requested about who requested the change, and what the date was before and after.
My take on the solution:
Modification of internal tables
Use with care and make sure to lock it down. Restict access to the form and make sure whoever has access to the form knows what happens.
A new workflow with two nodes, updating the database and "Mark verified". Slightly higher maintenance and another item to test when upgrading and patching
Delegation only was copied and modified with an additional 2 nodes and the Fulfillment Date node is changed to use SQL instead. This will also require testing when patching and upgrading.
What are your thoughts?