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"
