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; } } }

no user added to the group task

traghu

Hello,

A problem was reported with one of the group tasks in a workflow and upon researching the problem, it is noticed that the <no user> is one of the users associated with that group task. The iwgetwfobj returns the following in the users element when run on that group task

<users>
<user v="appvise\akambath"/>
<user v="appvise\rthiruma"/>
<user v="& lt;no user& gt;"/>
<user v="appvise\lpatrick"/>
</users>

Other group tasks (which are working as expected) do not have the "<user v="& lt;no user& gt;"/>" associated with them and I think the problem with the problematic group task could be because of this no user association but I dont know for sure.

I am unable to remove the <no user> using the iwrmtaskuser because <no user> is not a valid user and hence that CLT does not do anything.

How can I resolve this problem? And any ideas on how the got added to the group task in the first place?

Thanks.

P.S. I had to put in a blank space between the "&" and "lt;" (also between "&" and "gt;" so I could post them without being converted to "<" and ">" , the data returned by the iwgetwfobj does not have that space!

Find more posts tagged with

Comments

kaalraa

Hello,

A problem was reported with one of the group tasks in a workflow and upon researching the problem, it is noticed that the is one of the users associated with that group task. The iwgetwfobj returns the following in the users element when run on that group task

Other group tasks (which are working as expected) do not have the "" associated with them and I think the problem with the problematic group task could be because of this no user association but I dont know for sure.

I am unable to remove the using the iwrmtaskuser because is not a valid user and hence that CLT does not do anything.

How can I resolve this problem? And any ideas on how the got added to the group task in the first place?

Thanks.

P.S. I had to put in a blank space between the "&" and "lt;" (also between "&" and "gt;" so I could post them without being converted to "<" and ">" , the data returned by the iwgetwfobj does not have that space!

Could you please provide your TS version number. If TS 6.7, please attach the list of Users (tsusers.xml).

traghu

Sorry for not providing that information.

The version of Teamsite is 6.5 SP2 on Windows 2003. We use Active Directory for authentication and role info.

Thanks.

Adam Stoller

I've never had to deal with this - and one has to wonder how that ever happened - but you might be able to create a small little Perl script that takes a taskid as an argument, builds a task object from that id, and then uses $task->RemoveUser().

It's possible that you can find some way to pass the string to/through RemoveUser such that it does what you want.

Just a thought ...

traghu

Thanks for the reply.

I already tried using the CLT as well as using the WFTask perl module to remove the "no user" (using various options to handle the < & > symbols) but no luck.

Yes, it is kind of tricky since the "no user" should not have been added in the first place since its not a valid user.

traghu

Any inputs that will help resolve this issue are appreciated. Thanks.

Adam Stoller

Any inputs that will help resolve this issue are appreciated. Thanks.

Is this a single isolated case or does it happen periodically? often? always? for this workflow? all workflows?

If it's truly a one-off, I think you're basically stuck killing and restarting the job.

If this happens for only one workflow, then it sounds like a programming error somewhere within that workflow (in an externaltask or cgitask script?)

If this happens for all workflows (including OOTB ones) - then I think you have a valid case to open with IWOV Support.

kaalraa

Thanks for the reply.

I already tried using the CLT as well as using the WFTask perl module to remove the "no user" (using various options to handle the < & > symbols) but no luck.

Yes, it is kind of tricky since the "no user" should not have been added in the first place since its not a valid user.

Run a script, extracting all the users of the group task within a loop. Check for each user, if it is in the format which your system usually defines as. If it does not match the condition, simply pass the id extracted to the method or CLT.

HTH

Adam Stoller

Run a script, extracting all the users of the group task within a loop. Check for each user, if it is in the format which your system usually defines as. If it does not match the condition, simply pass the id extracted to the method or CLT.

HTH

How would you expect them to get an id for a completely non-existent / fictitious / invalid userid that is already embedded in the job data?

Since the CLT's already suggested don't provide for removing such an entry, the only way you could remove it, that I can think of, would be if you could actually edit the contents of the workflow backing store - which I don't think you can, and sure as **** wouldn't try without explicit instructions from IWOV Support.

How the entry got there in the first place is a mystery (to us, and apparently them too) - but the fact that it got there breaks the workflow - so again, I think the only solution will be to kill the job and re-start it.

Mohan_Babu

Raghu,

Can you send the wft file.

~Mohan

values.java

traghu

OK, This problem exists for 6 active jobs, all created using the same workflow. But this same workflow has been used to create more than a 1000 jobs in the last 6 months

If it was only one job, then I could have suggested that the job be killed and a new one created. Since this is reported for more than one case, I am concerned it will keep cropping up.

I am pretty sure that this problem may not be occuring in the OOTB workflows as we have other custom workflows that have group tasks but dont have this problem.

One thing that I can highlight with this problembatic workflow is that the group task's users are updated based on user actions (which kicks off an external task to change the users associated with that group task). Basically, the external task removes all the current users (using WFtask's RemoveUser method) and adds a new set of users to the group task (using WFtask's AddUser method). This could be failing in a few cases. (please note that the same process works and has worked for 100s of other jobs created using the same workflow)

I will open a case with IWOV and see what they have to say, probably thay may have an answer to "how did the no user id get associated with the task" and recommendations to avoid this problem/situation and finally to fix the existing "corrupted" tasks.

Thanks for your responses.

Adam Stoller

OK, This problem exists for 6 active jobs, all created using the same workflow. But this same workflow has been used to create more than a 1000 jobs in the last 6 months

If it was only one job, then I could have suggested that the job be killed and a new one created. Since this is reported for more than one case, I am concerned it will keep cropping up.

I am pretty sure that this problem may not be occuring in the OOTB workflows as we have other custom workflows that have group tasks but dont have this problem.

One thing that I can highlight with this problembatic workflow is that the group task's users are updated based on user actions (which kicks off an external task to change the users associated with that group task). Basically, the external task removes all the current users (using WFtask's RemoveUser method) and adds a new set of users to the group task (using WFtask's AddUser method). This could be failing in a few cases. (please note that the same process works and has worked for 100s of other jobs created using the same workflow)

I will open a case with IWOV and see what they have to say, probably thay may have an answer to "how did the no user id get associated with the task" and recommendations to avoid this problem/situation and finally to fix the existing "corrupted" tasks.

Thanks for your responses.

I suggest you carefully check that externaltask script - I was kind of thinking that would be the way this happened - my guess is that AddUser() might allow you to add a non-existent and even invalid userid to a group task (if so - it's a bug and should be reported to IWOV) and that somehow the logic in your script is pulling that "<no user>" from somewhere and blindly adding it.