Item4032: EditTablePlugin: Adding and deleting table row is broken

This has happened in a very recent change.

Try yourself below

-- TWiki:Main/KennethLavrsen - 07 May 2007

Delete last row is also broken.

it seems related to redirecting. You end up on an empty oops page.

Whoever changed the plugin code last cannot have spent even 1 minute testing it.

-- KennethLavrsen - 07 May 2007

This bug was introduced with two SVN checkins

First SVN 13278 which caused a conflict oops to be shown when you add and delete rows.

And 2nd SVN 13287 which give a blank screen instead.

Both checins are Crawfords.

-- TWiki:Main.KennethLavrsen - 11 May 2007

13278 and 13287 have nothing to do with EditTablePlugin....

-- TWiki:Main.CrawfordCurrie - 11 May 2007

Yes and No. It is a core bug. But it is seen on EditTablePlugin.

I have confirmed that it is these checkins that causes the problem by rolling back to just before and after the checkins. There is no doubt.

-- TWiki:Main.KennethLavrsen - 11 May 2007

Sorry, but there is.

The sad story is that those two checkins combined to fix a couple of niggling core bugs to do with redirection. The EditTablePlugin was extended (Harald, Item3338) to support leases, but unfortunately the code wasn't quite right. It worked as long as the core bug was there, but now.....

The appropriate response is to fix the plugin, not re-break the core.

I checked through the other plugins in subversion; this is the only one that has this problem (indicated by a third parameter to TWiki::Func::redirectCgiQuery)

CC

The fix does not work at all.

You get a Conflict oops when you try to add a row which is wrong.

And even when you hit "try anyway" you end up in normal view mode and with no row added.

How much did you test this fix?

KJL

I tested it just fine, thanks. My change corrected the blank page, which was a result of the above checkings. However the effect you are seeing is not a direct result of the those checkins, but of more recent changes in the users code. The EditTablePlugin takes a lease when the table is opened for edit. It checks that lease when a row is added. At the moment it is not recognising that the user who took the original lease is the same user as is trying to add the row. This is because in this code:

     my( $oopsUrl, $lockUser ) = TWiki::Func::checkTopicEditLock( $theWeb, $theTopic, 'view' );
     my $wikiUserName = TWiki::Func::getWikiName();
     my $loginUser = TWiki::Func::wikiToUserName($wikiUserName);
     if ($lockUser  ne  $loginUser) {

Sven is currently working in this area, so the appropriate response is to add a unit test that verifies the functionality of TWiki::Func::checkTopicEditLock, so that Sven is warned.

CC

I read this after I edited Item4050. It is for sure the same problem in Item4050.

Sven can you confirm that you have the task to fix both this one and 4050 as Crawford suggests above.

-- TWiki:Main.KennethLavrsen - 12 May 2007

yup, fix commited, thanks for the test CC - Kenneth, can you confirm that things are working?

-- TWiki:Main.SvenDowideit - 14 May 2007

Confirmed resolved. Thanks

Closing. (in between releases bug - not for release note)

-- TWiki:Main.KennethLavrsen - 15 May 2007