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

Modifying The Default Author Assignment Template

santoshrt

Hi,

I need modify the Default Author assignment workflow to allow a dropdown based selection from a list of reviewers.The author then selects the reviewer from the dropdown.
I do not want the Approver/Reviewer task to be group task.
How can I achieve the above functionality.

Any pointers/clue would be helpful.
Thanks in advance.
Santosh

Find more posts tagged with

Comments

Migrateduser

This is somewhat covered in the workflow documentation but I suggest you study the example workflows to learn how they work and their internals.

santoshrt

Thanks for the reply,

But I was actually looking for a functionality where the author chooses the approver at runtime i.e when the workflow is in progress.

The example worklflow(serial_approval) does have a functionality where appover is chosen from a list,but that happens at the time of initiation of workflow.

Can this be achieved at runtime ?

Thanks in advance,
Santosh

Adam Stoller

Thanks for the reply,

But I was actually looking for a functionality where the author chooses the approver at runtime i.e when the workflow is in progress.

The example worklflow(serial_approval) does have a functionality where appover is chosen from a list,but that happens at the time of initiation of workflow.

Can this be achieved at runtime ?

Thanks in advance,
Santosh

Yes - it can be done at runtime - but that requires a cgitask script - which is a custom effort. You probably need to read the perldoc for TeamSite::WFtask along with the manual and/or the Workflow Tutorial Supplement - you'll need to write code to present the list of users from which to select the reviewer and then take the selected value and use it to modify the owner of the review task (which would need to be inially set to some existing user - usually

__TAG__('iw_user');

)

Migrateduser

Oh, I see. Yes, you can do this within the workflow after the job has already been instantiated. It's common use (and best practice in my opinion) to have this done as a separate task but in an external task, you should already have the task declared as an object.

$task->SetOwner("xxxxx","userid");

where "xxxxx" is your job ID. You could otherwise use the iwsettaskownerandarea command line tool but I prefer the method above.

Dave

ISCBorisB

Thanks for the reply,

But I was actually looking for a functionality where the author chooses the approver at runtime i.e when the workflow is in progress.

The example worklflow(serial_approval) does have a functionality where appover is chosen from a list,but that happens at the time of initiation of workflow.

Can this be achieved at runtime ?

Thanks in advance,
Santosh

As indicated before - it has to be custom. That said, there are few threads that can give you a jump start.
Check for example this one

Adam Stoller

Oh, I see. Yes, you can do this within the workflow after the job has already been instantiated. It's common use (and best practice in my opinion) to have this done as a separate task but in an external task, you should already have the task declared as an object.

$task->SetOwner("xxxxx","userid");

where "xxxxx" is your job ID. You could otherwise use the iwsettaskownerandarea command line tool but I prefer the method above.

Dave

Dave - I think you need to RTFM ;-)
SetOwner() takes a single parameter - which is the userid - there is no 'xxxx'
However - you also need to get the correct task object to manipulate - which will not be the task object associated with the script itself, but the task object for the review task - again - read the perldoc for TeamSite::WFtask and TeamSite::WFworkflow for information about how to do all this.

Migrateduser

Aha, I didn't read the "FM", rather I read the "FP" (fallacious Perl). I have no trouble admitting when I'm

wrong but I do have trouble admitting when you're right ;-) here is the Perl to which I was referring, in WFtask.pm of course:

sub SetOwner
{
my ($this, $user) = @_;
$this->{xml_valid} = 0;
# retrieve the current area (and reuse it)
my $area = $this->GetArea();
my $ret = TeamSite::WFutils::call_clt( "iwsettaskownerandarea",
$this->{id},
$user,
$area );
# ::TODO:: is it OK to let call_clt() run UTF8ToNative_2() on $user ???
return (0 == $ret);
}

Adam Stoller

Aha, I didn't read the "FM", rather I read the "FP" (fallacious Perl). I have no trouble admitting when I'm
wrong but I do have trouble admitting when you're right ;-) here is the Perl to which I was referring, in WFtask.pm of course:

sub SetOwner
{
my ($this, $user) = @_;
$this->{xml_valid} = 0;
# retrieve the current area (and reuse it)
my $area = $this->GetArea();
my $ret = TeamSite::WFutils::call_clt( "iwsettaskownerandarea",
$this->{id},
$user,
$area );
# ::TODO:: is it OK to let call_clt() run UTF8ToNative_2() on $user ???
return (0 == $ret);
}

So - is this you admitting that I was right? The code indicates that the first parameter,

$this

is a TeamSite::WFtask object - it's passed implicitly due to the nature of calling this subroutine as a method (

$task->SetOwner(...);

) and so there's only one parameter left - which is

$user

.
Since, unfortunately, the Perl API was never completely/truly built as an API - it calls out to the CLT

iwsettaskownerandarea

which takes 3 paramaters - the task's id (retrieved from the implicit

$this

parameter, the tasks' areavpath (retrieved by using the existing

GetArea

method), and the new owner's id (

$user

) which was explicitly passed in to the subroutine.

Or are you saying you interpreted this code differently?

Migrateduser

Well, yes. I think I'm saying that you were right. The comment chunk which I conveniently left out of my last post was the following:


=head2 SetOwner($user)
We only support User name in ASCII encoding...
Modifies the owner of a task
Returns zero on error; non-zero on success.
=cut

Conflicting, huh? Yeah, well that's Interwoven, isn't it :-) so while at face value, it appears that you need to pass in two variables, it's possible (and perhaps correct) that the task object is implicitly passed in. In this case, when I gave the example of $task->SetOwner('xxxxx","user"), that would have been wrong. That seems to be how this routine is used. Supporting this is the error message one gets when calling this module independent of the task object and passing in only one argument.

So, no, I wasn't interpreting it differently. I was perhaps taking it at face value :-)

Adam Stoller

Well, yes. I think I'm saying that you were right. The comment chunk which I conveniently left out of my last post was the following:
=head2 SetOwner($user)
We only support User name in ASCII encoding...
Modifies the owner of a task
Returns zero on error; non-zero on success.
=cut
Conflicting, huh? Yeah, well that's Interwoven, isn't it :-) so while at face value, it appears that you need to pass in two variables, it's possible (and perhaps correct) that the task object is implicitly passed in. In this case, when I gave the example of $task->SetOwner('xxxxx","user"), that would have been wrong. That seems to be how this routine is used. Supporting this is the error message one gets when calling this module independent of the task object and passing in only one argument.

So, no, I wasn't interpreting it differently. I was perhaps taking it at face value :-)

I guess I don't see the conflict - the documentation is correct, the code is correctly written as a class method for OOPerl. Your problem seems to be that you weren't reading the code as OOPerl you were reading it as basic Perl.

However - I think we've side-tracked this thread sufficiently for now ;-)

santoshrt

Please let me know where can I find documentation for the perl modules available in iw-perl\vendor\lib\TeamSite which I can make use in building workflows.

Also the supplemental workflow document mentioned the following
"To ease implementation efforts a bit more with respect to this procedure the script,
setowner.ipl, has been included with the full distribution of this tutorial. This script
gets installed in some place like iw-home/local/bin/".

I could not find any such module.
Kindly let me know where I can find sample for the same

Migrateduser

Please let me know where can I find documentation for the perl modules available in iw-perl\vendor\lib\TeamSite which I can make use in building workflows.

use __IW_HOME__/iw-perl/bin/perldoc TeamSite::ModuleName

Adam Stoller

Please let me know where can I find documentation for the perl modules available in iw-perl\vendor\lib\TeamSite which I can make use in building workflows.

All the TeamSite::WF* modules have POD built-in - so you can just use iwhome/iw-perl/bin/perldoc to read the documentation for any of the modules.

Also the supplemental workflow document mentioned the following

"To ease implementation efforts a bit more with respect to this procedure the script, setowner.ipl, has been included with the full distribution of this tutorial. This script gets installed in some place like iw-home/local/bin/".

I could not find any such module.
Kindly let me know where I can find sample for the same

I believe if you search DevNet (the site, not the forums) that you'll find a tar or zip file that went with the tutorial and that contains that script. However, that script was created before the existance of the SetOwner() method being added to the TeamSite::WFtask module - and as such is no longer really of much value.