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

Transition Comment Pop-ups

ela

Hello,
is there a way to remove the pop-up window for task transition comments from one of our workflows? (We have TeamSite version 4.5.1 for Solaris)

Many thanks in advance!

(I also posted the same question in this forum: https://support.interwoven.com/cx/EZforum/forums/shoptalk/Forum.asp?F=21)

Find more posts tagged with

Comments

ela

Since I didn't get any replies on this, I asked Interwoven Support. They say there's no way to turn the Transition Comments box off. However, it has been posted as a Feature request, so we'll have to see what happens ;-)

ProfessorX

Has this feature come out yet?

The Professor-

Migrateduser

It's a feature request, so how does "never" work for you?

Smiley Happy

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

ela

Hi,
no, unfortunately I haven't heard any news about this yet. The answer I got was:

"There is no way to turn the Transition Comments box off.
This is a last chance effort for the user to enter a comment
and proceed to the next task. I asked several other consultants about this. They are not aware of a configuration setting that can turn off the Transition Comments box

There is a Feature request (12896) asking similar as you ask.
I have attached your case to that feature request."

I'll ask Support again about the status, and keep you informed. I suppose, if there are more customers asking for the same, it's easier to push it through, so please feel free to help!:-)

Regards,
Eldbjørg

ela

Goos news!:-)
Got a quick responce from Support:

"This will be fixed in TS 6.0 which will be released in Q3."

rollo

Just a thought (and a moot point now I suppose) but I guess you could edit the task_transition.html file and add the relevant stuff (run the doTransition() function, then submit the form) to the body onLoad event. So it'd pop up, submit itself and disappear. I haven't tried it though.

Phil

Migrateduser

ela, if you wanted the pop up to disappear and you already know what transition choice you are going to make, what rollo said would work.

ProfessorX

Wouldn't that work for every task transition thought? NG

If they were smart it would be listed as an attribute in the WFT file for each task.

The Professor-

rollo

hey, I didn't say it was a _good_ solution Smiley Very Happy

I like the idea of an optional task attribute such as 'showtransition' or something. Hopefully that's how they'll do it.

Phil

ela

Hi, and thanks for the suggestion! I'll try it out when I've got some time.

Greetings,
Eldbjørg

Migrateduser

I'd like to re-open this issue. I have just completed work on my most complex workflow, consisting of multiple concurrently nested workflows and several approval/test tasks along the way. The customers who requested this workflow are not very TeamSite friendly - they just got down to their last straw and needed to automate this process and TS Workflow was pretty much the only option where we have any expertise. The biggest complaint I am getting from these people is that there are way too many user inputs required to do what they consider to be a simple automated process. I can't say as I blame them for their concerns. The biggest pain points are the transition comment pop-ups - we don't use them or need them, but still can't turn them off. Why this is a "feature request" and not a bug is beyond me. A bug doesn't have to be something that doesn't work - it's also something that doesn't work properly. Transition comment pop-ups are often useless and we should be able to turn these things off but we can't - to me that's a bug. Call me crazy.

The next biggest pain point is the fact that the nested workflows (WFT's not job specs) have to be manually started. I know this is another "feature request" but it's terribly annoying to people and in my opinion is more of a bug than a "feature". There's just no reason why a WFT can't be started automatically if I want it to. Make it an option.

These seem like trival things to fix to me. I'm likely to lose this customer and a summer's worth of work because of these trivial issues. That will also hurt TeamSite's chances of being used in any future projects as well. Interwoven already has lost one of our major internet groups - if they lose another we will only have one left and I'm sure our management will begin looking at other options. I can't see the bug or the feature request list and so I have no idea whether these issues are even being considered to be fixed. The transition pop-up thing is huge for us, and evidently other people as well, but what, if anything, is being done about it?

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

james1

> The next biggest pain point is the fact that the nested
> workflows (WFT's not job specs) have to be manually
> started. I know this is another "feature request" but it's
> terribly annoying to people and in my opinion is more of
> a bug than a "feature". There's just no reason why a WFT
> can't be started automatically if I want it to. Make it an option.

Dave

As you know, in TS5.5.2 SP3, we shipped a CLT, iwwft_compile.ipl, which allows you to instantiate a new job from a WFT, without requiring use of the WFT instantiator GUI. You can use that CLT in an external task to start a new job without user intervention. Note that the new job will not be intrinsically bound to the parent job, as with a wftask job. Maybe that's why you're not doing this.

As of TS6.0, you can start wftask jobs based on WFTs in the background without user action. Here is a snippet from the 6.0 iwwf.dtd:


<!-- ****************************************
     If background is 't', then TeamSite will attempt to start a job using the wftfile
     assuming necessary args will be provided in task variables (for details,
     see documentation for iwwft_compile.pl.  If background job creation fails,
     then the GUI will present the user the option to start a job.  Defaults
     to false (requiring user intervention).
     **************************************** -->
<!ELEMENT wftfile EMPTY>
    <!ATTLIST wftfile v CDATA #REQUIRED
                      background (t|f) "f">

-- James

--
James H Koh
Interwoven Engineering

nipper

>The biggest pain points are the transition comment pop-ups -
> we don't use them or need them, but still can't turn them off
I have to agree with this. This is a feature that a lost of my customers do not like.

SInce this is supposed to be in 6.0, and since 6.0 is based up the 5.5.2 backend, one would think that porting the code as a patch to 5.5.2 would not be difficult. Esp. when big TS users have been yelling for this for a while.

>Why this is a "feature request" and not a bug is beyond me.
Cause it behaves accoring to the "specs". Of course the specs are woefully lacking, but that is a feature. :-)
When the specs are ambiguous, then it is a "documentation bug" :-)

>The next biggest pain point is the fact that the nested
>workflows (WFT's not job specs) have to be manually
>started. I know this is another "feature request" but it's
>terribly annoying to people and in my opinion is more of a
>bug than a "feature". There's just no reason why a WFT
>can't be started automatically if I want it to. Make it an option.

No kidding. I am in the process of re-writing a fairly complex workflow due to the user revolt over this issue.

#SOAPBOX ON

Many features sit and languish because marketing departments ask "how much new revenue will we see due to this enhancement ?" Ones that score high get the attention. However the question could be "How much money will our customers spend on (typically outside) consultants writing workarounds ? Since companies now have a finite pot of money to spend on CM solutions, these 2 "features" have made that pot of money smaller at some large corporations. That is very important now that new license purchases are being reviewed but the available money is smaller.
#SOAPBOX OFF

Andy

P.S. Dave thanks for venting, it encourages others. Kinda like primal screams in college. :-)

Migrateduser

I definitely need these jobs to be nested so using iwwft_compile on its own will not work for me. I'm not sure I understand the background thing. Why can't the WFT just start and display the typical WFT UI (The TAG_info stuff) - as you would expect a cgitask to do if the immediate flag is set to "t"? I would still want the user to enter the information - the parent workflow wouldn't necessarily have that information prior to instantiation of the nested job.

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

james1

> > The biggest pain points are the transition comment pop-ups -
> > we don't use them or need them, but still can't turn them off
>
> SInce this is supposed to be in 6.0, and since 6.0 is based up
> the 5.5.2 backend, one would think that porting the code as a
> patch to 5.5.2 would not be difficult.

It would be nice if it were that simple. However, the popups are a result not of any workflow engine behavior but instead of the UI, which was rewritten in 6.0. Therefore, porting this behavior change back to 5.5.2 is not as trivial you as you seem to think.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

James - by relying on iwwft_compile to kick off a nested WFT automatically, you seem to make the assumption that the parent workflow will always know what the input values to all the TAG_info parameters in the child workflow will be. That's just not valid. That means I would need an extra cgitask prior to the wftask to mimic the TAG_info UI that exists in the child workflow, just so I can set these workflow variables that will make iwwft_compile work properly. That just makes no sense. Is there a reason why it's difficult to just kick off the WFT and allow the child workflow UI to pop up on its own?

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

Migrateduser

How does one turn off the transition comments pop-up in 6.0? I don't see anything about transition comments in the index of the 6.0 WF Developer's Guide or the 6.0 TS Admin Guide.

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

Edited by Smitty77 on 10/03/03 11:16 AM (server time).

Migrateduser

Why didn't the background flag make it into the 6.0 WF Developer's Guide? Why does it not surprise me?

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

Migrateduser

Anyone? James? Anyone?

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

ela

Hi, this comes very late, I know, but I'm somebody! As I haven't installed TS 6 yet, I haven't had the chance to check it out. I was expecting this possbility, so I would be disappointed if it's not possible (in a supported way). Hope to see a comment from an Interwoven person on this.

The hack mentioned earlier in this thread removes all popups, which works for me (TS 5.5.2, Solaris), since we don't need them.

Regards,
Eldbjoerg