Clearing "owner" field in group task

TS 6.5
CSSDK 2.5
Win 2K

I have a group task that has " retainowner='f' "
when a user has "taken ownership" of that task and then transitions off that task, I would expect the Owner field to be cleared. However that does not appear to be the case. It appears that the owner field retains the owner's name until that task is reactivated.

I have tried to move a new CSUser into the job (via CSTask.setOwner() ) but I received the error "Operation not permitted". The CSUser object I tried to use was actually returned from getOwner() of another group task that had never been 'taken'. I expected it to make the original task owned by "<no user>".

I need to do this because if the workflow is "rejected" back to that group task, there is an external task that runs before getting to the group task that sends email. If the owner field is filled in, then the email is different than if the owner field is not.

Any clues?

Dan Bowker
Northern Trust
Web Publishing Technology

Find more posts tagged with

Comments

Migrateduser

Hi Dan,
I need a few clarifications on your use case. Here is what I understand, please correct me if I'm wrong -

o A user (user1) takes ownership of a group task (task1) and then transitions it.
o For some reason the next task/sequence of tasks is rejected and task1 is reactivated
o Even though the retainowner parameter is false, the owner of the task is still (user1)
o At this point your application tries to set another user (user2) as the owner of the task, and fails

When you created the job/workflow from a job specification, what was the initial owner of the group task, and was it shared by other users or groups? In a group task, only users or users in groups that are allowed to share the task, can take ownership of the task.

Best Regards,
Narendra

Edited by Naren on 04/15/05 09:02 AM (server time).

Bowker

nope -

1) User task Author
2) Email group or owner of next task
3) group task
4) email group or owner of next task
5) group task

All group tasks set to "retainowner=f"

Workflow makes it to stage 5 and gets rejected. The work flow then send control back to #2 to let the other group task users know it's back. However, when task #2 checks the owner of #3 it still has the previous owner so the other group members don't get notified.

There are times when I do want to notify just the owner, so just ignoring it isn't an option.

Dan Bowker
Northern Trust
Web Publishing Technology

iwovGraduate

... when task #2 checks the owner of #3 it still has the previous owner so the other group members don't get notified. ...

How exactly task #2 check for ownership of task # 3 ?
What do you see as the owner for task # 3 when in the output of iwjobc ? (when the workflow is at task # 3 after rejection)
Any of your externaltask scripts setting the retainowner attribute ? (just something to check)

Edited by iwovGraduate on 04/17/05 09:35 PM (server time).

Adam Stoller

I've had times where I've made explicit use of the information about owner of a past grouptask so the behavior you're seeing is correct as far as I know. When you *activate* the grouptask the second (third, fourth, etc.) time - the owner field should be blanked out but until it's activated it should retain information about who claimed it the previous time around.

You *might* be able to force a cleaning of the information by using a <resets> element within the workflow - perhaps in scripts for task 2 and/or 4 you can do a resets of the grouptask that is to follow before sending email?

The other solution would be to make your email script ignore the 'owner' field of a grouptask when sending email ...

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

Bowker

Using contentServices I get a reference to the CSTask and then get the owner of the task. It still has the old owner - it has not yet been cleared out.

Dan Bowker
Northern Trust
Web Publishing Technology

Bowker

I like the idea of doing a reset - I did a quick look through the contentServices doc and didn't see a way to do it programatically. Do you know of a way?

I guess I could add a "resets" clause to the group task in the e-mail task. If the retain owner is set to true - will that clear it? (I hope not)

Dan Bowker
Northern Trust
Web Publishing Technology

Adam Stoller

Let's start over again - the description you gave before of 5 sequential tasks didn't make sense - you indicated that the externaltask *before* the grouptask which has retainowner="f" will send email to the "group or owner of the next task" -- there should never be an 'owner' to even think about - you should only be looking at the group-for-sharing which you could probably capture in a job or task variable.

However - if you were going to add a resets clause into the task definition - I would do so in the externaltask that preceeds the grouptask - i.e. have task #2 reset task #3 and task #4 reset task #5. I'm not positive that it will do what you want, but I *think* it will.

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

Bowker

It looks like the 'resets' option will do what I want. I will give that a try. Unfortunatelly I've been pulled into another project for a few weeks, so this one will have to wait.
(I hate it when that happens!)

Dan Bowker
Northern Trust
Web Publishing Technology