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

WFconstructor's sharedby attribute

System

Could someone shed some light (or say RTFM) as to how the WFconstructor assembles the list of recipients when a sharedby attribute is included in a group task?

What I'm wondering is this: I'm using WFconstructor to declare a grouptask, but am also associating iw_solution_email.ipl with the task. So, the script sees the grouptask as the target task and what it does currently is send an email to "admins", which is the name of the group. However, I need for it to actually send it to all of the users within that group, which is how I understand that declaring sharedby => [["group","admins"]] is supposed to do.

I'm on TS 6.5 / Windows 2003 and I've tried using this with TS groups. Nothing.

What am I missing?

Thanks,

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Find more posts tagged with

Comments

Johnny

The shared by is used by the group task itself. Your email TPL needs to check if there is a shared by group and email it to that list by extracting the users from the group.

It's not wf constructor that is your issue - it's the email template.
The TPL is probably trying to read the owner field like it would in a normal user task.

So you have two things you need to do in your TPL,

Retrieve the shared by values.
Determine what users and hence what email addresses to send to.

John Cuiuli

Migrateduser

Johnny,

Thanks, that makes a lot of sense. I should have known to expect these types of things when I use IW's OOTB mail templates, in this case ccmail_header.tpl.

9 times out of 10, if you want something done right, don't reuse Interwoven's code.

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Migrateduser

if you're using the out-of-the-box iw_solutions_email.ipl script, then the "to" header if built by ccmail_header.tpl...

it understands if the task it's emailing about is a group or user task, to pull user or group nodes from <sharedby>, but it's not going to expand out the group for you like you're expecting (see snippet below)...

<to>
<iw_if expr='{iw_value name="user_task@owner"/} ne "<no user>"'>
<iw_then>
<iwov_emailmap user='{iw_value name="user_task@owner"/}' />
</iw_then>
<iw_else>
<iw_iterate var='user' list='user_task.users.user'>
<iwov_emailmap user='{iw_value name="user@v"/}' />
</iw_iterate>
<iw_iterate var='group' list='user_task.users.group'>
<iwov_emailmap user='{iw_value name="group@v"/}' /> <-- this is the key line
</iw_iterate>
</iw_else>
</iw_if>
</to>

two options for dealing with this...
1) iwov_emailmap is hard-coded to use /local/config/wft/solutions/email_map.cfg (NOTE solutions directory path!!)...edit the file to associate the group name with a comma-separated list of actual users in the group (maintenance headache, but simplest to implement)

2) toss the out-of-the-box code or modify it, so that you use Win32::NetAdmin instead to do a lookup of the OS group to get all members of it, which you can then convert to individual email addresses...

hth,
-Rori

awizardly

From my experience the group value in a sharedby value of a group task will be expanded. One thing to note about the iw_solutions_email.ipl is that you have to target the specific task that you want it to pickup the addresses from. So you would put <path to solutions>/iw_solution_emai.ipl -t <name of the target task>. Remember to use the name of the target task as defined in the workflow. This could be different depending on how you build your workflow. If you are using WFConstructor then there is an option in the declare_task that lets you instantiate with a string for an identifier and a seperate attribute called name. What you should be targetting is the value you have put in the name variable not the string used as a compilation identifier. To make things easy for myself I generally keep them the same and use the description variable to provide a more verbose indicator of task function.

clip_image001.jpg

Migrateduser

That it! I guess it's reasonable that it would take the email addresses from email_map.cfg, but it also seems like a "kludge" (-sp?) to define a group in the config file as a "user" in order to get around this. Is that the way it's really designed? It seems as though there are more elegant ways to go about this, but it works for my purposes!

Thanks,

Dave

Current Environments:
(1,2) TS 6.5 on W2K3
(3) Vignette V7 Portal on Solaris 9

Migrateduser

I guess another option is to create email distribution lists that correlate to the OS user groups, such that all members of OS group XYZ are also members of mailing list XYZ@company.com or ABC@company.com...if the name of the distribution list isn't the same as the OS group (default behaviour), then put in the solutions/email_map.cfg the email address of the mailing list for the OS group, instead of expanding it out...

while that cuts down on your email_map.cfg administration, it adds maintenance on the email administration, so you have to add new users to the groups in 2 places, not just one

or still, only 1 place, I think Exchange allows using domain groups as list members? been awile since I've poked around Exchange...

as for "Is that the way it's really designed?", you'd have to ask an Interwoven Engineer...I'm only interpretting the behaviour of the code they provided ;-)

cheers,
-Rori