Thank you for your response Swanand.
It is not custom workflow that is resetting the status reason to null. It is
an OOB filter related to release SLA and OLA hold.
The filter is HPD:INC:ClearStatusReason_210
Qualifications:
('Status' != "Pending") AND ('Status' != "Resolved") AND ('Status' != "Closed")
AND ('Status' != "Cancelled") AND ('Status_Reason' != $NULL$)
Actions:
'OLA Hold' = "NO"
'z1D_Status_Reason' = $NULL$
'SLA Hold' = "NO"
'Status_Reason' = $NULL$
So you see it is only when Assigned or in Progress. I am wondering if I just
have it set SLA and OLA Hold to No if that will be safe. I don't want to screw
up the SLA's. I'll have to do some more testing. Anyone else run across this?
Ken.
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of swanand deshpande
Sent: Tuesday, October 09, 2012 5:37 PM
To: [email protected]
Subject: Re: Status Reasons for Assigned and In Progress Statuses
** Ken,
We too are doing similar type of functionality but we did not face the issue
you are facing. Hope there aren't any custom workflows you had developed
earlier causing it set to null. I would suggest you to take filter and active
link log and then check.
Hope you have flushed the midtier cache after performing the change.
Thanks,
Swanand
On Tue, Oct 9, 2012 at 3:53 PM, Cecil, Ken
<[email protected]<mailto:[email protected]>> wrote:
Sean,
Thank you for your response. However, that is exactly what I did... I have
previously added Status Reasons to the Pending Status so I know you need to add
the data and modify the hidden Status_Reason field on the form.
As I had said, what is happening is that if the Status is either Assigned or In
Progress, the ' z1D_Status_Reason' and 'Status_Reason' are getting set to null
upon save (filter).
Is there a good reason that these filters are doing this? Has anyone else used
Status Reasons for the Assigned and/or In Progress statuses?
Ken.
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Garrison,
Sean (Norcross)
Sent: Tuesday, October 09, 2012 4:38 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: Status Reasons for Assigned and In Progress Statuses
Status Reason is determined from "SYS:StatusReason Menu Items" where 'Form
Name' = "HPD:Help Desk". It is status dependent so when the "Status" changes
you typically need a new "Status Reason" for why it is in that state.
Keep in mind that the field on HPD:Help Desk is a display only field
(z1D_Status_Reason)( 1000000881). There is workflow that sets the underlying
"Status Reason" field. Not only do you have to add it to "SYS:StatusReason
Menu Items" but you also have to add an entry to the hidden "Status Reason"
(1000000150) field on Incidents.
Hope that helps ...
Sean
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Cecil, Ken
Sent: Tuesday, October 09, 2012 12:01 PM
To: [email protected]<mailto:[email protected]>
Subject: Status Reasons for Assigned and In Progress Statuses
ITSM 7.6
On Incident, a customer would like to add several Status Reason menu choices
associated with the Assigned and In Progress Statuses. They intend to use is as
a sort of sub-status (for example: In Progress with a Status Reasons of
Analysis, Test, Document Prep, etc)
I have added the Status Reason menu choices and they show up properly. However,
now I see that there are filters that are clearing the field upon save. I plan
to disable or work around them.
My question is does anybody know no a good reason why I shouldn't do this...
why the Status Reason must be cleared out if the Status is either Assigned or
In Progress?
Has anybody else used the Status Reason with either of those two Statuses?
Thanks,
Ken.
******************************************************************************
This email and any files transmitted with it are confidential and intended
solely for the addressee. If you have received this email in error please
notify the system manager. Subject to local law, communications (including
traffic data) with Hubbell may be monitored by our systems [or a third party's
systems on our behalf] for the purposes of security and the assessment of
internal compliance with Hubbell policies. This footnote also confirms that
this email message has been swept for the presence of computer viruses.
www.Hubbell.com<http://www.Hubbell.com> - Hubbell Incorporated
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.org<http://www.arslist.org> attend wwrug12
www.wwrug12.com<http://www.wwrug12.com> ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.org<http://www.arslist.org> attend wwrug12
www.wwrug12.com<http://www.wwrug12.com> ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.org<http://www.arslist.org>
attend wwrug12 www.wwrug12.com<http://www.wwrug12.com> ARSList: "Where the
Answers Are"
--
S.J.Deshpande
_attend WWRUG12 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers
Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
