NP - what's rather frustrating is that the task phasing feature is the main feature, or one of the top features, in ITSM 7.5.1... It's frustrating to have to wait for patches or new versions for the new features to be solid. ITSM 7 had 9 patches, so I suspect it will be the same for ITSM 7.6
Guillaume -----Original Message----- From: Action Request System discussion list(ARSList) on behalf of Charles Baldi Sent: Mon 10/26/09 4:08 PM To: [email protected] Subject: Re: Task Flow bugs corrected Thanks, that is good to know. Because I suspected that there were many other bugs in the task flow I did not label my post as "resolved". Chuck On Mon, Oct 26, 2009 at 2:47 PM, Guillaume Rheault <[email protected]>wrote: > ** > > Forgot to mention... because these bugs are open in ITSM 7.6, and therefore > not fixed, it is recommended customers do not use the task phasing feature > either in ITSM 7.5.1 or ITSM 7.6. Hopefully ITSM 8.0 will fix, or an ITSM > 7.6 patch > > Guillaume > > > > -----Original Message----- > From: Guillaume Rheault > Sent: Mon 10/26/09 2:47 PM > To: [email protected]; [email protected] > Subject: RE: Task Flow bugs corrected > > FYI - there are more bugs in the Task Module in ITSM 7.5.1, when task > phasing is in use. Here it the statement form BMC Support, when I submitted > the ticket months ago: > > "There is a hidden field associated with the TMS:Task form, State > (10003019). This field must be set to Active for the task to allow a status > change. For some reason, the OOB workflow has been found to intermittently > fail in setting this. The exact cause is still under evaluation. The defect > related to this is SW00316007." > > Bug SW00324022 was also created for the same defect, it is the one > referenced in the ITSM 7.6 release notes. In addition to this bug, there is > bug SW00345321, also referenced in the ITSM 7.6 release notes, about task > phasing too. > > Because of these bugs, it is not recommended to use the task phasing > functionality introduced in ITSM 7.5.1. Seems to me all the Task management > module code needs to be reviewed and clean up. > > Guillaume > > > -----Original Message----- > From: Action Request System discussion list(ARSList) on behalf of Charles > Baldi > Sent: Mon 10/26/09 11:32 AM > To: [email protected] > Subject: Task Flow bugs corrected > > All, > For anyone who is using the Task Flow engine in Change Management in more > than a trivial way, you may have encountered bugs that prevent a built flow > from behaving as expected. We did. After several unhelpful and > time-wasting discussions with BMC support, we tracked-down and fixed a > handful of bugs in the Task Flow engine. > > Context: ITSM 7.0.03, patch 008. > > Hoping this may be useful to others, here are the corrections that we made > and why. > > 1. Filter "TMS:TAS:Bypassed_MarkFlowTo_NotFollowed" > The If Action - Push Fields was setting the Flow Status to "Flow Followed" > rather than "Flow Not Followed" as its name says. This was causing a flow > that should be bypassed appear as if it was still active. The correction > was to modify the Push Fields to set Status = "Flow Not Followed" > ==> This was the principle bug we found. Fixing this caused the bypass of > Task Groups to function properly. > > 2. Filter "TMS:FLW:Bypassed_TaskEvaluate`!" > The Run If qualification was looking for Status = "Flow Followed" to check > for bypassed rather than "Flow Not Followed". No doubt this bug was hidden > because of the first one above (or created because the first one could not > be found.) The correction was to change the Run If condition to check for > Status = "Flow Not Followed". > > 3. Filter "TMS:TGR:Bypassed`!" > This filter was not properly setting the DO variable "zTmpInternal" when a > Task Group within another Task Group was being bypassed. When this > happened > the change of Status to "Bypassed" was being interpreted as a user input > change which caused the filter "TMS:SHR:Inactive_StatusLock" to generate an > error. This caused all pending flow updates to roll back leaving the flow > unusable. The correction was to add zTmpInternal = "Yes" to the third > Push > Fields If Action. > > 4. Filter "TMS:FLW:CheckForOtherFailedFlows" > I consider this a defect. In a merged flow (i.e., a Task with multiple > input flows) if ANY input flow was bypassed, this filter caused the task > and > all downstream flows to also be bypassed. This is not the behavior I > expect. When I have Flow To Successor when = "All Complete" (in the flow > definition) I consider a bypassed input flow to be a completed flow. > Therefore if any input is closed normally, then the multiple-input task > should be activated normally. The multiple-input task should only be > bypassed if ALL inputs are bypassed. This is important because using "Any > Complete" in the flow is not an adequate solution. I want the multi-input > task to activate only when all inputs are completed or bypassed. Setting > the flow to "Any Complete" would allow the task to fire prematurely. The > correction was to DISABLE the filter. > > 5. Filter "TMS:SHR:varSetNameAsSourceForLabel". Despite what its help > text > says, this was only setting the source field for a data label if the data > variable was an OUTPUT. We need the labels to be set when they are INPUT > as > well. My correction was to copy the filter and add the opposite condition, > in this case ('zTmpVariableID' != $NULL) > > I hope this saves someone some time and pain. > > Regards, > Chuck Baldi > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum > Sponsor:[email protected]<sponsor%[email protected]>ARSlist: > "Where the Answers Are" > > > > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers > Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
