Re: Close related Changes before Incidents (521 Views)
Reply
Trusted Contributor
tprovin
Posts: 229
Registered: ‎11-05-2009
Message 1 of 8 (522 Views)
Accepted Solution

Close related Changes before Incidents

All:

 

I wanted to get some thoughts on the best way to do this.  In our environment, process states that when a Change is spawned from an Incident, the related Change needs to be closed prior to the Incident being closed.  Incidents are using the 2 set closure (Resolve and Close) and I know that I can hide the Resolve button if there are any open related Changes, but I don't know that this is the best/easiest way to do this. 

 

Your thoughts are greatly appreciated.

 

Tim

Thanks,

Tim
Honored Contributor
Jacob Heubner
Posts: 4,177
Registered: ‎07-21-2008
Message 2 of 8 (521 Views)

Re: Close related Changes before Incidents

Well, a formatctrl validation might be simpler to set up, and hit more consistently. 

 

That's one thing I don't like about the Display Option records - there's only one condition that runs.  For formatctrl validations, the validations are checked in order.

 

You could have either a Calculation or a Query that runs when problem.status in $file="Resolved" to return a result, and then insert a line at the start of the Validations panel that checks this result.

 

Maybe something like:

 

Calculations -

Update: problem.status in $file="Resolved"

Calculation: $L.void=rtecall("rinit", $L.rc, $L.screlation, "screlation");$L.void=rtecall("select", $L.rc, $L.screlation, "source=\""+number in $file+"\" and depend.filename=\"cm3r\" and depend.active=true"); if $L.rc>0 then $changes.closed=false

 

Validations:

Update: problem.status in $file="Resolved"

Validation: nullsub($changes.closed, true)=true

Message: You cannot Resolve this Incident until the related Change records are closed.

 

 

Trusted Contributor
tprovin
Posts: 229
Registered: ‎11-05-2009
Message 3 of 8 (521 Views)

Re: Close related Changes before Incidents

Just the guy I expected to set me straight!  Thank you as always Jacob!!!

Thanks,

Tim
Trusted Contributor
tprovin
Posts: 229
Registered: ‎11-05-2009
Message 4 of 8 (521 Views)

Re: Close related Changes before Incidents

So it looks like I spoke too soon about this ... The validation is being kicked off every time I resolve an Incident.  It doesn't matter if there is a Change related to it or not.  It all seems to work fine if there is a Change related to the Incident and the Change has been closed.  Not sure where it is getting confused. 

 

If I open an Incident without a Change and try to resolve it, the $changes.closed value is "false" which is what it should be.  However, the validation still triggers.  Any thoughts?

Thanks,

Tim
Honored Contributor
Vadim Gorda
Posts: 5,773
Registered: ‎11-10-2008
Message 5 of 8 (521 Views)

Re: Close related Changes before Incidents

So you mean that it fires wheather there is related change or not and if there is no related change you dont want it to fire.

Solution 1:

I think that you can just add a calculation line which will check is there any related record with cm3r parameter and set some variable to true or false (make this calculation before the several which wrote Jacob). And then add this variable true or false condition to the condition for trigerring Jacobs expressiosn. Just make a Update condition for them more complex, like problem.status in $file="Resolved" and  $related.change.exist=true

 

Solution 2:

Try just to add to Jacobs calculation expression

Calculations -

Update: problem.status in $file="Resolved"

Calculation: $L.void=rtecall("rinit", $L.rc, $L.screlation, "screlation");$L.void=rtecall("select", $L.rc, $L.screlation, "source=\""+number in $file+"\" and depend.filename=\"cm3r\" and depend.active=true"); if $L.rc>0 then $changes.closed=false else $changes.closed=true

think that will solve the problem.

Trusted Contributor
tprovin
Posts: 229
Registered: ‎11-05-2009
Message 6 of 8 (521 Views)

Re: Close related Changes before Incidents

Yea that didn't change anything ... After running some tests through the debugger, I am finding that the following statement is returning the wrong value for $L.rc

 

$L.void=rtecall("select", $L.rc, $L.screlation, "source=\""+number in $file+"\" and depend.filename=\"cm3r\" and depend.active=true");

 

I run a ticket through that has nothing related to it at all and $L.rc=3, but when I go to the screlation table and search using the same criteria I get "No records found."

 

The $L.rc value seems to set correctly when 1 or more Changes are related to the Incident, so i'm not to sure why it doesn't want to work when none are.

Thanks,

Tim
Valued Contributor
SteveO_1
Posts: 63
Registered: ‎04-06-2010
Message 7 of 8 (521 Views)

Re: Close related Changes before Incidents

Try amending the format control slightly to ensure that the correct variable is being addressed:

 

Update: problem.status in $file="Resolved"

Calculation: $L.void=rtecall("rinit", $L.rc, $L.screlation, "screlation");$L.void=rtecall("select", $L.r.no, $L.screlation, "source=\""+number in $file+"\" and depend.filename=\"cm3r\" and depend.active=true"); if $L.r.no>0 then $changes.closed=false else $changes.closed=true

This should prevent any confusion and if there is an issue with the variable being incorrectly populated I would suggest that you refer that to HP support.

Trusted Contributor
tprovin
Posts: 229
Registered: ‎11-05-2009
Message 8 of 8 (521 Views)

Re: Close related Changes before Incidents

In case anyone is interested I was able to get this working by going a different direction.

 

probsummary FC -> queries (Need to show expanded form)

Filename: screlation

Query: source=number in $file and depend.filename="cm3r" and depend.active=true

Comments=count

Update=problem.status in $file="Resolved"

 

probsummary FC -> validations

Validation: 4 in $file.count=0     (it was the 4th query in my case, but is probably different for others)

Message: You cannot Resolve this Incident until all related Changes are closed.

Update: problem.status in $file="Resolved"

 

Tim

Thanks,

Tim
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.