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

Dummy proof workflow

System

Our users complain about the way TeamSite workflow works:

1)When they click the run job button, there is no progress bar indicating that the system is working on creating a job instance. They will click the button run job button again and again.

2)They will double click instead of single click the run job button and create multiple jobs.

3)When the first task of a workflow is a cgi task and is set to run immediately, they will cancel out of the browser window created by the cgi task and think that they cancel the job. And they are mad to see that cgi tasks sit in their task list.

Just wondering if anyone out there have worked with similar users and actually have developed something to solve these problems. And no, telling them it's a training issue does not work.

Find more posts tagged with

Comments

Migrateduser

Interwoven, these are pretty frequent complaints. For the first issue, maybe use JavaScript to change the pointer to an hourglass. For the second, disable the button(s) after they press one. For the third, maybe your workflow instantiation form could be faster, otherwise I think you have to resort to training the users.

I think there are some old posts on the first two somewhere, or just google.

Migrateduser

Oh Jane, this was the post of the day. Just the title of the thread was outstanding. Honestly, the whole workflow process is archaic and hasn't been changed in many years. It is seriously in need of an overhaul. I think we all feel your pain and the solution for me is to have the least amount of people running workflows as possible so that we can realistically train all of them. Even with that, sometimes people are apt to mess something up once in a while.

3)When the first task of a workflow is a cgi task and is set to run immediately, they will cancel out of the browser window created by the cgi task and think that they cancel the job. And they are mad to see that cgi tasks sit in their task list.

Another wonderful byproduct of having a cgitask as your start task is that the ToDo list doesn't appear automatically when the job starts like it does for every job that doesn't have a cgitask as its start task. And so users have a different experience when starting those jobs and wonder what happened. It makes it look like the job didn't really start because you're right back where you started. I got some weak excuse for that once as well, but it wasn't serious enough in IW's opinion to actually fix.

I think ultimately you just learn to accept what you cannot change and become a contractor and make lots of money off of the shortcomings of this product. Smiley Happy

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

Migrateduser

Thanks, Smitty, for your compliments to my humble post. Maybe your are right. If I can become a contractor, make a lot of moneny out of all the enhancements and customizations, and don't have to deal with user complaints, then I could be happier. However, then I still have to count on Interwoven products not losing their customer base...

DevNet is a great thing. But finding the right information from old postings is not always easy. That's a tiny complaint for the day. I'm not going to start my own complaining business here, since noone can do as good a job as Smitty.

Migrateduser

I'm not going to start my own complaining business here, since noone can do as good a job as Smitty.

Are you flirting with me, Jane? Smiley Happy

You say the sweetest things. I could not get a nicer compliment. Thanks for that.

Seriously, I know a lot of people share your frustrations, but usually between support and DevNet, and perhaps screaming the loudest, someone typically can answer your questions. It might not be the answer you want, but an answer nonetheless. There is no shortage of frutration dealing with the IW suite of products. Making customers happy with this thing is an everyday struggle for many of us, dare I say a slew of us? Many of us have become pretty cynical, but every once in a while we say something useful. Hang in there. And besides, we need more chicks in here. Smiley Happy

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

Migrateduser

This is a professional forum, not internet chat room.

Migrateduser

Wow and a sense of humor, too. Lighten up.

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

nipper

Oh this one looks like fun.

I will try to avoid the pitfalls Smitty has stepped in, however when he does complain it is for a
good cause & trying to get the product improved. THat is a (very) long term goal.

One short term fix for you is to disable the submit button when the WF is initially being
instatiated. It was posted about a year ago, but I cannot find the code. You may want to search for
the code. It disables the submit button after the button was pressed, I beleive it was a
FR as well.

Andy

Migrateduser

Thanks. FR stands for Forums???

Migrateduser

feature request

Migrateduser

What a fun acronym that is...I can think of a few good definitions for FR, as far as Interwoven and TeamSite are concerned.

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

Migrateduser

I have not had any luck finding the code that you all know existed a year ago.

nipper

Had a user click the submit button twice (when it did not go away the first
time). Started 2 jobs with exactly the same info.

need to add a form close/open to the pre_tagtable_html like:

<form method=POST name="iwwft_instantiator" action=/iw-bin/iwwft_instantiator.cgi onsubmit="if(this.submitted) return false; this.submitted = true; return true;">

JonathonG

To solve this one:

>3)When the first task of a workflow is a cgi task and is set to run immediately, they will cancel out of the browser window created by the cgi task and think that they cancel the job. And they are mad to see that cgi tasks sit in their task list.

You could add code to your CGI which will end the workflow when the user clicks "Cancel" This can be done by adding a successorset which goes to the end task and doing a callback with the appropriate index. Or, more brute force, use the iwrmjob command to delete the job from the system.

To do this, your cancel button will have to do more than "window.close()" It would actually have to hit another cgi script of some kind which can do all of this cleanup. Not simple, but not overly complex, either.

Jonathon
Independent Interwoven Contractor

Migrateduser

Thanks everyone for the suggestions. In our case the immediate CGI task is the Interwoven supplied mtmetaproxy.cgi which launches metatagger for setting metadata. I'll have to see if anything can be down to the cancel button.

JonathonG

>In our case the immediate CGI task is the Interwoven supplied mtmetaproxy.cgi

Oh...that pretty well puts a damper on my suggestion Smiley Sad

>I'll have to see if anything can be down to the cancel button.

Good luck. I doubt you can do anything, but if you can, post the results here, as I'm sure many people would be interested in seeing what you come up with. Sorry I don't have any further suggestions.

Jonathon
Independent Interwoven Contractor

nipper

>Good luck. I doubt you can do anything, but if you can, post the results here, as I'm sure many people would be interested in seeing
> what you come up with. Sorry I don't have any further suggestions.

Esp Smitty. While he seems like a rabid dog, he is actually quite harmless & provides a nice bit of comic releif, al beit unintended.
No Smitty, we are laughing at you, not with you.

Migrateduser

Actually I couldn't care less about this particular issue.

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