I am deeply concerned about the new format for the topics
I am thinking about
author="TWikiUserMapping_KennethLavrsen"
I just tried to copy a newly edited topic from a MAIN installation to a 4.1.2.
And when you look at it it says the topic was last edited by
TWikiUserMapping
This means once you have been running on the beta there is no turning back once people have edited and created just a few days
I would personally not install a beta on production data under these conditions.
I think we need to choose a better way to define the next revision of the topic format to support the new mapping features - which are good features!
But I think we need a more compatible format. Either by making a new field in the META::TOPICINFO which 4.1 and earlier will ignore or by simply defining that
TWikiUserMapping does not prefix anything in front of the wikiname. New mappings do. That would be compatible for most since they most will come from the only mapping we had in 4.1.X and 4.0.X.
The need for being able to revert is also important at real releases. I have at least 3 times upgraded at Motorola and reverted back to previous version - because a show-stopper bug turned up that we had not seen before release. And then after a couple of weeks when the bug was fixed I would upgrade again. We have always been able to do that before even though the topic format changed. Somehow the changes were made so that the fallback performance was acceptable. So please everyone - consider an alternative approach to the new format. To me this is a release blocker.
--
TWiki:Main/KennethLavrsen
- 18 Jul 2007
yeah, i also worry about this - and you've given me an idea ... but.. in the last meeting (near the end, Peter asked me about this too - and I listed the reasons that the cUID is brutal at the moment -
http://twiki.org/p/pub/Codev/FreetownReleaseMeeting2007x07x16/FreetownMinutes2007x07x16.txt
to add to this, the cUID uses loginname again - as it used to be before cairo - so I presume your example is from one where allowloginname=off.
It
is possible that all the bug fixes i've done, and the Func work, may allow you to set TWiki::Users::TWikiUserMapping->{mapping_id}=''; - If you have time (i'm having a weird week) try it, run the unit tests, and see if it is better than when i last tried.
--
TWiki:Main.SvenDowideit
- 18 Jul 2007
I finally had time to work on this. (I also had a weird week)
I assume you mean change the file lib/TWiki/Users/TWikiUserMapping line 67 to say
$this->{mapping_id} = '';
Just tried to run a little.
Topic that were saved in the transition now show the
TWikiUserMapping prefix.
But if I edit and save it looks normal. And the saved topics are again in a backwards compatible format.
I will try and run unit tests. I am having a problem with my virtual machine (dies will not start) that I need to resolve before I can run them both in 5.6.1 and 5.8.X
Will anyone ever need to transition from one mapping to another? And how will that work?
--
TWiki:Main.KennethLavrsen
- 01 Aug 2007
I have my 5.6.1 up running now. And I have run - without modifying any code - all the units tests.
There are so many that fail miserably that it is difficult to see if more fails from altering code. The total test suite will not even complete.
I will open a bug report with my testruns as the output is now too long to post on twiki-dev.
Any particular tests I should run to verify that TWiki::Users::TWikiUserMapping->{mapping_id}=''; works?
--
TWiki:Main.KennethLavrsen
- 02 Aug 2007
Running the unit tests with the change is not even possible with the change (assuming that I understood it right).
# perl ../bin/TestRunner.pl -clean TWikiSuite.pm
exporting TWIKI_ASSERTS=1 for extra checking; disable by exporting TWIKI_ASSERTS=0
Assert checking on 1
Running TWikiSuite
Running tests from AccessControlTests.pm, AttrsTests.pm, AutoAttachTests.pm, ClientTests.pm, ConfigureTests.pm, ExampleTests.pm, ExceptionTests.pm, Fn_GROUPS.pm, Fn_IF.pm, Fn_INCLUDE.pm, Fn_NOP.pm, Fn_SCRIPTURL.pm, Fn_SEARCH.pm, Fn_SECTION.pm, Fn_SEP.pm, Fn_USERINFO.pm, FormDefTests.pm, FormattingTests.pm, FuncTests.pm, FuncUsersTests.pm, HierarchicalWebsTests.pm, InitFormTests.pm, MergeTests.pm, MetaTests.pm, PasswordTests.pm, PluginHandlerTests.pm, PrefsTests.pm, QueryTests.pm, RcsTests.pm, RegisterTests.pm, RenameTests.pm, RenderFormTests.pm, RobustnessTests.pm, SaveScriptTests.pm, SemiAutomaticTestCaseTests.pm, StoreSmokeTests.pm, StoreTests.pm, TOCTests.pm, TableRenderingTests.pm, TemplatesTests.pm, TimeTests.pm, UserMappingTests.pm, VariableTests.pm, ViewParamSectionTests.pm, ViewScriptTests.pm, CommentPluginSuite.pm, EmptyPluginSuite.pm, MailerContribSuite.pm, PreferencesPluginSuite.pm, TablePluginSuite.pm, WysiwygPluginSuite.pm
Running AccessControlTests
AccessControlTests::test_setInMETA
Assertion failed!
at /var/www/MAIN/lib/Assert.pm line 61
Assert::ASSERT('') called at /var/www/MAIN/lib/TWiki/Users/TWikiUserMapping.pm line 191
TWiki::Users::TWikiUserMapping::getLoginName('TWiki::Users::TWikiUserMapping=HASH(0x9bc4928)', 'guest') called at /var/www/MAIN/lib/TWiki/Users.pm line 320
TWiki::Users::getCanonicalUserID('TWiki::Users=HASH(0x99addec)', 'guest') called at /var/www/MAIN/lib/TWiki/Users.pm line 242
TWiki::Users::initialiseUser('TWiki::Users=HASH(0x99addec)', 'guest') called at /var/www/MAIN/lib/TWiki.pm line 1383
TWiki::new('TWiki') called at /var/www/MAIN/test/unit/TWikiTestCase.pm line 53
TWikiTestCase::set_up('AccessControlTests=HASH(0x9910124)') called at /var/www/MAIN/test/unit/TWikiFnTestCase.pm line 37
TWikiFnTestCase::set_up('AccessControlTests=HASH(0x9910124)') called at /var/www/MAIN/test/unit/AccessControlTests.pm line 27
AccessControlTests::set_up('AccessControlTests=HASH(0x9910124)') called at /var/www/MAIN/lib/Unit/TestRunner.pm line 43
Unit::TestRunner::start('Unit::TestRunner=HASH(0x96de4e4)', 'TWikiSuite.pm') called at ../bin/TestRunner.pl line 52
--
TWiki:Main.KennethLavrsen
- 07 Aug 2007
There's a relatively simple fix for this, and that's to use a different field in the TOPICINFO for the author UID - for example,
authoruid
, and reserve the
author
field for the display name of the author in the source system of the topic. Since old versions of TWiki use the
author
field exclusively, they will still see the wikiname of the user, and will just ignore the
authoruid
.
It's trickier to deal with old revisions, but with the above change in place I believe I am justified in dropping the priority to Normal (was Urgent).
CC
We can still do better
What Sven proposed was to let the old
TWikiUserMapping not have any prefix at all. On 4.1.2 and older we only had
TWikiUserMapping. So this is both forward and backwards compatible.
As long as people beta test with the good old
TWikiUserMapping the resulting topics as well as history will be fully compatible in both directions.
Is there anything that talks against this?
I tried to do the modification : lib/TWiki/Users/TWikiUserMapping line 67 to say
$this->{mapping_id} = '';
TWiki itself seems to run with this but the unit tests will not run so it is difficult to evaluate if this fix is safe.
Sven assumed it would work but had not had time to test it. What do you say Crawford? You have better overview of the TWiki code than most.
If this fix is good then I have no more worries.
If people start playing with the new mappings then it is OK that there is no safe way back to 4.1.2. I am sure people trying that will not use production data.
--
TWiki:Main.KennethLavrsen
- 08 Aug 2007
I'm afraid I don't have a particularly clear view of Sven's new code, but Ill see what I can do.
--
TWiki:Main.CrawfordCurrie
- 09 Aug 2007
Later: well, I made the changes, and updated all the tests so they pass. But there is one problem with that fix; edits made by the 'guest' user will still be credited to
BaseUserMapping_666
. There's a good reason for that. Sven moved the default users into their own user mapping, so that they would
always exist, irrespective of which further mapping was selected. This lets us do good stuff like have a default admin user. The trouble is that those users are still identified by their BaseUserMapping cUID if the topic is taken back to an older TWiki. It would be very complex to make a special case for this user.
I really don't think this is a killer problem though; the release notes can describe how to work around the issue (something like: "edits made by the TWikiGuest user will be credited to
BaseUserMapping _666. in the unlikely event that you see this username, you can simply change all occurences of BaseUserMapping_666 to
TWikiGuest using
sed
in your data dirs")
--
TWiki:Main.CrawfordCurrie
- 09 Aug 2007
Note that topics created in the last months here on Bugs now are shown as edited by TWikiUserMapping_SomeBody.
This is what I meant with not being able to release a beta until this was resolved.
Seems like we are getting close now with the help of Crawford. Our hero.
Crawford. Maybe as a beta test work around - to enable being able to get back - the guest user can be defined with a different name in configure and people can manually register a
TWikiUserGuest?
I have not tried this as I am sitting at work as I write this. I can try.
Then we can write this work around in a beta release note.
--
TWiki:Main.KennethLavrsen
- 09 Aug 2007
Crawford. Please view this topic after I just edited it. Lots of tags that are not supposed to be visible. --
KennethLavrsen - 09 Aug 2007
I suspect you fell foul of the glitch in the WYSIWYG. Unless you use Konqueror?
CC
todo: benchmark to compare speed between with and without mapper_ prefix - I expected there to be a performance loss, but I don't know yet
--
TWiki:Main.SvenDowideit
- 22 Aug 2007
Per agreement: Sven wants to benchmark the implementation before closing this. Assigning it to him
--
TWiki:Main.KennethLavrsen
- 23 Aug 2007
Ping. Beta is getting closer.
--
TWiki:Main.SteffenPoulsen
- 16 Sep 2007
Note the issue as such is fixed.
Sven just wanted to benchmark if the fix made was OK performancewise.
I would personally be happy to close this one - but let Sven make that call.
--
TWiki:Main.KennethLavrsen
- 16 Sep 2007
yeah, ok I'll track my perf testing elsewhere --
SvenDowideit - 01 Oct 2007