Error using Lifecycle.Queues.Find in Workflow Script

[Kirk_Sumpter]

I have a workflow script where I need to create an object referencing the "Exit" queue in a lifecycle (I later use this object to add a document back into the Exit queue).

Here is the code to assign the lifecycle object, then find the queue object:

-------------------

args.ScriptResult = false;

long maxdocs = 100;

//set up cue object from args

Queue cue = app.Workflow.Queues.Find(args.Queue.ID);

//if queue wasn't found throw exception

if (cue == null)

{

throw new Exception("Cannot find workflow Queue");

}

//create lifecycle object 

Hyland.Unity.Workflow.LifeCycle lc = app.Workflow.LifeCycles.Find(cue.LifeCycle.ID);

if (lc == null)

{

throw new Exception("Cannot locate MR Branch Expenditure Lifecycle");

}//end if

//set up cue object for re-adding doc to lifecycle in correct queue

Queue newQueue = lc.Queues.Find("Exit");

if (newQueue == null)

{

throw new Exception("Cannot locate Exit queue in this lifecycle");

}//end if

------end code snippet

When i run this exact code in my development environment with the same limited permissions as my user the script runs fine. 

However, when she runs the ad-hoc task she receives an error with the exception being the newQueue object is null.

The error in the Unity API tab of the diagnostics console throws this error:

-------

System.Exception: Cannot locate Exit queue in this lifecycle

  at MRCloseOutMRBatch.MRCloseOutMRBatch.OnWorkflowScriptExecute(Application app, WorkflowEventArgs args) in c:\Users\kirk.sumpter\AppData\Local\Temp\0frenzqp.0.cs:line 57

-----

Since this exact code works for me and not her, I'm a bit stumped.  Furthermore, what REALLY stumps me is why there is a reference in the error code to my users folder, when her user ID is logged and running the script.  Could this be the source of the issue?

Any other ideas or has someone run into this before?

Thanks!

[Adam_Kuhn · Accepted solution]

Hi Kurt --

Couple questions:

1. Is she running the script in the same environment as you (i.e. on your machine) or has she ported the script over to her machine? If so, are all the Queues named exactly the same on both your systems?
2. What steps did you take to configure the two user accounts to have the same limited permissions? If you create a new user account with the correct permissions, are you able to execute the script when logged in as that user?

My first guess is that there's some flag or permission that's different between your User and your customer's User which is preventing her from seeing the Exit queue.

Best, Adam Kuhn

[Kirk_Sumpter]

Thanks Adam,

I believe I've now re-created and isolated the issue in our dev environment (I can't prove production until Monday after the app servers reset).

The issue is her user group did not have permissions to the "Exit" queue in production since they shouldn't need to see documents in there (but did in dev for testing purposes). 

What I don't understand why that's necessary as the script itself is running under an account that has permissions to all the queues. 

And, related, why would the script be treated differently than any ad-hoc task action that moves documents to another queue in which the user doesn't have permissions (I have a number of these in this workflow)?

To answer your second question, the script is running from the app server since it's a workflow script executed from an ad-hoc task in workflow, and the queues are named identically in both environments (Exit)

[Jeffrey_Seaman]

If this script is being executed from an ad hoc task, then it's executed under the user that initiated the ad hoc task. If you need to ensure the script runs as an account with specific privileges, you'd need to move it under a timer. You might be thinking IWorkflowScript runs as the server, while IWorkflowClientScript runs as the user, but that's just where the script executes (appserver vs client), not the user context.