Item6008: EditTablePlugin returns to viewauth page after save

'Suddenly' EditTablePlugin does not return to normal view after saving. Take a simple table:

Num	Item
1	works
2	c

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.

• ArthurClemens - 02 Nov 2008

No problem here, but the problem persists at http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item6008

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 Response.pm - this is new introduction in trunk. From Core.pm of Editable ==> Func.pm goes everything well, after that the control goes to Response.pm.

-- 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 Response.pm?

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?

• CrawfordCurrie - 04 Dec 2008

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 Response.pm, 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

-- OlivierRaginel - 10 Dec 2008