Item6008: EditTablePlugin returns to viewauth page after save

Priority: Urgent
Current State: Closed
Released In: 1.0.0
Target Release: patch
Applies To: Engine
Component: EditTablePlugin
Reported By: TWiki:Main.ArthurClemens
Waiting For: Main.OlivierRaginel
Last Change By: KennethLavrsen
'Suddenly' EditTablePlugin does not return to normal view after saving. Take a simple table:

Num Item

After clicking Save the page is redirected to viewauth and the EDITTABLE tag is not rendered, and the saved value not updated the updated value can only be seen when reloading the page in normal view script.

Checking the code, the generated url passed to TWiki::Func::redirectCgiQuery is a view url.

-- TWiki:Main/ArthurClemens - 21 Sep 2008

Could it be something in my local setup? Here it seems to work.

No problem here, but the problem persists at

This happens (at least) on Mac Firefox 3.0.3 and Safari 3.1.2.

Release blocker!

-- ArthurClemens - 05 Nov 2008 - 00:01

Input from Sopan in TWikibugs:Item6008
My guess is - something wrong in - this is new introduction in trunk. From of Editable ==> goes everything well, after that the control goes to

-- ArthurClemens - 26 Nov 2008

An extra note: When it returns to viewauth the plugin does not work in that page view.

So it is more than just returning to wrong bin script. The plugin is goofed with visible EDITTABLE tags.

-- KennethLavrsen - 29 Nov 2008

I've checked the code, and it has nothing to do with viewauth or view. Sopan was right indeed.

What happens is that everything is set properly, but the redirectCgiQuery function does not cut the line of evaluation of rendering handlers.

For me, when we call that, we should finalize the Engine, but it doesn't look like it's been designed that way.

Could someone ask Gilmar what's the expected behavior of the redirect function in

I could hack some finalize there, but I want to have his opinion.

-- OlivierRaginel - 03 Dec 2008

What does "does not cut the line of evaluation of rendering handlers" mean, please?

Sorry, hadn't seen your message before.

By this I just meant that one might think a call to redirectCgiQuery will do the redirect right away. This is not the case, and in fact, a call to this function (or the redirect in, and a few others which get piled up) simply add the direct information into the headers.

Root cause of this bug was that these headers were being over-written by another call later on in the chain. This is what I called the "line of evaluation of rendering handlers". The fact that each registered handler is called in turn, for each possible handler "state".

By cutting it, I meant doing the redirect right away.

After discussing with Gilmar it seemed not the desired way to go, thus I just fixed the call that's used to set default headers, so it doesn't over-write headers that have already been set.

Hope that's clear enough, otherwise, see my commit smile

-- OlivierRaginel - 10 Dec 2008

ItemTemplate edit

Summary EditTablePlugin returns to viewauth page after save
ReportedBy TWiki:Main.ArthurClemens
Codebase trunk
SVN Range TWiki-5.0.0, Fri, 12 Sep 2008, build 17509
AppliesTo Engine
Component EditTablePlugin
Priority Urgent
CurrentState Closed
WaitingFor OlivierRaginel
Checkins distro:48eaf08a52e2 distro:1f43206d1044 distro:5fa880714e55
TargetRelease patch
ReleasedIn 1.0.0
Topic revision: r17 - 26 Dec 2008, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy