Re-assigning task owner within workflow

In our setup we will have multiple authors working on a single job. We would like the ability to have our authors reassign task ownership to another author (for change review purposes) at any point during the job. Having a master account manually reassign the task owner is not an option.

What do you think would be the best way to achieve this?

TS 6.5 on Solaris

Find more posts tagged with

Comments

Dwayne

I don't know about "best" but one way to do it would be to have a CGI task which is activated in parallel with the task to be changed. That CGI task wouldn't be able to directly change the owner of the target task, but it could set a task variable indicating the new owner, and a subsequent external task could read that variable and then change the owner.

Or, if you only have a very small number of authors (2 or 3 max, I would say) you could just have one task transition for each possible new author, in addition to your current transition(s). Each would transition to a different external task to again perform the change of ownership.

ISCBorisB

In our setup we will have multiple authors working on a single job. We would like the ability to have our authors reassign task ownership to another author (for change review purposes) at any point during the job. Having a master account manually reassign the task owner is not an option.

What do you think would be the best way to achieve this?

TS 6.5 on Solaris

In outline - You can create extra "Reassign" transition button in every user task. From there,
transition to CGI Task with GUI to choose reassignment,
change an owner of the task you just left and loop back to it.

Devil is in details though... You may have to transition to interim external task
to set CGI ownership dynamically, then face an issue of "CGI right after external", etc...

kaalraa

Adding more to that... the change in ownership of a task can even be done within the CGITask.

In our setup we will have multiple authors working on a single job. We would like the ability to have our authors reassign task ownership to another author (for change review purposes) at any point during the job. Having a master account manually reassign the task owner is not an option.

What do you think would be the best way to achieve this?

TS 6.5 on Solaris

Dwayne

Adding more to that... the change in ownership of a task can even be done within the CGITask.

But only if the user running the CGI task has permission to do so. Transitioning to an external task is safer, IMO.

kaalraa

As far as I know, i dont think that the user would be different for a CGITask and the very next external task. Moreover as the person has to add the CGITask in between he would make sure that the user for cgitask should have permission.

But only if the user running the CGI task has permission to do so. Transitioning to an external task is safer, IMO.

As per my opinion if the user does not have permission to change the owner, then he could not do so either from CGItask or an external task.

May be i am wrong.... please correct and confirm.

ISCBorisB

As per my opinion if the user does not have permission to change the owner, then he could not do so either from CGItask or an external task.

May be i am wrong.... please correct and confirm.

user/external/cgi task owner(s) are not always the same. Usually, it's quite the opposite.
So, even if particular user of some task does not have certain credentials, "Workflow" may

JMcNeil

The CGItask sounds promising, my question would be how to invoke it. The problem is that the authors should be able to change ownership at any point in the job. In order to invoke a CGItask would you need to have a successor of each task point to it (and somehow pass the information of which job should be the successor of the CGItask)?

Adam Stoller

The CGItask sounds promising, my question would be how to invoke it. The problem is that the authors should be able to change ownership at any point in the job. In order to invoke a CGItask would you need to have a successor of each task point to it (and somehow pass the information of which job should be the successor of the CGItask)?

Depending on the actual workflow state/transition process map this may be easy or difficult to do.

Dwayne

The CGItask sounds promising, my question would be how to invoke it. The problem is that the authors should be able to change ownership at any point in the job. In order to invoke a CGItask would you need to have a successor of each task point to it (and somehow pass the information of which job should be the successor of the CGItask)?

It may be possible to have a single CGI task for the entire workflow, depending on how your workflow is structured. That CGI task could be set to start at the beginning of the workflow, and always be active while the job is active. Once the user invokes it to change the owner, the following external task could change the ownership of all the appropriate tasks, provided it has some way of knowing which tasks to change. (Perhaps all the tasks owned by the old user). It would be complicated, though, because it would have to detect the currently active task, so that it could de-activate it, change the ownership, and then transition to that task.

Migrateduser

As per my opinion if the user does not have permission to change the owner, then he could not do so either from CGItask or an external task.

May be i am wrong.... please correct and confirm.

You can run a CGI task that does not have permissions to change task owner as the user might not have admin or master permissions. The CGI task can just update a workflow variable and have a externaltask that reads and resets the task ownership.

I think only specific users should be given permissions to change task ownership or other workflow properties.

JMcNeil

My current thought process is have a CGItask as an available successor to each usertask
have that CGItask transition to an externaltask which changes the owner

My problem comes in dynamically setting the successor of that externaltask. If it were somethign simple like setting a task description the API would cover it easily ($task->setDescription("foobar")). But as far as I can tell changing the successor of a task is not so straight forward. If there were an API command such as $task->SetSuccessorTask("wherever the job was before the CGItask") then I'd be all set.

Any info on dynamically changing successor sets while in a workflow?

Adam Stoller

It may be possible to have a single CGI task for the entire workflow, depending on how your workflow is structured. That CGI task could be set to start at the beginning of the workflow, and always be active while the job is active. Once the user invokes it to change the owner, the following external task could change the ownership of all the appropriate tasks, provided it has some way of knowing which tasks to change. (Perhaps all the tasks owned by the old user). It would be complicated, though, because it would have to detect the currently active task, so that it could de-activate it, change the ownership, and then transition to that task.

While it is generally recommended to only change ownership of tasks while they are in an inactive state, it is not mandatory (I've done some pretty tricky things like this before)
I'm not sure I'd recommend having the cgitask active over the course of the entire workflow process - I think there are far more elegant solutions.

Adam Stoller

You can run a CGI task that does not have permissions to change task owner as the user might not have admin or master permissions. The CGI task can just update a workflow variable and have a externaltask that reads and resets the task ownership.

I think only specific users should be given permissions to change task ownership or other workflow properties.

I'm not 100% positive, but I'm pretty sure that the task owner always has the ability to reassign a task that they (currently) own to someone else - regardless (I believe) of their TeamSite role.

Adam Stoller

My current thought process is have a CGItask as an available successor to each usertask
have that CGItask transition to an externaltask which changes the owner

My problem comes in dynamically setting the successor of that externaltask. If it were somethign simple like setting a task description the API would cover it easily ($task->setDescription("foobar")). But as far as I can tell changing the successor of a task is not so straight forward. If there were an API command such as $task->SetSuccessorTask("wherever the job was before the CGItask") then I'd be all set.

Any info on dynamically changing successor sets while in a workflow?

Repeat after me:[indent]Job variables are your friend.[/indent]

JMcNeil

Job Variables are our friends Smiley Happy

My problem isn't remembering "wherever the job was before the CGItask", that's easy enough to keep as a job variable

My problem is dynamically telling this external task that it's succesor is that job variable. As I understand it once the wft is compiled the successor's for each task are defined.

If this $task->SetSuccessorTask function existed I'd be all set, but I made that up and that's where I'm getting stuck

Adam Stoller

Job Variables are our friends

My problem isn't remembering "wherever the job was before the CGItask", that's easy enough to keep as a job variable

My problem is dynamically telling this external task that it's succesor is that job variable. As I understand it once the wft is compiled the successor's for each task are defined.

If this $task->SetSuccessorTask function existed I'd be all set, but I made that up and that's where I'm getting stuck

Okay - now think table-driven

See if you can fill in the blanks.

Migrateduser

You could have your external task have succesors for each of the tasks it might potentially transition to. Within the external task, make a call to iwgetwfobj for the task id so you can get the list of succeessors (don't know why there isn't a WFTask method for this), and build a hash with the task name of the successor as the key, and the transition number (indexed from 0 of course) as the value.

Then you could call your CallBack with that transition id and transition to any arbitrary task so long as the value of the variable matches the name of a task that is a valid successor for your external task.

ISCBorisB

Job Variables are our friends

My problem isn't remembering "wherever the job was before the CGItask", that's easy enough to keep as a job variable

My problem is dynamically telling this external task that it's succesor is that job variable. As I understand it once the wft is compiled the successor's for each task are defined.

If this $task->SetSuccessorTask function existed I'd be all set, but I made that up and that's where I'm getting stuck

You are trying to do something like "Subroutine" Task. Although possible, in your case the following looks much easier:

1. Code what is logically a usertask unit as a pair of tasks: usertask proper + CGI Task.
CGI is always one of the usertask successors. The only CGI Successor is the original usertask (loop back).
2. Original owners of the pair are set identically, just like you would do for the single one.
3. CGI task changes the owner of it's counterpart and then

you would have to have the cgitask reset its ownership to the same as the usertask owner - probably after the callback.

With WFConstructor setting your own function to generate it is trivial

Adam Stoller

You are trying to do something like "Subroutine" Task. Although possible, in your case the following looks much easier:

1. Code what is logically a usertask unit as a pair of tasks: usertask proper + CGI Task.
CGI is always one of the usertask successors. The only CGI Successor is the original usertask (loop back).
2. Original owners of the pair are set identically, just like you would do for the single one.
3. CGI task changes the owner of it's counterpart and then

This is certainly another valid approach - simpler to code, but more "tasks" created for each instantiation of the workflow.

JMcNeil

I think I'm coming around fish!

Alright so I make a table of all tasks with fields like id and taskname. id 0 is the first task in the wft, 1 is the second, and so on in sequential order.

In the CDATA block of the wft, have a subroutine generate a successorset list for the external changeownership task (which is invoked by the CGItask to specify which user).

Then in the externaltask, $transition = "select id from alltaskstable where taskname='grandparent's taskname'" and then CallBack ($transition, $comment)

Have I filled in the blanks?

Adam Stoller

I think I'm coming around fish!

Alright so I make a table of all tasks with fields like id and taskname. id 0 is the first task in the wft, 1 is the second, and so on in sequential order.

In the CDATA block of the wft, have a subroutine generate a successorset list for the external changeownership task (which is invoked by the CGItask to specify which user).

Then in the externaltask, $transition = "select id from alltaskstable where taskname='grandparent's taskname'" and then CallBack ($transition, $comment)

Have I filled in the blanks?

I think you're over-complicating things - draw yourself a picture, or two, and layout a simple table and "play workflow" and you should be able to figure it out.

Otherwise - go for the simpler approach already suggested - consider them as pairs-of-tasks with a separate cgitask for each usertask that you might reassign - and then you only have a single callback for each instance of the cgitask (all the cgitask elements can reference the same cgitask script)