Yet another
EditTablePlugin error.
On my test server where I use
ApacheLogin. I put a table like the one below.
Then I hit the Edit button below the table (not the topic edit).
And back out using the browser back button. (leaving behind a lease file)
And then hit edit again.
And I get a blank page.
Deleting the lease file cures the condition.
This condition has arrived very recently. I have not yet nailed down the exact checkin but it worked in SVN 13225 (which is the version that broke the plugin with respect to editing a table with a header row.)
--
TWiki:Main/KennethLavrsen - 10 May 2007
Problem can also be seen on this bug item so it is same problem with
TemplateLogin server
--
TWiki:Main.KennethLavrsen - 11 May 2007
Found the checkin that causes the problem.
Author: CrawfordCurrie
Date: 2007-04-06 07:21:52 -0500 (Fri, 06 Apr 2007)
New Revision: 13287
Modified:
twiki/branches/MAIN/lib/TWiki.pm
twiki/branches/MAIN/lib/TWiki/Func.pm
twiki/branches/MAIN/lib/TWiki/OopsException.pm
twiki/branches/MAIN/lib/TWiki/UI.pm
twiki/branches/MAIN/lib/TWiki/UI/Manage.pm
Log:
Item3772: opened a can of worms when I realised the the TWiki::Func::getOopsUrl API isn't just broken, it's also pretty pointless and confusing. So I deprecated it, and added advice as to how to use getScriptUrl to achieve the same thing.
Crawford I guess you need to give this another iteration.
--
TWiki:Main.KennethLavrsen - 11 May 2007
Duplicate of
Item4032, and fixed by the same fix. At least, it works fine here.
CC
Now you get a conflict oops instead.
Reopening.
Item4032 was not fixed either. I wonder how you tested this. It fails also here on d.t.o in this very bug item as well as
Item4032.
KJL
You get a conflict oops because there is a conflict. That is the whole point of
Item3338. Or were you expecting some other behaviour? Please be clear about what you are reporting, because the behaviour looks correct to me ATM.
II
think you may be complaining that
Item3338 has re-emerged (which is a result of recent changes to the users code as Sven is iterating on the user mappers)
If that is indeed the case, please close this no-action, as it's a duplicate of
Item4032
--
TWiki:Main.CrawfordCurrie - 12 May 2007
Until the recent changes in redirect the edit table plugin worked perfectly in this respect!
Compare the two use cases.
Editing a topic the normal way
- User KennethLavrsen hits the topic edit link
- User KennethLavrsen hit the back button of the browser for some silly reason. He leaves behind a lease file.
- User KennethLavrsen hits the topic edit link again.
- User KennethLavrsen again goes into edit mode again without any conflict warning because the TWiki code correctly checks that it is the SAME USER that edits again.
Editing with edit table button
- User KennethLavrsen hits the table edit button
- User KennethLavrsen hit the back button of the browser for some silly reason. He leaves behind a lease file.
- User KennethLavrsen hits the table edit button again.
- User KennethLavrsen is now met with a conflict oops because with edit table the code fails to recognize the user as the same user that holds the lease.
In both cases it is the expected behavior that
another user is met with a conflict warning when a lease is in effect. But the
same user backing out and comming back should not be met with this.
It happens often that you go back to see something in normal view and then edit again. Or you have more than one table and hit the wrong edit table. And we can never teach the users to always use the cancel button. It works very well in 4.1.2 and there is no reason why it shall now be broken in 4.2.0.
Harald may not have implemented the code as cleanly as you would expect but the behavior to the user was the right one and I would like to see it restored.
--
TWiki:Main.KennethLavrsen - 12 May 2007
There is a good chance that this is the same problem as
Item4032. If Crawford is correct then the fix lies with Sven in a different part of the code..
Crawford - confirm that you agree with my spec above and then set it to Waiting for Sven. Do not set it to No Action because I want to make sure we remember to test that it is indeed fixed.
--
TWiki:Main.KennethLavrsen - 12 May 2007
Yes, your spec is correct. I fixed the blank page part of it, which was due to the redirect. The user mismatch is the outstanding problem, and I added a unit test for it.
--
TWiki:Main.CrawfordCurrie - 12 May 2007
Confirmed fixed by Sven's fix of Item4032 SVN 13744
Closed (in between releases bug)
--
TWiki:Main.KennethLavrsen - 15 May 2007
Cleaned "WaitingFor" field.
--
TWiki:Main.GilmarSantosJr - 10 Aug 2008