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

Discovering the context of a submit job.

rob1234

Hi,

I need to know the context in which a submit job was started. For example, a workarea could contain a subdirectory of “test”, which contains two modified files, 1.txt and 2.txt. Now the user could either navigate to the “test” directory and just click submit, in which case the workflow instantiator will do a listmodified under “test” and discover the two files. iw_file will be set for each of these two files. However, if the user specifically selects the two files it doesn’t check for other files but the result is the same, iw_file is set for both files.

My problem is that I need to know whether the user specifically checked the files, or just used the context in the navigation window. Unfortunately, handy parameters like “vpath” don’t seem to get passed when you click submit, and iw_file will be the same whatever was done.

Arghhh.

I know I could get this info if I created a cgi front end, but that would have to be run from a drop down menu, which our user’s wont go for. The only other thing I can think of is catching the instantiator on the proxy, but that seems really messy.

Help! This must be easy.

Thanks,

Rob

Find more posts tagged with

Comments

iwovGraduate

Why do you need to find if the users checked any files ? In other words what do you intend to do with this information in your workflow ?

If you need to include all modified files (within a certain directory), you can have an externaltask which will do it.

What version of TS ?
OS ?

rob1234

iwversion -> 5.5.2 Build 23679
on solaris 5.8 sparc

I have another workarea which has different files, but organised in the same structure. If the user submitted using the nav window context I need to check files under this equivalent subdirectory in the other area, and process them. However I need to ignore this other area if they are selecting specific files.

It's a bit more complicated than that, but its the basic idea.

Thanks,

Rob

rob1234

No one got any ideas on this? I'm really stumped.

Cheers, Rob

JonathonG

I believe that what you're asking is not possible. There isn't any way to detect the difference between a user selecting files and files being auto-selected by the Submit process. I've discussed this at length with a co-worker of mine who needed to do something similar but neither of us could come up with anything. Probably would be a good feature request.

Of course, I'd be more than happy to have someone prove me wrong.

Jonathon
Interwoven Developer
Allstate, Inc.

rob1234

Thanks for the reply Johnathon.

My only thoughts round it were redirecting the submit request, ie whatever gets run when you click submit, off to my own cgi, I could then save the vpath (which I'm guessing would still be there) and forward the request back to the "submit instantiator". Hardly elegant or supportable though. The other prob with this is you can't use the proxy remap, as iwproxy doesn't pick up the urls in iw-bin, I think. If anyone knows how to do that I'd be interested.

Cheers,

Rob

rob1234

Thought I'd post up my solution. It's a bit of a hack but here goes.

When you click submit you endup going through the standard teamsite function iwpresubmit.cgi (which is a compiled CGI, so not editable. What I did was to rename this cgi and put my own in it's place. In this new cgi I can then check the area path, and, if it's in my workarea where I wan't to override the standard function, I do a http refresh, pointing the browser over to the workflow instantiator (iwwft_instantiator.cgi). This does mean I don't have a list of files already colated for me (ala iwpresubmit), but it does mean I can check "name_0" and "vpath" and create my own list. If they click submit in an area where I just want standard submit functionality, I just forward the browser to iwpresubmit_original.cgi, which is the copy I made (obviously) of the original CGI, and all carries on oblivious of the extra step.

Of course this will need repapplying if Teamsite is patched, but I've not actually re-written any Teamsite code, so the effort is minimal.

Thought I'd share,

Cheers,

Rob

Migrateduser

Good work! Thanks for posting your solution,

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K

rob1234

A futher update...

HTTP refresh is not sufficient because you can run into limits of the number of parameters passable on a url (when you "select all" and click submit). I've had to change my code to return an auto-posting form, in the same fashion used by standard teamsite (ie using javascript.), to force the parameters through on the header.

Something like the following

<HTML>
<HEAD>
<TITLE>Submit</TITLE>
</HEAD>

<BODY>
<FORM METHOD="POST" TARGET="_self" NAME="tmp_post_form" ACTION="./test2.html">
<INPUT TYPE="hidden" NAME="testname" VALUE="testvalue">
</FORM>

<SCRIPT LANGUAGE="JavaScript">
document.tmp_post_form.submit();
</SCRIPT>
</BODY>
</HTML>