EditTablePlugin Adding a 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) {
the
$lockUser
being returned is a canonical user ID instead of a wikiname, which is contrary to the spec of TWiki::Func.
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