Re: ITSM 7.6.04 SIT:Site related filter SIT:STE:ChkStatusRuleRead_105... [[UPDATE]]
Just an FYI for those interested.
BMC Software has created a SW bug defect for this which will be applied to a
later release / patch of either supported versions that would require this
fix.
The SW bug ID is SW00477529.
Cheers
Joe
_
From: Joe D'Souza [mailto:jdso...@shyle.net]
Sent: Thursday, October 16, 2014 2:53 PM
To: ARS Discussion List
Subject: RE: ITSM 7.6.04 SIT:Site related filter
SIT:STE:ChkStatusRuleRead_105...
Just got a response from BMC as well stating the exact same thing that it is
so on version 8.x too and that it might be a bug.
Joe
_
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: Thursday, October 16, 2014 2:33 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7.6.04 SIT:Site related filter
SIT:STE:ChkStatusRuleRead_105...
**
Joe,
I just checked our 8.1 no patch system, and it says CTM:Site still. I
hadn't noticed it before.
Thad
On Thu, Oct 16, 2014 at 10:52 AM, Joe D'Souza jdso...@shyle.net wrote:
**
I was wondering if anyone else had noticed this and brought this up with BMC
Software. It looks like a bug with a filter named
SIT:STE:ChkStatusRuleRead_105 that has two Set Fields action.
The first Set Field action is fine and is looking for the existing Status
integer and character value and setting them to the respective temp fields.
The second Set Field action has a weird qualification. It is looking up the
SYS:Status Transition LookUp form which is a join form and is using the
qualification:
('Form Name' = CTM:Site) AND ('System Role' = $z1D System Role$) AND ('To
Status Int' = $Status$) AND ('From Status Int' = $z1D Integer01$) AND
('Status' = Enabled)
Because the form name sounded weird (CTM:Site and there is no such form on
the server) I looked up the SYS:Status Transition LookUp join to see if
there are any matching requests for CTM:Site and found none there either.
There are 50 matching requests for SIT:Site.
So basically it means that with no matches found for CTM:Site, this Set
Field action will ALWAYS set z1D Char01 to null. I think it might be a bug
(typo while developing that filter). I accidentally found it when looking
through OTB workflow since I was troubleshooting another unrelated issue on
some customization we are working on.
The qualification should have been:
('Form Name' = SIT:Site) AND ('System Role' = $z1D System Role$) AND ('To
Status Int' = $Status$) AND ('From Status Int' = $z1D Integer01$) AND
('Status' = Enabled)
Its impact would be that the Status field value would be set to whatever
value the user selects irrespective of the results of a check for if the
user belongs to Contact Location Admin or General Access.
Has anyone noticed this and raised it to BMC Support and is there a hot fix
available for this? I have just raised a ticket with BMC Support a couple of
hours ago and yet to hear back from them.
Cheers
Joe
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Where the Answers Are, and have been for 20 years
Re: ITSM 7.6.04 SIT:Site related filter SIT:STE:ChkStatusRuleRead_105...
Joe,
I just checked our 8.1 no patch system, and it says CTM:Site still. I
hadn't noticed it before.
Thad
On Thu, Oct 16, 2014 at 10:52 AM, Joe D'Souza jdso...@shyle.net wrote:
**
I was wondering if anyone else had noticed this and brought this up with
BMC Software. It looks like a bug with a filter named
*SIT:STE:ChkStatusRuleRead_105* that has two Set Fields action.
The first Set Field action is fine and is looking for the existing Status
integer and character value and setting them to the respective temp fields.
The second Set Field action has a weird qualification. It is looking up
the *SYS:Status Transition LookUp* form which is a join form and is using
the qualification:
('Form Name' = CTM:Site) AND ('System Role' = $z1D System Role$) AND
('To Status Int' = $Status$) AND ('From Status Int' = $z1D Integer01$) AND
('Status' = Enabled)
Because the form name sounded weird (CTM:Site and there is no such form on
the server) I looked up the *SYS:Status Transition LookUp* join to see if
there are any matching requests for *CTM:Site* and found none there
either. There are 50 matching requests for *SIT:Site*.
So basically it means that with no matches found for CTM:Site, this Set
Field action will ALWAYS set *z1D Char01* to null. I think it might be a
bug (typo while developing that filter). I accidentally found it when
looking through OTB workflow since I was troubleshooting another unrelated
issue on some customization we are working on.
The qualification should have been:
('Form Name' = SIT:Site) AND ('System Role' = $z1D System Role$) AND
('To Status Int' = $Status$) AND ('From Status Int' = $z1D Integer01$) AND
('Status' = Enabled)
Its impact would be that the Status field value would be set to whatever
value the user selects irrespective of the results of a check for if the
user belongs to *Contact Location Admin* or *General Access*.
Has anyone noticed this and raised it to BMC Support and is there a hot
fix available for this? I have just raised a ticket with BMC Support a
couple of hours ago and yet to hear back from them.
Cheers
Joe
_ARSlist: Where the Answers Are and have been for 20 years_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Where the Answers Are, and have been for 20 years
Re: ITSM 7.6.04 SIT:Site related filter SIT:STE:ChkStatusRuleRead_105...
Just got a response from BMC as well stating the exact same thing that it is
so on version 8.x too and that it might be a bug.
Joe
_
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser
Sent: Thursday, October 16, 2014 2:33 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM 7.6.04 SIT:Site related filter
SIT:STE:ChkStatusRuleRead_105...
**
Joe,
I just checked our 8.1 no patch system, and it says CTM:Site still. I
hadn't noticed it before.
Thad
On Thu, Oct 16, 2014 at 10:52 AM, Joe D'Souza jdso...@shyle.net wrote:
**
I was wondering if anyone else had noticed this and brought this up with BMC
Software. It looks like a bug with a filter named
SIT:STE:ChkStatusRuleRead_105 that has two Set Fields action.
The first Set Field action is fine and is looking for the existing Status
integer and character value and setting them to the respective temp fields.
The second Set Field action has a weird qualification. It is looking up the
SYS:Status Transition LookUp form which is a join form and is using the
qualification:
('Form Name' = CTM:Site) AND ('System Role' = $z1D System Role$) AND ('To
Status Int' = $Status$) AND ('From Status Int' = $z1D Integer01$) AND
('Status' = Enabled)
Because the form name sounded weird (CTM:Site and there is no such form on
the server) I looked up the SYS:Status Transition LookUp join to see if
there are any matching requests for CTM:Site and found none there either.
There are 50 matching requests for SIT:Site.
So basically it means that with no matches found for CTM:Site, this Set
Field action will ALWAYS set z1D Char01 to null. I think it might be a bug
(typo while developing that filter). I accidentally found it when looking
through OTB workflow since I was troubleshooting another unrelated issue on
some customization we are working on.
The qualification should have been:
('Form Name' = SIT:Site) AND ('System Role' = $z1D System Role$) AND ('To
Status Int' = $Status$) AND ('From Status Int' = $z1D Integer01$) AND
('Status' = Enabled)
Its impact would be that the Status field value would be set to whatever
value the user selects irrespective of the results of a check for if the
user belongs to Contact Location Admin or General Access.
Has anyone noticed this and raised it to BMC Support and is there a hot fix
available for this? I have just raised a ticket with BMC Support a couple of
hours ago and yet to hear back from them.
Cheers
Joe
_ARSlist: Where the Answers Are and have been for 20 years_
_ARSlist: Where the Answers Are and have been for 20 years_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Where the Answers Are, and have been for 20 years
