I'd like to require a CR on a Task based on the Component part of a Release. I don't want to turn on change_request required for the whole db. I thought maybe I could use a trigger but the tech note says:
"The pt_transition section is especially for the transition of PT related objects (problems and tasks). After the status of a PT object has been changed, scripts in this section are called. This means that there is no pretransition for PT objects".
So, this seems to mean I couldn't check the change_request attribute before the task transition and prevent it from happening. True?
Pinned topic Trigger to check if change_request is filled in on task, Synergy 7.1
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-08-13T22:47:27Z at 2012-08-13T22:47:27Z by oldchevy
David.Honey 270001UEBC176 Posts
Re: Trigger to check if change_request is filled in on task, Synergy 7.12012-07-17T08:26:52ZThis is the accepted answer. This is the accepted answer.Hi Terry,
You can require that a task has an associated change request without using triggers. See http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14629777 and https://www-304.ibm.com/support/docview.wss?uid=swg21325257&wv=1. It is also described on page 25 in Default Settings.
Re: Trigger to check if change_request is filled in on task, Synergy 7.12012-07-17T15:07:28ZThis is the accepted answer. This is the accepted answer.
- David.Honey 270001UEBC
Thanks, but setting change_request as a required attribute sets it for the whole db. I wanted to use a trigger to require a change request only on a certain Component of a Release number.
David.Honey 270001UEBC176 Posts
Re: Trigger to check if change_request is filled in on task, Synergy 7.12012-07-24T09:23:03ZThis is the accepted answer. This is the accepted answer.
- oldchevy 2700029178
I think there are two issues to address: timing, and checking the data.
For timing, the reason there is a pt_transition is that in some cases task attributes entered by the user for some task operation that involves a change of status might not be saved until after the state transition. So a pre-trigger might see the task data as it existed before those changes were applied. However, the task's change request is not represented as an attribute, but as a relation from the change request to the task. I don't know when this relationship gets created. However, if you are checking for task transition from task_assigned to completed, it might be satisfactory to require that the relation exists before the user attempts to complete the task.
For checking the data, the issue is that the data you want to check is a relation not an attribute, so cannot be directly passed in as a parameter to the trigger. A trigger cannot directly use ccm CLI commands. So I think the script would need to start a CLI session, then use that session to check for the associated_task relationship to that task, then stop the session. Of course doing that will make the attempted task transition much slower than would be the case without the trigger.
If you cannot get this to work, you might consider an alternative approach. For example, you could have a script that queries for tasks in completed state with some properties that do not have associated change requests, then email the owner or completor of the task asking them to associate it with a change request. The user would be encouraged to do so to avoid getting emails each time the script ran as a cron job.