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

New 6.1 annoyance - attach to existing job

System

One of my users was complaining that some of his jobs were getting trapped in our datadeploy failure task. Upon closer investigation, it turned out that the ones that were failing had an attached file with no metadata. Tagging is the first step in all of our workflows, so I was a little curious how this had happened. It turns out that he had attached the file to an existing workflow (which of course, was already past the tagging step).

Is there a way to disallow attaching a file to an existing workflow? Or to cause it to force the entire workflow back to the start task when a new file is attached?

Find more posts tagged with

Comments

Dwayne

I don't think that what you're asking for is supported. If it's a usertask, then the owner of that task is going to have the ability to attach new files, unless it's read-only.

About the best I can come up with is an externaltask after key usertasks (and grouptasks) that validate that all attached files meet whatever criteria you set (metadata set, in your case). Then you could loop from that external task based on the result of your test.

BTW - this isn't new with 6.1. It's been that way "forever," as far as I know.

--

Current project: TS 5.5.2/6.1 W2K

Edited by Dwayne on 10/21/04 08:41 AM (server time).

Migrateduser

In this case, he wasn't even attaching from a usertask - he was attaching from the wizard. This is kind of scary when you think about it, because it could potentially allow a user to skip approvals in a mult-approver workflow. Later approvers would have to be pretty clever to realize that a user had snuck on a file without the prior approvers seeing it.

I have a job that includes a dummy task after all the reviews have completed. I just tried an experiment to see if I could attach an unapproved file to it, and they seem to have at least disallowed that. I'm not sure what the criteria is that determines which jobs are listed in the pulldown in the wizard. I would look it up in the 6.1 user guide, if such a thing existed. Needless to say, the online help doesn't say anything about this.

Adam Stoller

dumytasks by definition, do not have a files element - so not being able to attach a file to a (presumably long-running) dummytask is probably not a valid test of anything (other than that dummytasks can't have files associated with them).

I believe Dwayne has pretty much outlined the salient pieces here - and that perhaps you should file a feature request for the ability to specify something like attach_files="f" (default would be "t" for backwards compatibility) to various task definitions to allow the workflow developer to prevent users from attaching files to workflows in progress .. you'd want this on the task specification, not the job specification as there are many places where you'd probably like to be able to do something like automatically/programmatically generate files from a DCR and attach them to an externaltask.

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

gzevin

it's not only manual attachment. I already mentioned, that the new default behaviour of TS 6 makes some file attach to workflow without our explicit action (by editing a templated file - and it's not in Wizard, BTW, but from the workflow).

this 'feature' annoys **** out of me... IWOV thniks that adding new features that negate a lots of workflows' functionality is a good thing. I don't mind such features, but they HAVE TO BE CUSTOMIZABLE!!!!!!!!!

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU