nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

having changing owner of task within Workflow

navjot

Greetings,

I have two questions.

__Q1__
Assume my workflow is running with one of the tasks as ACTIVE. Let's say ABC is the owner of that task.

Now, i wish to provide control to the ADMINSTRATOR to be able to change the owner of the specified task. Is it possible to write a CGI program that can accept the task id and the new owner name DEF and then save the new owner for the specified task.

Now that DEF logs in and continue with the task. Now, the same task WILL NOT be visible as tasks in the ABC login.

__Q2__

Is it possible to write a CGI program that accepts the task id / job id and then aborts the same job instance? What impact will it have on the files that were attached to the workflow at that time?

TIA
Navjot Singh

Find more posts tagged with

Comments

Adam Stoller

__Q1__
Assume my workflow is running with one of the tasks as ACTIVE. Let's say ABC is the owner of that task.

Now, i wish to provide control to the ADMINSTRATOR to be able to change the owner of the specified task. Is it possible to write a CGI program that can accept the task id and the new owner name DEF and then save the new owner for the specified task.
Yes - using either CLTs or (generally better) the TeamSite::WFtask and TeamSite::WFworkflow modules as appropriate.

Now that DEF logs in and continue with the task. Now, the same task WILL NOT be visible as tasks in the ABC login.
Assuming that ABC either logged in after the reassignment or refreshed their UI after the reassignment - yes - however if ABC was already looking at their To Do List after the task had been initially assigned to them and did not refresh the window after the reassignment was performed - then they would still see the task listed there, but would receive a [likely] confusing error message if they tried to act on it

__Q2__
Is it possible to write a CGI program that accepts the task id / job id and then aborts the same job instance? What impact will it have on the files that were attached to the workflow at that time?
Yes. The files that were attached to the workflow become un-attached, and if they were locked by the workflow they become unlocked. Nothing else happens to them specifically because the job went away. If you had already made modifications to the files as part of the workflow, or submitted them, etc. - those actiions are not reverted by deleting the job.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

Might be a little late to this conversation, but this line concerns me:

Assume my workflow is running with one of the tasks as ACTIVE. Let's say ABC is the owner of that task.

Last I checked, it was not supported to change the owner of an active task, using either the CLT or the Perl modules. So, this CGI would have to somehow transition the task programmatically (not sure if this is possible on a user task), then change the owner, then transition back to the user task.

That's my $.03 (would be $.02 but this post is a bit late to the discussion, so I'm sure interest has applied

)

Jonathon
Interwoven Developer
Allstate, Inc.

Adam Stoller

I've modified the owner of active tasks in 5.5.2 SP2b without any problems ... not sure if it's "officially" supported - but it seems to work...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

JonathonG

Hmm, I stand (or sit or whatever one does on a message board) corrected.

I could've sworn that one couldn't do that (but I just ran it myself on a 5.5.2 machine and it worked). Maybe that was in an older version. Maybe I'm delusional.

Jonathon
Interwoven Developer
Allstate, Inc.

Adam Stoller

Well, to be fair - I just ran into a situation where it only 1/2 worked. I was able, within a single externaltask script, to change the owner of the task to someone else and perform some operations and then I tried to change the owner back and that failed.

However, I think it's "explainable" - as the owner of the externaltask process remains constant throughout - and the first time I changed owners I was doing so as the owner of the process who was also the owner of the task. The second time I was still the owner of the externaltask process but I was no longer the owner of the task (in this case the owner of the process was *not* a master user - which might also have some bearing on it).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com