As of now, no such configuration exists. But then those orphan tasks will be deleted by the cleanup escalation.
Is this not happening in your case. Check your cleanup escalation timing and criteria and see if you can reduce the number of days.
I would also recommend you to create an idea and let others vote for it.
My point is that as change request is not saved then how tasks get activated n how task users can work on them?
They should not be able work on those.
User see those tasks assigned to them in overview console.
Ashok, do you know the name of escalation?
What is the status of task request? (Staged or Assigned)?
Try these steps and let me know if they can see the tasks or not.
- Log in to the User Tool
- Open the Form - SYS:Status Query Results
- Search for the Form Name - TMS:Task
- From the search results, look for the record with the Query Description as "All Open Tasks"
- Change the field - From Status (>=) from STAGED to ASSIGNED
- Save the changes
- Flush the midtier cache
- Test the functionality
I see only 1 record for "All Open Tasks"
Is it for each task reference?
Also will it affect any "actual" tasks which are staged?
After this modification, no staged task will be shown in Overview console. It will affect all.
As task is in staged status, even though task user can see them cannot modify them until task is activated.
Thanks! I guess we will not change all tasks becaouse of little few.
I would like to prevent that behaviour though.
Thanks for all your input!
If I am reading it correct, we are talking about, orphan tasks being shown in overview console. If yes, I will think of this as a defect, because orphan tasks get deleted after sometime by escalations and also ITSM does not have tasks as an independent. So ideally the tasks can be added before saving the parent record (change or incident etc). However if the parent record is not saved, these tasks should not appear anywhere.
4 of 4 people found this helpful
If the change request is not saved, or Mid-Tier client crashes or is killed before a request is created where any task, task groups, or task group templates are created there is a field called "Parent Linked" on the associated task form that remains in an inactive state.
When any application form is submitted/created (change, incident, release.....) any previously created tasks prior to the create operation are set to "Active" because we now know that the parent request is real. Every 24 hours (the default setting within the SYS:Application Cleanup form) the escalation named "SYS:CLN:TA@00:05-StartCleanup" fires.
This escalation checks the SYS:Application Cleanup form for the retention parameter (where the form name is TMS:Task) which kicks off the filter (via a push fields operation) which will perform the delete operation on any tasks still in an "Inactive" state longer than the specified retention period.
The filter name is "INT:FNDTMS:CLN:DelTasksInactive7Days" which fires on the SYS:Application Cleanup form which then pushes the "DELETE" keyword to the z1D_Action field to any tasks that need to be deleted. The standard system filters that fire on most application forms that require a delete kick in which causes the cascading delete to the task form and any association forms for a given task.
Please close this thread if there is no further updates required.