Listers,
We've been going through some test scripts of late in preparation
for our upcoming upgrade to 7.0 and we noticed a workflow problem as it relates
to the mid-tier. This is all pretty clunky so bear with me, and I'll do my
best to describe the problem.
Scenario: Analyst opens a ticket on the mid-tier but needs to pass it to level
2 for some reason. Analyst changes status to System POC Working (our level 2
status) and selects an appropriate POC to assign the ticket to. Analyst makes
required changes to ticket and clicks save. At this point, we have a dialog
screen that pops up for extra clarification. It basically states the previous
status of the ticket and the status it's going to (i.e. Helpdesk Working to
System POC Working), the individual it will be assigned to, etc. At the bottom
is a button called Update Ticket. When this button is clicked, a series of
checks are performed to ensure the current user has the permissions to modify
the ticket and pass it to the status they're attempting to, as well as ensure
the next assignee has the proper permissions to update the ticket once they get
it. On the WUT, assuming all permissions are correct, everything works
according to plan. On the mid-tier however, an error is firing that as far as
I can tell, shouldn't.
Testuser5 is an analyst (Group) and passes a ticket to System POC Working. He
selects testuser6 who is a System POC (Group). Once he clicks save, the dialog
pops up and he enters the required information and clicks on Update ticket and
receives the following error: "$Assigned_To$ (in this case testuser6) does not
have permission to update a call in $Status$ (System POC Working) status.
Please reassign the call."
The process is as follows: When testuser5 clicks Update ticket, an active link
sets the Assign_To_Group field on the Dialog form (checks the value of
Assign_To against the login_name on the User form and returns their Group_List)
which in the above case would be "System POC." Next a series of active links
checks the Assign_To_Group and sets a field called Permissions based on the
value. There are 5 of these active links, but the one that should be firing
has the following Run If Condition: ( 'Assigned_To_Group' = "System POC" ) OR
( 'Assigned_To_Group' = "System POC Manager" ) OR ( 'Assigned_To_Group' =
"SWSX" )
In this case, Permissions should be set to "2." The field Assign_To_Group is
being set to System POC (I've made the field visible and can verify once the
error message appears) but it looks like the Permissions field is not being
set. The last step is a series of active links that check the current status
of the ticket (the status it will be placed in once the ticket is saved) and
the value in the permissions field. If the Run If condition is met, the
Assign_To_Okay field is set to "OK" which allows the ticket to bypass the above
error message and commit the changes. In the above case, the active link that
should be firing has the following Run If condition: (( 'Status' = "Sys POC
Working" ) OR ( 'Status' = "Customer Proposed DR" ) OR ( 'Status' =
"Evaluation" ) OR ( 'Status' = "Pending Support" ) OR ( 'Status' =
"Validation" ) OR ( 'Status' = "Duplicate" ) OR ( 'Status' = "Pending Site" )
OR ( 'Status' = "Waiting Turn-In" ) OR ( 'Status' = "Re-cycled" )) AND ((
'Permissions' = "2" ) OR ( 'Permissions' = "4" )) and the If Action sets
Assign_To_Okay = "OK"
Assign_To_Group is System POC so Permissions should be set to "2" and status is
Sys POC Working so the above Run If condition should be met but for some
reason, it appears Permissions is not being set and consequently Assign_To_Okay
is not being set.
I know that's all probably really clunky and ugly but huge modifications to
that workflow are pretty much off the table at this point. (we're on a short
schedule for this upgrade) Keep in mind, this works as intended on the WUT.
This problem only appears on the mid-tier. I guess my question is two-fold.
Is there anything in the above workflow that may cause it to function
incorrectly on the mid-tier but not on the WUT? And also, how big of a role
does execution order play in a web environment? The execution orders of the
whole series of active links in this check is separated by about 20. If I'm
not mistaken, execution order doesn't have any direct correlation to amount of
time elapsed but I'm wondering if that's maybe too close?
I looked through some of the docs describing WUT and web differences and didn't
see anything related to the above, and I also played around with the log
settings on the mid-tier configuration tool but didn't see anything
particularly useful. (at least nothing close to a WUT log, which I can
actually make use of) The following did appear in the mid-tier log when I
checked the workflow option:
Aug 7, 2008 1:58:24 PM - FINE (com.remedy.log.WORKFLOW) : (Thread 16)
com.remedy.arsys.goat.action.ActionSetFields: Error binding set-fields action 1
- dropping action
Aug 7, 2008 1:58:24 PM - FINE (com.remedy.log.WORKFLOW) : (Thread 16)
com.remedy.arsys.goat.action.ActionSetFields: Error binding set-fields action 0
- dropping action
As well as a couple other errors about 'Unsupported Action Automation' and
'Unsupported Action macro' but none of the logs really point me in any helpful
direction.
Windows Server 2003
AR Server 7.0. patch 6
Mid-tier 7.0 patch 8 with Tomcat 5.5
SQL 2K database
Again, my apologies if this is hard to follow. I'll be happy to clarify as
best I can.
Thanks,
Michael A. McManus, SSgt, USAF
Remedy Developer
HQ 754 ELSG/DOMH
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
