Re: Remove closed cases from incident matching on escalate. (289 Views)
Reply
Regular Advisor
Ivis
Posts: 122
Registered: ‎02-03-2011
Message 1 of 6 (326 Views)

Remove closed cases from incident matching on escalate.

Hi - I was wondering if it is possible to remove closed cases from the list generated by RAD application - incident.maching and script SolutionMatching so that it will only show the open cases and remove closed cases? 

 

Currently running on 9.32 with PD 9.30.3 installed. 

 

BR Ivis. 

Honored Contributor
John Stagaman
Posts: 3,521
Registered: ‎07-13-2007
Message 2 of 6 (299 Views)

Re: Remove closed cases from incident matching on escalate.

[ Edited ]

With PD4 (9.30.3) the field matching comparisons  are defined in the imMatchQuery table. Those records do not support the addition of a filter to restrict matching to only open records. 

 

However, the incident.matching RAD application calls a JavaScript to retrieve and execute the soluition match query:
SolutionMatching.getIMQueries

 

Option 1: You could potentially update that JavaScript to append an additional filter on the generated queries. I haven't played with it so I can't verify that it will work or provide a code example. 

 

Option 2: If you look at the Problem & Known Error matching, they are prompting for all, pm. ke, but I can't figure out how they are modifying the resulting query. But if you hack through that it may provide a way to do something similar to filter by active, inactive, all.

 

Option 3: If those don't work, you could also do a messy but easy alternative: for any open record copy the service and affected CI into two new fields (call them openService and openCI) and at close, clear the fields. Then update/replace the matching queries to work against your new fields instead of the originals. (It's not elegant). Note that you absolutely would want to define a dbdict key/RDBMS index for the openService and openCI fields if you used this approach.

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
Honored Contributor
John Stagaman
Posts: 3,521
Registered: ‎07-13-2007
Message 3 of 6 (289 Views)

Re: Remove closed cases from incident matching on escalate.

[ Edited ]

You should be able to update the sql outputs in this section of the JavaScript to exclude closed records in addition to just querying against logical.name or affected.item:

 

SNAG_Program-0037.png

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
Regular Advisor
Ivis
Posts: 122
Registered: ‎02-03-2011
Message 4 of 6 (273 Views)

Re: Remove closed cases from incident matching on escalate.

Hi John and thanks for the input. 

I am trying to run some print statements but i get no output and nothing seems to happen when I modify the sql's. 

So wondering when these things are getting called. 

 

BR Ivis. 

Regular Advisor
Ivis
Posts: 122
Registered: ‎02-03-2011
Message 5 of 6 (272 Views)

Re: Remove closed cases from incident matching on escalate.

I am getting a little closer but I get an issue with different tables. 

In the function getQueryDesc the query is returned and by adding query+=" and problem.status~=\"Closed\" to the bottom of the function it returns only open tickets. 

 

The issue is of course when the i change to knownerror where it does not locate the problem.status field. Flag is also not an option here it looks like....

 

 

I guess I can add a field in all modules that correspond and use this in the query - but if anyone else has a better option I am listening. 

 

BR Ivis. 

 

Regular Advisor
Ivis
Posts: 122
Registered: ‎02-03-2011
Message 6 of 6 (271 Views)

Re: Remove closed cases from incident matching on escalate.

Ok - added the if sentence: 

 

if (tableName=="incidents" && tableToMatch!="rootcause") {

       query+=" and flag#true"; 

}

 

Looks to remove all closed tickets. 

 

I will monitor it for the time beeing, but looks like the result is stored so this may cause a future issue. 

 

BR Ivar. 

 

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.