Michael,
It may be the whole problem.... or it may be nothing... but...
Part of your process ("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") indicates that every
user of the system has to have access to the 'Group List' data for all
other users of the system. (Assuming the work is done in Active
Links.) This seems like a _poor security practice_ to me. And
specifically, when you did your upgrade, did you verify that the User
form permissions, and field permissions matched the "old system"? I
would bet that changes were made to the User form so that all users
can see all other users 'Group List' data for this "feature" to work.
Maybe there is some issue with how those changes work relative to the
Mid-Tier only?
You think go on to say...
"Run If Condition: ( 'Assigned_To_Group' = "System POC" ) OR (
'Assigned_To_Group' = "System POC Manager" ) OR ( 'Assigned_To_Group'
= "SWSX" )"
However, testing the 'Group List' data ( which is really a string
like: ";1234; 23245; 464567;", AKA: a ";" separated 'Group ID' list)
with 'Group Name' values seems like a problem to me. Maybe it worked
in some version of the User Tool, but I would not design an
application that relied on the behavior. Not to mention the "=" tests.
Should those be LIKE operators with some kind of wild card matching?
(Or are there other things that walk the 'Group ID' list and do a
translation to 'Group Name' so that other workflow can test on
separate 'Group Name' values that you did not mention?
Later you go on to say...
"
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?
"
Execution Order for active links should work exactly the same between
the two clients. It dictates which Active Links come first, but it is
not a "timing"(AKA: Wall clock) related feature. The Active Link will
take as long as it takes and the next Active Link should not start
until the previous one is finished. As long as the Execution Orders
are arranged so that anything that has to come "before something else"
has a lower number (>=0) then it should work as expected. If you have
workflow that has to work in a specific order, but they have the same
execution order value... then all bets are off for which Active Link
will be processed first.
Ok.. now we may be getting somewhere...
You go on to say...
"
> 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
"
I would suggest that you export the workflow in question (in XML
format) and verify that the ARS Server value for the Set Field action
that failed is a "@" value. If it is a hard coded server name, then
the Mid-Tier will need to have that server configured in it's
configuration, or the Active Like definition will need to be updated
to point at the "current server". (Which is what the "@" marker
means.)
It is a less than used feature that Active Links from a Form on
ServerA can actually Set/Push data to a Form on ServerB. (Assuming the
user has a license on both servers that use the same 'Login Name' and
the same password.)
Maybe that is your problem?
BTW: the 'Unsupported Action Automation' and 'Unsupported Action
macro' stuff are OLE and Macro actions in your Active Links. Those do
not work on the Mid-Tier at all. And I would suggest that you hunt
down and replace any Macro actions. They are old, and poorly supported
at this point. ( I would use the word depreciated.)
Hope some of that helps.
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On Thu, Aug 7, 2008 at 3:54 PM, McManus Michael A SSgt HQ 754
ELSG/DOMH <[EMAIL PROTECTED]> wrote:
> **
>
> 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
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
