Did you try with refresh table option in Reletionship tab...
Also let us your enviornment details .......
thanks for your concern.
Well, I always refresh the table and the entire incident as well. But the problem still persists!
We have checked the Filter and API logs, but no luck.
We use Arserver 7.5 Patch 007.
ITSM 7.5 Patch 007.
Did u change any workflow?You can trace out the log where details are getting from a back end form to table list..
Ya we have cheked all the logs but didnt find anything in it.
I thing the problem is with table refresh .I mean table that shows child incidents is not reflecting.
If I open that child ticket it shows me the status as Resolved.
Actually the entries coming in the table from HPD:Associations, and may status is not updated there after you resolve the ticket.
Indeed, BMC told us it was for performance reasons. I think there is an escalation that does that job.
FND:ACT:IM1-ProcessUPDATEASSOCIATIONSTATUS (not sure of the writing).
There is an interval on it and a run-if for that.
I checked this escalations but still not getting the exact reason for this issue.
I have checked HPD:Association form in which End date field is also taking time.Because of that status is not getting updated in that table.
Which is the activelink/filter/escalation running on clicking refresh on association table?
Refresh button will only refresh the table, not the values
I faced this problem in the past. In my case it was enough to follow KA353953. All about is to change RunIf in updating escalation FND:ACT:IM1-ProcessUPDATEASSOCATIONSTATUS:
((('Action' = "UPDATEASSOCIATIONSTATUS") OR ('Action' = "CALCULATE_SLMDATES")) OR ('Action' = "UPDATESLMREASON")) OR ('Action' = "BRCAST-STAMP")
This is for version 7.6 but as I remember it works also in 7.5. At least worth to try
I have a smiliar problem and I was never able to resolve it. I am still trying to find the exact steps to re produce the issue at will. I believe that the filters that update the Associations table (Execution Order 560 or 570, I am not sure at this moment) are being skipped because of a filter that has a goto action.
This is just a hunch. Can you please let me know what you find?
we had the same proble but it got resolved as escalation HPD:IPC:TriggerProcessControl was not getting called in logs
check which form the filter, HPD:IPC:ResolveDuplicates_200_CallGuide, is fired. It is On Modify HPD:IncidentProcessControl.
I checked into the filter log, I saw that there is a "SET on HPD:IncidentProcessControl" operation. i.e. there is an update to the record.
Then we come to know that we need to add this escalation in pool..
I think this will be helpful for you to debug more..
One more thing need to rememeber here that aifterresoving parent ticket wait for some time(more than a minute) and then reopen parent ticket..
Let the escalation fire,resole child status also
Just curious to know- From where above Diagram is coming from? I mean Source of such a nice dependency and flow diagram?