task owner is not allowed to set a comment on task?

Adam Stoller

Environment[indent]TS672P2
W2K3R2
VMWare ESX instance[/indent]
Background[indent]Customer is currently running TS650SP2 on W2K.
I'm trying to do a [new-server] upgrade for them, and taking their existing customizations and testing/fixing/verifying that they work.
This is, unfortunately, a very brief (1 week) and thus a somewhat ambitious project[/indent]
Issue[indent]I've actually made very good progress, but I'm now testing their workflow and running into a problem where an externaltask that sends email is failing to transition to the next task.

The script they're using is custom - towards the end of the script is the following:

...
    debug(__LINE__ . ": TASK: $task\n");
    debug(__LINE__ . ": TASK VALID: " . $task->IsValid() . "\n");

    $task->CallBack(0, "Completed email notification");

    debug(__LINE__ . ": Called back to workflow (0, 'completed email notification')\n"); #=#
    debug(__LINE__ . ": TASK: $task\n");
    debug(__LINE__ . ": TASK VALID: " . $task->IsValid() . "\n");
    ...

While the scripts' specific log file contains just the information I expected, and looking like it was successful, I [finally] found a bit more information, in-context, in the iwutild_cmdout.log:

...
    388: TASK: TeamSite::WFtask=HASH(0x2a34434)
    389: TASK VALID: 1
    User ****\yyy is not allowed to set a comment on task 1226.
    ERROR:02439: Operation not permitted
    392: Called back to workflow (0, 'completed email notification')
    394: TASK: TeamSite::WFtask=HASH(0x2a34434)
    395: TASK VALID: 1

The user is the owner of the task.[/indent]Has anyone else ever encountered such an error? And if so, do you remember the source and (hopefully) resolution of it?

I've opened a case with Support - but I figured I'd post here as well, just in case ...

Adam Stoller

Heh - this is kind of funny ....

It turns out that the task owner (****\yyy) had not been associated with any roles in that particular branch (or any of its parent branches) - and that is why they were unable to transition the task.

The funny part of it is that I thought about this while I was walking outside to go to lunch but dismissed it because usually the workflow instantiator will error out if any of the task owners do not have rights to the workarea. I guess the user may have had some access at the OS level - but completely lacked access at the TS level.

Anyway, the problem is resolved - now I get to work on the next one ... ;-)