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

iw_servlet_mail.ipl bug?

cocchi

Hi,

I'm having a problem with the send mail task within the workflow. Imagine a simple workflow Author - Email - Approver.

You have Author Task (Owner = UserA)
Email Task (Owner = UserA, Email= UserB)
Approver Task (Owner = UserB

Every time I try to email it sends the email to UserA instead of UserB.

When I checked the iw_servlet_mail.ipl script I saw the code

$this_task->GetOwner() as the "From" person
$target_task->GetOwner() as the "To" person

For giggles, I added some code to print out the descriptions to both $this_task, and $target_task

The problem is that they are both the same task (It's the Email task from my workflow)

Is this some kind of bug?

How can I have an email go from one person to another? (And have the proper name appear in the "From" box)

Find more posts tagged with

Comments

james1

What version of TeamSite are you using?!?

TS5.5.2 has a new e-mail script (iw_solution_email.ipl), which is intended to replace all of the prior (buggy) e-mail scripts. It is straightforward to associate target tasks with the e-mail, and it is also relatively easy to format the address as you wish (including proper name, for example).

Please see the examples in IWHOME/local/config/wft/soluttions. Also, there is a DevNet webinar on September 24 on out-of-the-box workflows. I imagine that the new iw_solution_email.ipl script would not be off-topic there.

-- James

Adam Stoller

Can you look at the generated wft and see how the iwsend_servlet_mail.ipl script is being invoked?

It should look (in your case) something like this [Unix]:


< command v="/usr/iw-home/bin/iwsend_servlet_mail.ipl Approver_Task someting"/>

I.e. there should be two command line arguments provided for the script - the first is the name of the successor task, and the second is supposed to be an email address (though from a quick look at the code in 5.5.2 it doesn't seem to be used).

If you only see one argument - the script should probably fail outright - so I don't think that's your problem here.

The question is whether the first argument is the name of the successor task or the current task - it should be the former.

--fish
(Interwoven, Curriculum Development)

cocchi

I'm game! How can I use the new script? Should I create an external task instead of an Email task?

Migrateduser

Since you are using Email Task, I can only assume you are using Workflow Builder. I forgive you for that. Smiley Happy

I also assume you are using Windows since I have no iw_servlet_mail.ipl script on my Solaris installation.

If you can look at the wft file that Workflow Builder spits out, I believe an Email Task turns into an externaltask that calls the iw_servlet_mail.ipl command with whatever inputs it needs. If it indeed puts the wrong parameters in the call to the script, you can change them manually in the wft file. This will solve your problem in the short term.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

cocchi

Here's the command line getting invoked

iw_get_mail_cmd('iwsend_servlet_mail','EmailApprover', $uApprover)

(Approver is the correct person it "should" be going to)

My predecessor is
<pred v = "CreateContent"/>
(owned by Author)

My successor is
<succ v = "WebReadyContent"/>
(owned by Approver)

It has me very baffled.

Migrateduser

I'm so glad I have never used the out-of-the-box email scripts that Interwoven provides with TeamSite. From the looks of the posts on email scripts, they cause more problems than they solve. I wrote a very simple perl script that uses Mail::Mailer and I can customize my email however I want it, including file lists and URL links to files. Allows me more time to complain about the documentation. Smiley Happy

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

james1

Dave

Would you like to share your script with everyone else on DevNet? It sounds like it could be generally useful to others.

-- James

cocchi

I don't have a problem with sharing my script. It doesn't work right anyway.

It's a basic Press Release script for a large institution.

There are four roles:
Author
Approver (PR Manager)
Emerging Channels Web Site Manager (tech guy/girl who posts to staging)
Emerging Channels Compliance (Legal review)

Migrateduser

OK, here's a sample of one of my workflow email scripts. I took out a bunch of stuff, but this works. You can see that all the different emails I want to send are defined by an index. You call this script from an externaltask passing in 2 parameters: a comma separated list of users you want the email sent to and the index to the message you want to send. I changed the name of our mail server, so you would have to modify that to define your mail server. We also have our own home grown email mapping config file that converts a login name to an email address. It's essentially a comma separated list (that's what emailSplit does). This may not work for everyone, but the beauty is you can format your emails however you like. Flame away...

Disclaimer: Since I posted this, I already noticed a couple cut and paste errors in my script, so go easy on me.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Edited by Smitty77 on 09/12/02 09:47 AM (server time).

Adam Stoller

> iw_get_mail_cmd('iwsend_servlet_mail','EmailApprover', $uApprover)
> [...]
> My successor is
> <succ v = "WebReadyContent"/>
> (owned by Approver)

The above, apparently generated, call to iw_get_mail_cmd is wrong - it should look like:

iw_get_mail_cmd('iwsend_servlet_mail', 'WebReadyContent', $uApprover);

Note the second argument - should be the name of the *successor* task.

--fish
(Interwoven, Curriculum Development)

cocchi

That seemed to fix my problem. Is there anyway I can get the GUI tool to remember that change? I'd rather not edit wft files by hand every time I make a change to the workflow.

What would be the External Task command line equivalent?

Adam Stoller

This would appear to be a problem with the WorkflowBuilder code/task generation in which it does not get a handle on the successor tasks' name for the Email Task but instead plugs in the name of the Email Task as the first argument.

Solutions I can think of are:

Make the owner of the Email Task be the same as the owner of the successor task. Email will still appear to be coming from / to the same person, but it will be the right person.
Leave the owner of the Email Task alone, but edit the wft to change the first parameter of iw_get_mail_cmd() to be the name of the successor task. You may have to do this each and every time you decide to edit the workflow using WFB
For the emailtask - you can select to use iwsend_mail.ipl rather than iwsend_servlet_mail.ipl. It's a bit more work - but if you create Task-level variables for the email task, you can define a number of task variables that iwsend_mail will use:
mail_cc (string)
one or more [comma-separated] addrs
mail_error (undef or defined)
default is undefined (off)
[if defined, will return a callback of '1' if an error occurs attempting to send the mail. Requires that the externaltask defines two successorsets]
mail_from (string)
email addr
mail_html (undef or defined)
defualt is undefined (off)
mail_message_file (string)
path to file, contents used for mail body
mail_message (string)
contents used for mail body
mail_subject (string)
contents used for mail subject
mail_taskname (string)
name of the successor task
mail_to (string)
one or more [comma-separated] addrs
mail_url (undef or defined)
default is undefined (off)
[if you are *not* using HTML formatted email, but still want URLs to tasks and such included in the email]
There are defaults for all the above settings - so you only need to set the ones you want to be different than the defaults
Use workflow builder only as an initial schematic generator for the wft and do all finesse work directly within the wft code - in which case you can use any externaltask script you want with whatever command line arguments you want to pass into it.
Don't use WorkflowBuilder at all - and just write the wft directly by hand. If you're comfortable doing so.

--fish
(Interwoven, Curriculum Development)

Adam Stoller

Dave,

Have you looked at iwsend_mail.ipl lately?
I just posted some information on it for a different thread [I think? It gets confusing some times] - but I think it provides the flexibility that you were professing in a much more open-way (your script appears to have lots of hard-coded assumptions in it as well as requiring everything to be passed in on the command line, which could cause problems if you are trying to handle a lot of files with long paths)

Take a look at the 5.5.2 version of iwsend_mail.ipl - I think you'll find that it does quite a bit more than it did back in the 4.x days.

--fish
(Interwoven, Curriculum Development)

Migrateduser

Yes I have looked at the newest iwsend_mail.ipl and it certainly has come a long way from the version I created for 4.2.1. You raise some good points, and there is a lot of hardcoded stuff in my script, but you know how it goes when you create a script and it ends up growing and growing as more functionality is requested. I am comfortable with it, and it serves our needs. I see that I could definitely do everything (I think) that I'm doing now with iwsend_mail.ipl. The URL stuff is confusing to me, and I'm not convinced it would produce the same URLs that I am creating in my script. As far as your argument that I have too many parameters, it looks like I could have a lot more parameters using iwsend_mail.ipl. That would be one **** of a command line if I even used only half of the flags that are available. And the iwsend_mail script is a really big script, and while it has some great block comments, it contains some fairly heavy perl concepts and few, if any, inline comments. I just feel more comfortable with my own script at this point. If my users, who are very finicky, decide they need a lot more information in their emails, I might be convinced to switch.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

cocchi

I think I'm going to go with the iwsend_mail option. Although I have to admit, Smitty77 posted some really cool stuff. I think my best bet is to stay out of the box for this one.

Now a really dumb question:
When I post a task variable how do I enclose the value? Do I use ('), ("), or something else? The email task works fine as long as I don't add a variable. Whenever I try to add one it breaks. Any thoughts?

-C

Migrateduser

Another thing I thought about if I wanted to try and convert to iwsend_mail.ipl from my home-grown script is that, because I have so many distinct subject lines and message bodies for different scenarios, I would still have to keep those strings hardcoded somewhere in order to pass them in to iwsend_mail.ipl. That would be as bad a maintenance issue as what I have now, as I would still have to make a similar call to some other script in order to retrieve the appropriate subject/body. I like that I can call my script with 2 parameters and have only one place to maintain my hardcoded values. For now anyway.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

Re command line arguments - the iwsend_mail.ipl script *allows* you to put them on the command line, but it also accepts them as task-level variables. That's the key point, all of the notification configuration can be made at the task-level rather than at the script level.

As for maintaining all the different subject lines - I can see ways around this - but it involves more Perl coding - so hey, use what you're comfortable with. I was just trying to point out that the OOTB script is far more flexible than it was in the past.

--fish
(Interwoven, Curriculum Development)

Adam Stoller

I'm not sure I understand your question regarding "posting a task variable" - can you perhaps provide a bit more context / code snippets?

--fish
(Interwoven, Curriculum Development)

cocchi

I was following the example you gave me #3 in your last post. I am trying to use the Variables section of the Task Attributes. I tried setting a variable with a key of 'mail_from' and a value of '$uAuthor'

It doesn't like any of that. In fact as soon as I add any variable it breaks the Email Task

Adam Stoller

Are you doing this directly within the WFT or are you talking about providing variables for the values of the keys within the WFB GUI?

--fish
(Interwoven, Curriculum Development)

cocchi

I'm using the GUI. That's why I've been killing myself with this. Since the workflows are going to change a bit, I want to at least try to avoid the temptation of editing the wft.

Migrateduser

Don't resist editing the wft. Go toward the light. Smiley Happy

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

cocchi

Normally I'd agree, but some less technical folks are going to have to manage this in the end.

Smiley Sad

Adam Stoller

It's a bit difficult, but can you describe the actions you take in WFB, and the show the resulting command line generated for the email task in the WFT?

I just tried this out - and it *looks* like it would do the right thing, but I haven't actually tried to instantiate and run the workflow yet [got a few other things I'm supposed to be doing right now...]

--fish
(Interwoven, Curriculum Development)