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

Job Spec File & WFtask AddFile Method

djhalliday

Environment:

TeamSite 6.5 SP2
Windows 2003 EE

Background:

I'm using a job specification xml file to allow an external program to generate TeamSite workflows. These workflows are designed to be picked up by normal TeamSite users through a regular process. This has seemed to work fine, including setting EAs, etc., up until this point.

Problem:

The external program necessarily must log into TeamSite with master privelages in order to spawn workflows. For this, we have created a login separate from the workarea owner that this program uses. After a workflow is created, other TeamSite users take ownership of the workflow via a grouptask. The problem arises when a user that does not have master privelages tries to take control of the task. The workflow fails on a call to AddFile in a perl script that is called by a cgitask. Specifically, the call is as follows:

$task->AddFile($loc), where $loc corresponds to the area-relative path of the file (no leading /) to be added to the task.

Since the AddFile module doesn't seem to have been designed to return meaningful status codes, I've debugged the module and found that the correct Task ID and path are passed to the function. No file comments are passed, but those don't seem to be required to get successful completion. Using the same Task ID and path through the CLT iwaddfiletask works, however.

A couple questions - but the main one is: Is this a problem of permissions? It would seem to be, since running the same workflow with a user that is even in the mater.uid file seems to be fine. In the workflow job spec file, I am setting the task owners to the workarea owner as a general property, since I don't know which user will be actually taking control of the job. However, if an Admin user manually starts a job of the same wft (and all tasks are automatically set to their ownership), the workflow seems fine. Is there some kind of setting that I can change to allow non-Masters the ability to use AddFile??

Below is the job spec file. Things crash at the 'Deploy Content' task, which calls the perl script referenced above.

Thanks,
Derek

==========================================
<?xml version="1.0" standalone="no"?>
<!DOCTYPE workflow SYSTEM "iwwf.dtd">

<workflow name="Big Ticket Submission" owner="servername\admin" creator="servername\admin" description=" ">

<variables>
<variable key="error_info" value=""/>
<variable key="pals_info" value=""/>
</variables>

<externaltask name="Email Reviewer" owner="servername\admin" description="Emailing QC Team..." start="t">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successors>
<successorset description="Review content">
<succ v="QA Review"/>
</successorset>
</successors>
<command v="d:/Interwoven/TeamSite/iw-perl/bin/iwperl d:/Interwoven/TeamSite/local/config/wft/solutions/iw_solution_email.ipl -t "QA Review""/>
<files>
<file path="dcrpath" comment=""/>
</files>
<variables>
<variable key="iw_mailbody_pt" value="/../solutions/reviewer_iwmailbody.tpl"/>
<variable key="iw_mailheader_pt" value="/../solutions/reviewer_iwmailheader.tpl"/>
</variables>
</externaltask>

<grouptask name="QA Review" description="Review / revise files before previewing" lock="t" readonly="f" retainowner="t">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successors>
<successorset description="Approve: Deploy & Preview Content">
<succ v="Deploy Content"/>
</successorset>
<successorset description="Reject: Send to PALS maintainers">
<succ v="Email PALS"/>
</successorset>
<successorset description="Reject: End job, no email">
<succ v="The End"/>
</successorset>
</successors>
<sharedby>
<group v="servername\TSUsers"/>
</sharedby>
<activation>
<or>
<pred v="Deploy Content"/>
<pred v="Email Reviewer"/>
</or>
</activation>
</grouptask>

<cgitask name="Deploy Content" owner="servername\admin" description="Deploy content to preview and/or production" start="f" immediate="t">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successors>
<successorset description="Error occurred">
<succ v="Mail Error"/>
</successorset>
<successorset description="Approve: Version within TeamSite">
<succ v="Submit"/>
</successorset>
<successorset description="Revise: Edit and re-deploy content">
<succ v="QA Review"/>
</successorset>
<successorset description="Reject: End job, no email">
<succ v="The End"/>
</successorset>
<successorset description="Reject: Send to PALS maintainers">
<succ v="Email PALS"/>
</successorset>
</successors>
<command v="perl_script.ipl"/>
<activation>
<or>
<pred v="QA Review"/>
<pred v="Error"/>
</or>
</activation>
<variables>
<variable key="is_main_promo" value="0"/>
</variables>
</cgitask>

<externaltask name="Mail Error" owner="servername\admin" description="An error occurred, please fix ASAP">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successors>
<successorset description="Done">
<succ v="Error"/>
</successorset>
</successors>
<command v="d:/Interwoven/TeamSite/iw-perl/bin/iwperl d:/Interwoven/TeamSite/local/config/wft/solutions/iw_solution_email.ipl -t "Error""/>
<activation>
<pred v="Deploy Content"/>
</activation>
<variables>
<variable key="iw_mailbody_pt" value="/../solutions/reviewer_iwmailbody.tpl"/>
<variable key="iw_mailheader_pt" value="/../solutions/reviewer_iwmailheader.tpl"/>
</variables>
</externaltask>

<grouptask name="Error" description="Resolve error that occurred elsewhere in workflow">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successors>
<successorset description="Re-Deploy Content">
<succ v="Deploy Content"/>
</successorset>
<successorset description="Re-Version within TeamSite">
<succ v="Submit"/>
</successorset>
<successorset description="End Job">
<succ v="The End"/>
</successorset>
</successors>
<sharedby>
<group v="servername\TSAdmins"/>
</sharedby>
<activation>
<pred v="Mail Error"/>
</activation>
</grouptask>

<submittask name="Submit" owner="servername\admin" description="Content Submission" unlock="t" savecomments="t">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successorset>
<succ v="The End"/>
</successorset>
<activation>
<or>
<pred v="Deploy Content"/>
<pred v="Error"/>
</or>
</activation>
<variables>
<variable key="submit_cmt" value=" "/>
<variable key="submit_info" value=""/>
</variables>
</submittask>

<externaltask name="Email PALS" owner="servername\admin" description="Send email to PALS with comments indicating what's wrong">
<areavpath v="/default/main/bigticket/WORKAREA/bigticket_wa"/>
<successors>
<successorset description="End job">
<succ v="The End"/>
</successorset>
</successors>
<command v="d:/Interwoven/TeamSite/iw-perl/bin/iwperl d:/Interwoven/TeamSite/bin/iwsend_mail.ipl"/>
<activation>
<or>
<pred v="Deploy Content"/>
<pred v="QA Review"/>
</or>
</activation>
<variables>
<variable key="mail_from" value="servername\admin"/>
<variable key="mail_html" value="1"/>
<variable key="mail_message" value="Please see Job Comments below, for details."/>
<variable key="mail_subject" value="Rejected content - requires PALS update"/>
<variable key="mail_to" value="mailaddress"/>
</variables>
</externaltask>

<endtask name="The End">
<activation>
<or>
<pred v="Deploy Content"/>
<pred v="Submit"/>
<pred v="QA Review"/>
<pred v="Error"/>
<pred v="Email PALS"/>
</or>
</activation>
</endtask>
</workflow>

Find more posts tagged with

Comments

Adam Stoller

The external program necessarily must log into TeamSite with master privelages in order to spawn workflows. For this, we have created a login separate from the workarea owner that this program uses.

Hey Derek,
So far, okay.

After a workflow is created, other TeamSite users take ownership of the workflow via a grouptask.

Nit: Unless you're doing something via an externaltask, cgitask, or iwat trigger - the users are taking ownership of tasks within the workflow, not taking ownership of the workflow here. Probably not important to the issue at hand, but ...

The problem arises when a user that does not have master privelages tries to take control of the task. The workflow fails on a call to AddFile in a perl script that is called by a cgitask.

Okay - now we're getting to some interesting stuff here. The workflow fails in a cgitask when userA (who is not a 'Master' user) claims ownership of a grouptask.

Who owns the cgitask?
How was ownership on the cgitask set?

If this is the workflow I think it is - it's via an iwat trigger script - is the iwat trigger script running on this server?What are the permissions on the workarea, directory, and file with respect to the user who owns the cgitask? with respect to the user who took ownership of the grouptask? (if not the same)

[...]
Since the AddFile module doesn't seem to have been designed to return meaningful status codes,

Ah yes - feel free to contact Support about this - somewhere there's a bunch of bug reports / feature requests regarding error status and such - however - you should be able to replace the library call with a direct call to the CLT in which you capture the output to aid in debugging - something like: my $cmd = qq($iwhome/bin/iwaddtaskfile $taskid "$loc" "");
my @results = qx($cmd 2>&1);
if ($?){
# if you don't have a Log::Log4perl handle - just use 'die'
$logger->logdie("AddFile $taskid '$loc' =>\n\t".join("\t", @results));
}
[...]
A couple questions - but the main one is: Is this a problem of permissions? It would seem to be, since running the same workflow with a user that is even in the mater.uid file seems to be fine. In the workflow job spec file, I am setting the task owners to the workarea owner as a general property, since I don't know which user will be actually taking control of the job. However, if an Admin user manually starts a job of the same wft (and all tasks are automatically set to their ownership), the workflow seems fine.

While it would seem to be an issue of permissions - I think gathering additional information via the debugging technique above may help clarify the issue.

Is there some kind of setting that I can change to allow non-Masters the ability to use AddFile??

No - no such setting exists - AddFile does not require Master priveleges - but something else might be - and that's what you need to figure out.

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

djhalliday

Hi Fish,

Many thanks for the quick reply. Your analysis was correct - the iwat trigger was not running due to the fact that we had to change servers after the 1st one crashed

. I have re-registered the appropriate trigger with the backing store and all is working again.

-Derek

TommyWillB

Okay, so reading Fish's comments, I chose to use the command line solution.

The silly part is that the errors are easy to trap:

# ERROR:00017: Item already exists
# ERROR:02009: No file or directory found

But success doesn't say "SUCCESS"... It just shows the date and that darn buffer size message:
# [Sat Jan 31 12:08:47 2009] WARNING: Group buffer size should be 8192 bytes

To be explicit, was was thinking I'd test for the date [Sat Jan 31 12:08:47 2009].

Does anyone know if the Day-of-week (SAT) and month-of-year (JAN) will always be 3 digits?

Am I over-thinking this? Should I just be happen with:
# if ($ts_import_output =~ m/ERROR:/)

Adam Stoller

Okay, so reading Fish's comments, I chose to use the command line solution.

The silly part is that the errors are easy to trap:

# ERROR:00017: Item already exists
# ERROR:02009: No file or directory found

But success doesn't say "SUCCESS"... It just shows the date and that darn buffer size message:
# [Sat Jan 31 12:08:47 2009] WARNING: Group buffer size should be 8192 bytes

To be explicit, was was thinking I'd test for the date [Sat Jan 31 12:08:47 2009].

Does anyone know if the Day-of-week (SAT) and month-of-year (JAN) will always be 3 digits?

Am I over-thinking this? Should I just be happen with:
# if ($ts_import_output =~ m/ERROR:/)

Wow - a 3+ year old thread comes back to life ;-)
Are you using 6.7.1 (no-SP)? I ask because I believe the "Group Buffer size" issue was fixed in an SP for 671 - check the release notes.

The question is not what the output looks like on success - but whether the exit status is different for success and failure. As long as success returns a zero-status code, you only have to worry about false-error status codes - which 00017 clearly covers. I'd argue that 02009 is a real error, and one that you should be suspicious of.

As for date format - no - you should never count on the date format being consistent across releases / patches / service packs of TeamSite (unfortunately) - but there are modules you can use that can parse most date formats and then output something in a standardized format you can work with.

TommyWillB

Wow - a 3+ year old thread comes back to life ;-)

Yes, my client is using the non-SP1 version of 6.7.1. Unfortunately the "upgrade" would require "migration" level effort for their IT team, so it's more than they are willing to take on in these overworked-lean-staff'd-times.

However, when working with 3-year-old versions of TeamSite, these 3-year-old threads are exceedingly helpful. Sorry for the time-warp.

only have to worry about false-error status codes - which 00017

So, that's actually is my annoyance. How does one KNOW what all of these false-errors are. Is there an Interwoven documented list of error codes somewhere?

I stumbled on the 00017 by basic testing, but I worry that there are other scenarios I don't know about.

Seriously, it's always easier to do an if=true rather than if!=x && !=y && !=z then assume "true".

Fish, all of your posts here are great and truly helpful. So I take what you say here as the "best practice"... So don't interpret my desire for a better-best-practice as a criticism of your suggestion.

Adam Stoller

I agree that the error messages should all be documented - and I posted a list of FR's that I filed a bit before the end of last year, in which I believe that was one of them. Sometimes the only way to figure it out is trial-and-error.