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

Workflow passes user folder as file param

dazzlad

Hi.

I am working with TS6.1 on Solaris.

My issue is this:

When a user kicks off a workflow within a sub-folder of an area that folder is passed to the workflow as a 'file' parameter.
This is confusing to the user as they haven't explicitly checked the folder and it ends up attached to their task.

I don't recall this behaviour from 5.x
Has anyone experienced this and managed to get around it?

Many Thanks.
Darren.

Find more posts tagged with

Comments

Adam Stoller

Is this a 'submit' initiated workflow or a 'new_job' (or other?) initiated workflow?

Also - where are you finding this directory as being passed in - is this within the wft itself in iw_file, or is this within a cgitask where you're looking at form variables?

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

dazzlad

Hi.

I'm initiating with new job and no files checked.

In the .wft file i'm doing:

my @files=__VALUE__('iw_file');

and the first task is like this:

<externaltask name="AddFiles"
owner = "__TAG__('iw_areaowner');"
description = "Add Files to Workflow" start="t">

<areavpath v='__TAG__('iw_workarea');'/>
<successors>
<successorset>
<succ v = "StartFlow"/>
</successorset>
</successors>

<command v="/usr/iw-home/iw-perl/bin/perl /iwmnt/default/main/www/_LibMod/STAGING/WorkFlow/dummy.ipl" />

<template_script><![CDATA[
if(scalar(@files) >0){
__INSERT__('<files>');
foreach my $file (@files){
__INSERT__(qq|<file path="$file" comment="task file"/>|);
}
__INSERT__('</files>');
}
]]>
</template_script>
</externaltask>

Within the external tak i have:

my ($job_id, $task_id, $area, @files) = @ARGV;

......
......

foreach my $file (@files) {
log($file);
}

In the case that the new job is initiated in a subfolder of the workarea (with nothing checked) files is an array with the path of the folder i am in relative to the top of the workarea.

Thanks.
D.

Adam Stoller

Commentary:
Within the external tak i have:
my ($job_id, $task_id, $area, @files) = @ARGV;

I recommend you change this to be:my ($job_id, $task_id) = @ARGV;
my $task = new TeamSite::WFtask($task_id);
if (!$task->IsValid()){ ... do something ... }
my $area = $task->GetArea();
my @files = $task->GetFiles();In general, you don't want to assume all files were passed on the command line - there's actually a setting in iw.cfg (or used to be) to disable this because it isn't a good idea; and by just expecting the jobid and taskid, it makes it much easier to run the script from the command line when debugging problems.

All that being said, I'm not sure why you're seeing what you are - though it would be interesting to know if the same problem exists when you do make the change indicated above.

If I have time (no guarantee) I'll try to reproduce this problem on one of my systems...

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

dazzlad

Thanks!

But don't go out of your way to make the change.

I shall do it shortly and report back here....

Darren

dazzlad

Ok.

So i made your suggested changes and get the same results.....

My first task now looks like:

#!/usr/iw-home/iw-perl/bin/iwperl

use lib '/iwmnt/default/main/www/_LibMod/STAGING';
use TeamSite::WFtask;
use TeamSite::Config;

use FindBin qw($RealScript $RealDir);

use Fidelity::Log;
use Fidelity::Mailer;

my ($job_id, $task_id) = @ARGV;
my $iwmount = TeamSite::Config::iwgetmount();

my $task;

if(!($task = new TeamSite::WFtask($task_id))) {
mail_notify("WORKFLOW Error: Task '$task_id' Cannot be created in '$RealDir/$RealScript'");
exit;
}

if (!$task->IsValid()) {
mail_notify("WORKFLOW Error: Task '$task_id' is not valid in '$RealDir/$RealScript'");
exit;
}

my $area = $task->GetArea();
my @files = $task->GetFiles();

log($area);

foreach my $file (@files) {

log($file);
}

$task->Refresh();
$task->CallBack(0, 'Dummy Task');

You'll notice my code to log the information. After running TWICE in subfolders of a workarea with no files checked it looks like:

27/08/2004 13:02:51 /default/main/www/_LibMod/WORKAREA/WebTeam
27/08/2004 13:02:51 Presentation

27/08/2004 13:03:22 /default/main/www/_LibMod/WORKAREA/WebTeam
27/08/2004 13:03:22 Presentation/TopLevel

if i *do* check a file, then the folder isn't passed in.

Why do i always seem to find these oddities??

Thanks.
Darren.

Adam Stoller

I suggest you open a case with Support - as I don't believe this is the expected/correct behavior.

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

dazzlad

HI.

Support gave me the following to add to ui_custom.xml to override the default behaviour for 'New Job'.
Apparently TS6's default behaviour is to attach the current folder if nothing else is selected.

<link id="iw.ccpro.action_menu.new_job.link"
refid="_iw.ccpro.instantiator_popup.link"
label="new_job.button.label"
description="new_job.button.label"
commandID="iw.ccpro.new_job"
onClick="fs_invoke_with_selection"
resourceBundle="com.interwoven.ui.teamsite.ccpro.workflow"
public="true" />

May be useful if anyone else encounters this issue.
Thanks.
D.

Adam Stoller

I guess this is another one for the TS6 non-backwards compatibility issues list - sigh.
Thanks for doing the follow-up

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

dazzlad

Sorry,

I spoke to soon.

When I built the UI with their suggested fix, it prevented the workarea path being passed into the workflow, so i have passed it back to support.

I'll post again when I have a working solution, in cas anyone happens to be searching this issue...

Thanks
D.

dazzlad

A rather length reply from support which I'll summarise by saying you have to hack your way around this one.
Thanks
Darren.
_______________________________

Though the workaround provided to you did prevent current directory from being passed to the workflow invocation screen but there seems to be a problem since this current path is parsed by java application to create iw_workarea, iw_branch and other variables to pass to iwwft_instantiator.cgi hence preventing this path from being passed (as done earlier) would mean that java application is unable to create such variables.

Explanation

Java application parses the whole path of file or current directory passed from TS GUI to create values for branch, workarea and if there is any path after workarea it converts it to a file variable and hence if workflow is invoked from any subdirectory of workarea then it gets attached to the workflow.

Workarounds

1. Invoking workflow from top level of workarea will ensure that no directory is automatically attached with the workflow.

2. Filtering out such directories in your wft file by popping such directory in files list

This filters out the directory attached incase that is the only file atttched.

#################################################################################################################################

my @submit_file = (); # files sorted in unencoded

if (__ELEM__('iw_file')) # form, then html-encoded

{ # by hand via CGI_lite

@submit_file = map { TeamSite::CGI_lite::escape_html_data($_);

} sort __VALUE__('iw_file');

}

========================== This code has been added to filter out current directory ================================================

if(scalar (@submit_file) == 1){ #if there is only one file attach

my $wa= __VALUE__('iw_workarea');

my $iwMount = TeamSite::Config::iwgetmount();

my $filePath= $iwMount . $wa . "/" . $submit_file[0];

if(-d $filePath ){ # if the file attached is directory then remove it from list

pop(@submit_file);

}

}

=========================================================================================

for (my $i=0; $i<@submit_file; ++$i)

{

TAG_info(

"File_comment_$i" =>

[ html => $localizer->format('comment_label') .

"  $submit_file[$i]<br>".

"<textarea rows=5 cols=50></textarea>".

"<br> ",

error_msg => $localizer->format('comment_label_error_msg'),

is_required => 'false',

label => '',

],

);

}

3 Strip of remaining path after workarea from vpath in select WF screen ( not Recommended)

$iw-home\httpd\webapps\content_center\ccpro\workflow\select_wft.jsp

On loading of the form the following function modifies the value of vpath hidden variable to exclude directory path after workarea so that application does not create current directory as file path

##############################################################################################

<script>

function modifyVpath(){

if (document.selectWFT.vpath.value != null){

var vp= document.selectWFT.vpath.value;

var wa1=".*/WORKAREA/[^/]+/";

var exp1= new RegExp(wa1);

var wa2=".*/WORKAREA/[^/]+";

var exp2= new RegExp(wa2);

if (vp.match(exp1)!= null && vp.indexOf(“.”) == -1){ // checks for single vapth with no dot in it

document.selectWFT.vpath.value=vp.match(exp2);

}

}

}

</script>

</head>

<body onload= “modifyVpath ()”>

Limitations.

The only limitation the second option has is that it has no way of figuring out whether the directory attached is current directory or single directory selected by the user but since user will always attach files and never a single directory this can be accepted

The third option (apart from above) has also the limitation of not being able to figure out if the single attached file is a file or directory (being on client) unless file has got a dot character (.) in it so this will not be a feasible option to implement since it will skip files without dot (extension) in them.

Please let me know if second option is acceptable for your requirements, incase user is not invoking the Workflow from top of workarea.

Also please comment the link in ui_custom.xml and run make_tool.ipl again to revert back since the application needs current directory path to create variables for branch and workarea which are taken dynamically by wft file.

Adam Stoller

Method 2 is a [more] reasonable work-around but it does fail if the user pre-selects a single directory before invoking a job. Although seldom done in most cases it's not a true solution and while I'd recommend following this method for now, I'd also suggest that you continue to pursue this issue as a significant non-backwards-compatible bug.

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