Weird workflow error

I'm getting this error message (see attachment) when a user is trying to submit a change to a file that she (up till now) has normally been able to submit.

Note that I have doctored the usernames in order to not incriminate the innocent :-)....but, in this example:

1. tsuser2 is the owner of the file and the work area (in fact, she created the file);
2. tsuser2 is also the one trying to submit;
3. tsuser1 has not had anything to do with this branch/work area/etc.

So...I am confused as to why, even though tsuser2 is logged in, and submitting from her work area, why it would even think that tsuser1 has anything to do with it.

Any help/pointers/clues would be greatly appreciated.

Find more posts tagged with

Comments

Sailesh

Check if anyone has changed anything to the default submit workflow, seems some one must have done some hardcoding of user value and it is still there.

nipper

What workflow are you using ? Is this a custom or a out of the box ?

Tbag

If there's a group task defined in your workflow (or, actually any UserTask that pre-defines a username) and any member of of the GroupTask or UserTask will not have permission to operate on files attached to the workflow during the execution of the workflow, you'll get that error.

slarty

Hi...thanks for the responses.

Here are some answers:

1. There have been no changes to this workflow for sometime (about a year);
2. It is a custom workflow;
3. There are a number of usertasks/grouptasks in the workflow, and this user (or the group that she is in) is the owner of that task. I am still invetigating this more fully...but the strange thing is that this user was previously able to do this, and now, all of a sudden, she can't. And no .wft files have changed. I'm still trying to understand TeamSite permissions, but this one seems a bit odd.

Sailesh

Hi...thanks for the responses.

Here are some answers:

1. There have been no changes to this workflow for sometime (about a year);
2. It is a custom workflow;
3. There are a number of usertasks/grouptasks in the workflow, and this user (or the group that she is in) is the owner of that task. I am still invetigating this more fully...but the strange thing is that this user was previously able to do this, and now, all of a sudden, she can't. And no .wft files have changed. I'm still trying to understand TeamSite permissions, but this one seems a bit odd.

Can you post your wft file,

cute_guy

I'm getting this error message (see attachment) when a user is trying to submit a change to a file that she (up till now) has normally been able to submit.

Note that I have doctored the usernames in order to not incriminate the innocent :-)....but, in this example:

1. tsuser2 is the owner of the file and the work area (in fact, she created the file);
2. tsuser2 is also the one trying to submit;
3. tsuser1 has not had anything to do with this branch/work area/etc.

So...I am confused as to why, even though tsuser2 is logged in, and submitting from her work area, why it would even think that tsuser1 has anything to do with it.

Any help/pointers/clues would be greatly appreciated.

One of the possible cases the tsuser2 and 1 are part of a group, task in the workflow is owned by the group. The group task has the read only attribute set to f, so when the group task is invoked and the tsuser1 does not have permission to edit in the workarea the error message pop up is thrown

Adam Stoller

Hi...thanks for the responses.

Here are some answers:

1. There have been no changes to this workflow for sometime (about a year);
2. It is a custom workflow;
3. There are a number of usertasks/grouptasks in the workflow, and this user (or the group that she is in) is the owner of that task. I am still invetigating this more fully...but the strange thing is that this user was previously able to do this, and now, all of a sudden, she can't. And no .wft files have changed. I'm still trying to understand TeamSite permissions, but this one seems a bit odd.

I think the diagnosis of this being a grouptask for which both users (or at least the one for whom you're getting an error about) is a member of the sharedby users - either directly or via group entry for that task and that user does not have write access to the workarea to which the task is associated.

The reason this might have "suddenly happened" is likely to be one of [at least] two possibilities:

Without having access to the system - its difficult to provide any more detailed diagnosis.

slarty

Thanks to all for their responses...

It was a weird group thing happening. I changed the primary group (in the OS - we're using Solaris) to a particular group, and changed the group of the workarea to the same group ... and all is well. I can't admit to completely understanding what happened, as this user was the owner of that particular workarea. It seems to me that for a grouptask to successfully execute, it is not sufficient to be simply be the 'owner' you actually need to be in the group as well??

Anyway, we're back on the road...Cheers.