The personal data folder changed from LOdev\3 to LOdev\4 but nothing was imported (and the now useless LOdev\3 folder was left behind...) Maybe the \3 folder can be optionally left around (in case people want to go back). I would recommend that during install user input was requested. Something like "Your personal data has been migrated to version 4. Would you like to remove the outdated personal folder?" NOTE: This was observed in Version 4.0.0.0.alpha0+ (Build ID: a2b3ee) master~2012-11-13_06.07.28_LibO-Dev_4.0.0.0.alpha0_Win_x86_install_en-US from Tinderbox Win-x86@6
*** Bug 57087 has been marked as a duplicate of this bug. ***
Some more information additional info (confirmation for Mac by Roman, developers working on that, ...) from mailing list
Thank you, Pedro, for reporting this, and thank you, Rainer, for CCing me! REPRODUCIBLE also on Mac OS X (10.6.8, Intel) with LOdev 4.0.0.0.alpha0+ (Build ID: 32315e; pull time: 2012-11-13 00:32:26). This master build for Mac OS X correctly creates the user profile folder at ~/Library/Application Support/LOdev/4/user/ ^ -- as expected. But it does NOT migrate any settings from the /LOdev/3/user folder to the /LOdev/4/user/ folder; not even the most general settings, like my user name, or the selected JRE appear in the /LOdev/4/user/ profile. It seems that the new (4) user profile is created from scratch, without attempting to copy any data from the old (3) user profile folder. → Changed Platform to All/All. → Increased Importance: IMHO this is at least a “major” issue, because when LibO 4.0 will be released, most users will expect that all their settings are correctly imported, and we would get bad press if we would not do that.
About the question: what to do with the old (3) user profile: (In reply to comment #0) > Maybe the \3 folder can be optionally left around (in case people want to go > back). I would recommend that during install user input was requested. > Something like "Your personal data has been migrated to version 4. Would > you like to remove the outdated personal folder?" This option could be a good idea. But if it is too complicated to implement such an option, please do NOT remove the old user profile folder by default; just leave it there! There always will be some downgraders, and other people -- like me -- switch between LibreOffice versions daily, just depending on the kind of task they need to accomplish.
Random notes: * Migration of extension information (stored in berkeleydb files within the user profile) needs to coordinate with potential removal of berkeleydb support from LO, cf. <http://lists.freedesktop.org/archives/libreoffice/2012-November/041109.html> "minutes of ESC call ..." * It appears that on case-insensitive file systems (Mac OS X, Windows), existing "3" user profiles got the "MIGRATED" flag file (<http://cgit.freedesktop.org/libreoffice/core/commit/?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94> "disable multiple migrations via MIGRATED stamp file") erroneously added when running LO 3 already, cf. <http://lists.freedesktop.org/archives/libreoffice/2012-February/027058.html> "User installation migrated onto itself." This needs to be taken into account when trying to migrate from existing "3" user profiles.
> This option could be a good idea. But if it is too complicated to implement > such an option, please do NOT remove the old user profile folder by default; > just leave it there! There always will be some downgraders, and other people > -- like me -- switch between LibreOffice versions daily, just depending on > the kind of task they need to accomplish. The idea to ask for user input is that LO/TDF passes responsibility to the user: if the user chooses to delete then s/he can't complain later that it was removed. If s/he chooses to keep it, s/he can't complain that there are left-overs.
Hmm, the supported migration paths are configured in registry, see the "Migration" section at http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Setup.xcu#771 I see only the release versions there. It seems that migration from "Dev" builds has never been supported. I guess that Dev builds could inherit configuration from a release build but not from the older Dev builds. The best solution would be to produce build-specific registry entry. I am not sure how to do it easily. Anyway, the migration should work in the official Alpha, Beta, RC builds.
Bug still exists in versions 4.0.0.1 and 4.0.0.2. Reproduced with Win 7, 32 bit, LO version 3.6.4. Then install version 4.0.0.1. Also reproduced with Win 8, 64 bit and version 4.0.0.2. Importance increased, hence users expect that all their data and settings of the user profile are still available, if they update to version 4.0.x AND all users with changes of their user profile are affected. Hence I expect a lot of user complaints, if this bug is not corrected. Furthermore it will not really raise the image of LibreOffice especially at the start of a new major release (Version 4.x.x). IMHO it's necessary to correct this problem before the release of version 4.0.0.
Harald - can you confirm that if you move away your user profiles; and run a released 3.x version - then run the 4.0 version - it does not import those settings ? FWIW - I hate this "not upgrading from -dev versions" thing - it was the underlying cause of tons of mangledness in this code for the last 3.x series releases and we need to stop distinguishing between -dev and non-dev releases wrt. migration I think [ perhaps having a different config directory for each -dev release ;-] But of course that requires some time + thought, and re-working the desktop/ code I guess [ I can't be working on this now sadly ].
@Michael: Somehow this all is rather unclear, I wonder what moron made status here NEW ;-) The only fact that counts is whether a 4.0 rc makes the job to update from a 3.x user Profile (and it should do that for any user profile starting from 3.3, and also OOo Profiles should be imported as far as possible (at least some basics like personal data like name ...) All tests I see here are from Master(?!) and to be honest, I currently I do not know whether a LODev Profile is intended to be updated from where ever. I think this definitively is not an ...alpha+ Version's bug. More or less reproducible with "LibO 4.0.0.2 rc - GERMAN UI / German Locale [Build ID: 5991f37846fc3763493029c4958b57282c2597e)]" {tinderbox: @6, pull time 2013-01-24 07:20(?)} on German WIN7 Home Premium (64bit). The effects were obvious, all my Extensions, Macros, own toolbars, security settings and so on were lost. BUT === I did not check whether there might have been an existing /4 user profile from any test before, and so my result does not count. Of course an existing /4 Profile should not be overwritten I will do an update test under controlled, clean test conditions Some additional thoughts and info: It might be risky all import all Extensions, there might be some not working with 4.0. Eventually they should all be disabled with a comment "please check ..." I did the Brute-force Method for my /4 Profile update and simply copied the /3 Profile to the /4 folder, and everything worked and all 3.6 settings were back after new launch of LibO. My request to Roman, Pedro, ... Can you please retry an update wit non-WIN-OS with definitively not existing /4 Profile from 3.6 to 4.0.0.2RC. All existing other profiles should be hidden to avoid interferences of our test environments (or explicitly state that your update was that way)?
Hello Michael, I'm not sure if I understand your question correctly, so don't hesitate to ask me again if necessary. What I did is: (1) LO version 3.6.4 is installed on Win 7 as a standard installation (no parallel installation). User profile in directory /3. (2) Install LO version 4.0.0.1 with Windows Installer. The version 3.6.4 is removed automatically during installation. /3 user profile still exists after installation. (3) Start LO version 4.0.0.1. A new /4 user profile is created. The /3 profile still exists too. Data from the /3 profile have not been moved to the new /4 profile. Michael as I understood it, you asked me to run version 3.x and then to run version 4.0. In the procedure above, it is not possible to do this, hence either only ver. 3.x or 4.0 is installed. What I expect: From https://www.libreoffice.org/get-help/installation/windows/ "You do not have to de-install any previously-installed version of LibreOffice. If you do have an existing installation of LibreOffice, all your preferences will be preserved and that old installation will simply be overwritten."
Also please make sure that the file "MIGRATED" is missing in the directory with "LibreOffice 3" user configuration. It is created there once the configuration is migrated. The file prevents multiple migrations and helps to find what is the last used configuration.
(In reply to comment #10) > The only fact that counts is whether a 4.0 rc makes the job to update from a > 3.x user Profile (and it should do that for any user profile starting from > 3.3, and also OOo Profiles should be imported as far as possible (at least > some basics like personal data like name ...) Agreed. > All tests I see here are from Master(?!) and to be honest, I currently I do > not know whether a LODev Profile is intended to be updated from where ever. > I think this definitively is not an ...alpha+ Version's bug. This just shows that I bothered to do an early test of a Master and report it with 2 MONTHS in advance. This was ignored as "should work". > Some additional thoughts and info: > It might be risky all import all Extensions, there might be some not working > with 4.0. Eventually they should all be disabled with a comment "please > check ..." Ideally this should behave as Firefox (check for compatibility/new versions) > I did the Brute-force Method for my /4 Profile update and simply copied the > /3 Profile to the /4 folder, and everything worked and all 3.6 settings were > back after new launch of LibO. I tested that as well and it worked > My request to Roman, Pedro, ... > Can you please retry an update wit non-WIN-OS with definitively not existing > /4 Profile from 3.6 to 4.0.0.2RC. All existing other profiles should be > hidden to avoid interferences of our test environments (or explicitly state > that your update was that way)? I can retry anything you need but on Win (XP and/or 7) only.
It works for me. I have just tested it with the 4.0.0.2 build on Windows and the configuration was migrated. Note that I had to remove the file C:\Users\pmladek\AppData\Roaming\LibreOffice\3\MIGRATED and the already existing C:\Users\pmladek\AppData\Roaming\LibreOffice\4 configuration. I guess that the confusion here is caused by the MIGRATION file and Dev builds. Once you run 4.0 Dev build, it migrates the LibreOffice\3 configuration and crates the MIGRATED file in the LibreOffice\3 user config dir. When you install 4.0 release build, it ignores LibreOffice\3 configuration because it has already been migrated. Also it ignores LODev\4 configuration because it is from the Dev build and thus potentially broken. I am not sure what is the idea behind the MIGRATION file but it has been there for ages. I guess that it was introduced to avoid another can of worms when migrating OOo-2.x to OOo-3.x. Note that normal users should not be affected by this bug because they do not install dev builds.
(In reply to comment #14) > I guess that the confusion here is caused by the MIGRATION file and Dev > builds. Once you run 4.0 Dev build, it migrates the LibreOffice\3 > configuration and crates the MIGRATED file in the LibreOffice\3 user config > dir. See comment 5: "It appears that on case-insensitive file systems (Mac OS X, Windows), existing '3' user profiles got the 'MIGRATED' flag file (<http://cgit.freedesktop.org/libreoffice/core/commit/?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94> 'disable multiple migrations via MIGRATED stamp file') erroneously added when running LO 3 already, cf. <http://lists.freedesktop.org/archives/libreoffice/2012-February/027058.html> 'User installation migrated onto itself.'" > I am not sure what is the idea behind the MIGRATION file but it has been > there for ages. I guess that it was introduced to avoid another can of worms > when migrating OOo-2.x to OOo-3.x. See commit linked above. I had assumed that the issue with the MIGRATED file had been addressed (<http://lists.freedesktop.org/archives/libreoffice/2013-January/043769.html> "minutes of ESC call ...": "Completed Action Items: need to rename the MIGRATED flag and unwind / test re-migration (Michael): apparently no need to do this - the new directory name takes care of it." But it does not look like the issue is addressed (and I fail to see how the new directory name, LibreOffice\4 on Windows, would take care of anything there). The best solution is probably to either (a) change the name of the flag file from MIGRATED to MIGRATED4 for LO 4 (MIGRATION_STAMP_NAME in MigrationImpl::alreadyMigrated in desktop/soruce/migration/migration.cxx) or (b) get rid of the flag file completely by effectively reverting the commit linked above. Case (a) has the advantage that, when migrating existing user profiles to LO 4 and such a migration leads to a broken LO 4 profile, the user can get out of that by just removing the broken LO 4 profile and starting over. Both cases have the disadvantage that if an old profile already caused migration problems once in the past (but only once, as it was flagged as MIGRATED afterwards), it may cause migration problems now again. I will take care to get solution (a) into libreoffice-4-0-0.
@Petr: That's quite nearby what I wanted to test and expected to see in my laboratory, so I think there is no need for my announced test? @Stephan: Thank you for assigning to you!
Tested on Mac OX 10.6 and recent LO 4.0.0.2: No migration, brand new /LibreOffice/4/ - folder. No "MIGRATION" file found in /LibreOffice/3/user/
(In reply to comment #17) > No "MIGRATION" file found in /LibreOffice/3/user/ The file in question would rather be .../LibreOffice/3/MIGRATED (note both directory and file name are different from what you state).
Started from zero on a Win7 x64 machine (deleted LibreOffice personal data folder) *Nothing* was imported from 3.6.4.3 to 4.0.0.2 File .../LibreOffice/3/MIGRATED is present but it is NOT related to LOdev (this machine NEVER had Dev build installed)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=67d23e3a99bbaaa5a4dff1f8f3a10bd8abd198fb fdo#57061: Use a new MIGRATION4 flag file for profile migration LO 3 -> 4 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
requested backport of the fix from comment 20 to libreoffice-4-0 (<https://gerrit.libreoffice.org/#/c/1867/>) and libreoffice-4-0-0 (<https://gerrit.libreoffice.org/#/c/1868/>)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=04f2233c6c8a503147105af86ad447f70d33ec71&h=libreoffice-4-0 fdo#57061: Use a new MIGRATION4 flag file for profile migration LO 3 -> 4 It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-0-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4615ff90bd09ea02aff7a4952f1eb5cf9307375e&h=libreoffice-4-0-0 fdo#57061: Use a new MIGRATION4 flag file for profile migration LO 3 -> 4 It will be available already in LibreOffice 4.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I checked this problem again with 4.0.0.3. There is an improvement to version 4.0.0.2, but as I checked it is not completely solved. My System: Win 7 Prof., German, 32bit This is what I did: Step [A]: Preparations in order to get a clean system: (1) All LibreOffice versions and help packs deinstalled. (2) Folders "C:\Program Files\LibreOffice 3.6" and "C:\Program Files\LibreOffice 4.0" don't exist. Some folders with LibreOffice administrative installations still exist in C:\Program Files. They are named "LibreOffice 3.x.x Parallel". (3) No existing user profiles, that means I renamed them to "...AppData\Roaming\XXX-LibreOffice" Step [B]: Installation of version 3.6.4: (1) Main installer, typical installation (2) Installation of German built-in help. All 2 packages are installed in "C:\Program Files\LibreOffice 3.6". Step [C]: Create and modify user profile with version 3.6.4: (1) Start LO 3.6.4. A user profile "...\AppData\Roaming\LibreOffice\3" is created. In folder "...\3" a file called "MIGRATED" has been created too !!! (2) Modify user profile, I did this: (a) Open an existing text file and close file. (Recent document) (b) Resize LibreOffice window (c) Change an option. I unchecked the option "Tips" (d) Open new text document and create an autotext and use it. (3) Close and start LO again. All changes of the user profile are still in effect. Close LO again. Step [D]: Installation of version 4.0.0.3: (1) Main installer, typical installation (2) Installation of German built-in help. All 2 packages are installed in "C:\Program Files\LibreOffice 4.0". Version 3.6.4 is replaced completely. The folder "C:\Program Files\LibreOffice 3.6" still exists, but it is empty. Step [E]: Start version 4.0.0.3 and check the user profile: (1) Start LO. A user profile "...\AppData\Roaming\LibreOffice\4" is created. The profile "../3" still exists. In folder ".../3 the file "MIGRATED" still exists. Additionally a new file called "MIGRATED4" has been created !!! (2) (a) Recent Document: not migrated !!! (b) Window size: not migrated !!! (c) Tips unchecked, migrated. (d) Autotext: migrated. (3) Close LO. (4) Rename profile "..\4" to "..\X4", rename "..\3" to "..\4". (5) Start LO 4.0.0.3. Now all 4 changes of the user profile are in effect. If you do the same procedure with 4.0.0.2 the result is different: (1) Start LO. A user profile "...\AppData\Roaming\LibreOffice\4" is created. The profile "../3" still exists. In folder ".../3 the file "MIGRATED" still exists. A file called "MIGRATED4" is not created. (2) (a) Recent document: not migrated !!! (b) Window size: not migrated !!! (c) Tips unchecked not migrated !!! (d) Autotext not migrated !!! (3) Close LO. (4) Rename "..\4" to "..\X4", rename "..\3" to "..\4". (5) Start LO 4.0.0.3. Now all 4 changes of the user profile are in effect. Conclusion: It seemed to me that parts of the user profile are migrated now (4.0.0.3), but not all. Hence bug reopened (with hesitation...)
Excellent testing! (In reply to comment #24) > Step [E]: Start version 4.0.0.3 and check the user profile: > (1) Start LO. A user profile "...\AppData\Roaming\LibreOffice\4" is created. > The profile "../3" still exists. In folder ".../3 the file "MIGRATED" still > exists. Additionally a new file called "MIGRATED4" has been created !!! > (2) (a) Recent Document: not migrated !!! > (b) Window size: not migrated !!! > (c) Tips unchecked, migrated. > (d) Autotext: migrated. > (3) Close LO. > (4) Rename profile "..\4" to "..\X4", rename "..\3" to "..\4". > (5) Start LO 4.0.0.3. Now all 4 changes of the user profile are in effect. I believe this proves that Migration CAN and SHOULD be improved. I opened a topic in http://nabble.documentfoundation.org/What-are-Preferences-when-moving-from-3-x-to-4-x-tp4033742.html but no one seems to be worried or (HOPEFULLY) they are using their time to fix the problem instead of writing :) Thank you for reopening the BUG ;)
I now also checked the migration of changes of the user interface (customizing). These changes are also not migrated. The general procedure is the same like in comment 24. First open a new text document. Then I did these changes in version 3.6.5: (a) Display of additional tool bar: View > Toolbars > Drawing (b) Display of additional icon in toolbar: context menu on toolbar Standard > Visible Buttons > New Document From Template (c) Change order of a menu: Tools > Customize... > Menus > LibreOffice Writer Menus: I just moved the item "New" below "Open..." After installing 4.0.0.3 the changes of the user profile made with 3.6.5 are lost !!! I do not know, if my problems according migrating the user profile are general problems. If this is the case I am not sure if it is a good idea to release RC3 hence I expect user complaints. Some general thoughts according migration from version 3.6.x to 4.0.x: (1) Is it not the easiest way just to copy (or rename?) the /3 user profile to a new /4 profile, if LO does not find a /4 profile at start? When I did this manually it always works for me. (2) The files "MIGRATED" or "MIGRATED4" are just confusing. As I understood they are necessary for development. Is it not better to banish them from a release version and find another solution for development? (3) Is it really necessary to use different folders for the user profile (".../3", ".../4", ...) when changing the first digit of the LO version? Is there possibly a compatibility problem? If not the "/3" or "/4" folder could be removed from the path. By the way: Does someone know if there is a forward compatibility of LO 3.6.x to /4 user profiles if they are renamed to /3? This may be interesting for users who like to go back from version 4.0.x to 3.6.x or for exchange of profiles between different systems or users.
In reply to comment 24 and comment 26: In general, what parts of an old user profile are migrated is controlled by configuration settings in the /org.openoffice.Setup/Migration tree (see officecfg/registry/data/org/openoffice/Setup.xcu). The data that is present there is apparently mostly what had been there for the migration from OOo 2 to OOo 3 already. The reason why certain parts of a user profile had been excluded from migration back than are probably lost to history. Note that this user profile migration code already kicked in on Linux during the LO 3 timeframe, when <http://cgit.freedesktop.org/libreoffice/core/commit/?id=9276f7d5740a28b342db2a9bcd8644ff2f4f5742> "fdo#32263" moved the location of the user profile from ~/.libreoffice/3 to ~/.config/libreoffice/3 and <http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b522673373797bbf53d795d53e0ec45175a5d67> "default config location has changed, look in old config dir when migrating" enabled LO's migration code to migrate from an existing ~/.libreoffice/3 to a new ~/.config/libreoffice/3. Therefore, at least my assumption would have been that that migration worked acceptably, or else (Linux) users would already have complained when upgrading from old LO 3 versions (that used ~/.libreoffice/3) to newer LO 3 versions (that used ~/.config/libreoffice/3) about settings getting lost. However, re-checking that now, things like the list of recently used documents indeed were not migrated back then, either. Apparently nobody looked at the migration machinery in detail, whether it works acceptably for migrating individual settings to a new LO 4 user profile. Addressing specific items from the above comments: * List of recently used documents: This apparently manifests itself in configuration items (in the user profile's user/registrymodifications.xcu) in the /org.openoffice.Office.Histories tree, which is not included in the migrated data. Whether there ever was or still is any good (technical) reason for that I do not know offhand. * Window sizes: These apparently manifest themselves in configuration items (in the user profile's user/registrymodifications.xcu) in the /org.openofice.Office.Views tree, which is not included in the migrated data. Again, wheter there ever was or still is any good (technical) reason for that I do not know offhand, but the odd format in which this data is saved makes it not unlikely that this was considered too fragile for migration at least in the past. * Autotexts: These apparently manifest themselves as files in the user/autotext/ directory, which explicitly are migrated (cf. ".*/autotext/.*" listed in /org.openoffice.Setup/Migration/SupportedVersions['OpenOffice.org3+OpenOffice.org2+StarOffice8+StarSuite8+Libreoffice3']/MigrationSteps['Common']/IncludedFiles in officecfg/registry/data/org/openoffice/Setup.xcu), and indeed an existing ~/.config/libreoffice/3/user/autotext/mytexts.bau is copied to ~/.config/libreoffice/4/user/autotext/mytexts.bau and works fine in LO 4 at least when I try that out with my local master build on Linux. So this needs further verification. * View - Toolbars - Drawing: This apparently manifests itself in configuration items (in the user profile's user/registrymodifications.xcu) in the /org.openoffice.Office.UI.WriterWindowState tree, which is not included in the migrated data. Again, wheter there ever was or still is any good (technical) reason for that I do not know offhand, but, again, the format in which this data is saved makes it not unlikely that this was considered too fragile for migration at least in the past. * context menu on toolbar Standard > Visible Buttons > New Document From Template: This apparently manifests itself in the file user/config/soffice.cfg/modules/swriter/toolbar/standardbar.xml. The migration data mentioned above lists ".*/config/soffice.cfg/modules/.*/toolbar/custom.*\.xml", but that apparently does not match this file, so it is not copied. What's the story there I do not know. * Tools > Customize... > Menus: This apparently manifests itself in the file user/config/soffice.cfg/modules/swriter/menubar/menubar.xml, which is not included in the migrated data. Again, what's the story there I do not know. * "Is it not the easiest way just to copy (or rename?) the /3 user profile to a new /4 profile, if LO does not find a /4 profile at start?" While most of the old data could indeed be reused, a new major release is generally considered a good point in time for incompatible changes in user profile data, thus demanding more sophisticated migration than wholesale copy/rename. There is at least some changes (like changing bundled extensions into core parts, and changing the database format for information about installed extensions) that benefited from this for LO 4. * "The files 'MIGRATED' or 'MIGRATED4' are just confusing. As I understood they are necessary for development." No, see <http://cgit.freedesktop.org/libreoffice/core/commit/?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94> "disable multiple migrations via MIGRATED stamp file" for the reason the MIGRATED file got introduced. Having said that, I personally think that design is flawed, and we best get rid of those flag files again; I have that on my to-do list. * "Does someone know if there is a forward compatibility of LO 3.6.x to /4 user profiles if they are renamed to /3?" There is no guarantee for that to work. If it works, it works by chance, not by design.
(In reply to comment #27) > * Autotexts: These apparently manifest themselves as files in the > user/autotext/ directory, which explicitly are migrated (cf. > ".*/autotext/.*" listed in > /org.openoffice.Setup/Migration/SupportedVersions['OpenOffice. > org3+OpenOffice.org2+StarOffice8+StarSuite8+Libreoffice3']/ > MigrationSteps['Common']/IncludedFiles in > officecfg/registry/data/org/openoffice/Setup.xcu), and indeed an existing > ~/.config/libreoffice/3/user/autotext/mytexts.bau is copied to > ~/.config/libreoffice/4/user/autotext/mytexts.bau and works fine in LO 4 at > least when I try that out with my local master build on Linux. So this > needs further verification. Also verified that it works fine on Windows when migrating from <http://download.documentfoundation.org/libreoffice/stable/3.6.5/win/x86/LibO_3.6.5_Win_x86_install_multi.msi> to <http://download.documentfoundation.org/libreoffice/testing/4.0.0/win/x86/LibreOffice_4.0.0.3_Win_x86.msi>. Argh, this is in line with "Autotext: migrated." from comment 24, so forget about this. I had apparently misread that as if it claimed "not working."
(In reply to comment #27) > In reply to comment 24 and comment 26: > > > * "Is it not the easiest way just to copy (or rename?) the /3 user profile > to a new /4 profile, if LO does not find a /4 profile at start?" While most > of the old data could indeed be reused, a new major release is generally > considered a good point in time for incompatible changes in user profile > data, thus demanding more sophisticated migration than wholesale > copy/rename. There is at least some changes (like changing bundled > extensions into core parts, and changing the database format for information > about installed extensions) that benefited from this for LO 4. The user folder should be copied... > > * "The files 'MIGRATED' or 'MIGRATED4' are just confusing. As I understood > they are necessary for development." No, see > <http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=995a87e5cf63fe1626245b62fef4aa71fa02dc94> "disable multiple migrations > via MIGRATED stamp file" for the reason the MIGRATED file got introduced. > Having said that, I personally think that design is flawed, and we best get > rid of those flag files again; I have that on my to-do list. IMHO a very good idea ;) > > * "Does someone know if there is a forward compatibility of LO 3.6.x to /4 > user profiles if they are renamed to /3?" There is no guarantee for that to > work. If it works, it works by chance, not by design. From a non-LibO developers point: Is there a possibility to check weather there were any major changes? Finally I did some changes: - Changed priority to highest (IMHO release of 4.0 _should_ be postponed because of this bug. If we expect, that something isn't working it should even not be called Beta, it should be called Alpha or even Daily! [I am very sorry for how this statement sounds like, it's a little bit too direct ;)] - I changed the URL. Oiginal URL: http://lists.freedesktop.org/archives/libreoffice-qa/2013-February/003560.html
I am sorry but this can't be taken as a blocker. Yes, it is annoying that some setting is lost. Though, it does not affect the functionality of the software. It is still well usable. Is it really a blocker when user lost the list of recently used documents or few 3rd-party extensions that even might need an update to work with the new release? Are these the most critical problems in this release? All linux users lost similar level of setting with the switch from LO-3.4 to LO-3.5 and I am not aware of any strong complains. BTW: I am very surprised by the sentence: --- cut --- "If we expect, that something isn't working it should even not be called Beta, it should be called Alpha or even Daily! --- cut --- I am sorry but this is non-realistic. It would mean that we would not be able to release next few years until we fix all bugs and regressions caused by all fixes. Note that it would include implementing all missing features for 100% import/export from/into the supported file formats to avoid any potential "data loss". Unfortunately, the software would be very outdated in compare with the competitors at this point. Please, read also https://wiki.documentfoundation.org/ReleasePlan#Summary. The time based release means that .0 release is intended for enthusiasts. It might include include even annoying bugs. I am sorry if the above sounded too strong. It was just a reaction on the previous quite strong comment. I wanted to emphasize that the situation is not that easy and we have to see it from different point of views :-)
(In reply to comment #30) > I am sorry but this can't be taken as a blocker. Yes, it is annoying that > some setting is lost. Though, it does not affect the functionality of the > software. It is still well usable. > > Is it really a blocker when user lost the list of recently used documents or > few 3rd-party extensions that even might need an update to work with the new > release? Are these the most critical problems in this release? If you describe it like that no > > All linux users lost similar level of setting with the switch from LO-3.4 to > LO-3.5 and I am not aware of any strong complains. True > > BTW: I am very surprised by the sentence: > > --- cut --- > "If we expect, that something isn't working it should even not be called > Beta, it should be called Alpha or even Daily! > --- cut --- > > I am sorry but this is non-realistic. It would mean that we would not be > able to release next few years until we fix all bugs and regressions caused > by all fixes. You are very right at this point. But the problem is: We can't fix that later on ( or only for 5.0 which definitely is not in the very near future...) > Note that it would include implementing all missing features > for 100% import/export from/into the supported file formats to avoid any > potential "data loss". Unfortunately, the software would be very outdated in > compare with the competitors at this point. +1 > Please, read also https://wiki.documentfoundation.org/ReleasePlan#Summary. > The time based release means that .0 release is intended for enthusiasts. It > might include include even annoying bugs. Year I totally understand your point, but here my reason for this sharp sentence above (I didn't get it sound more friendly - sorry for that) > I am sorry if the above sounded too strong. It was just a reaction on the > previous quite strong comment. I wanted to emphasize that the situation is > not that easy and we have to see it from different point of views :-) Of course. And the most important aspect: You have more experience on how to release a program :-) But please read my rephrased argument ( it isn't sharp any more AND you were not too strong): If we didn't do it in 4.0 we have to do it with 5.0 [2016-2018 IMHO] --> We should do this ASAP with (if that is possible) 5.0 testing builds...
(In reply to comment #30) > Is it really a blocker when user lost the list of recently used documents or > few 3rd-party extensions that even might need an update to work with the new > release? Are these the most critical problems in this release? No. Those were examples. I think we have no idea of the extent of loss. But here are some more problems http://ask.libreoffice.org/en/question/11416/how-to-read-custom-color-from-file-libreoffice/ > All linux users lost similar level of setting with the switch from LO-3.4 to > LO-3.5 and I am not aware of any strong complains. Then it's ok because people don't complain? > Please, read also https://wiki.documentfoundation.org/ReleasePlan#Summary. > The time based release means that .0 release is intended for enthusiasts. It > might include include even annoying bugs. That is a Developer perspective. From a USER and PUBLIC perception it is a MAJOR update. So having a BAD .0 release is simply BAD marketing. If renaming the \3 to \4 folder solves many problems, maybe comparing what is the difference between the renamed \4 and the imported \4 could bring major improvements?
I tried LO4 RC3 and discovered all my personal settings gone..... now I am here, and I am discovering there is a debate going on the relevance of this. I do not pretend to be right on this issue, but one fact is clear: after realizing this, I downgraded back to 3.6.5 - no doubt about it. I have dozens and dozens of toolbar personalizations, to say the least. I do hope this can be fixed, at least indicating a "manual" way to recover your profile after the install of 4.0 I tried simply to replace the contents of the user/libreoffice/4/user with those of the user/libreoffice/3/user, but it did not work. Is there another more successful way? Thanks
Hi there. Andy - continuing to use 3.6.x is fine of course - we should have this fixed for 4.0.1 in a few weeks more - along with plenty of other issues. It'd be great to have more testing (and MAB prioritisation) further in advance of 4.1 I guess - though Pedro did a great job to file this in September and we sucked at prioritising / identifying it as an issue it seems. Florian - you're quite right - the apparently endless problems of migration are really irritating ... we need to come up with some creative regression tests for it I think to avoid issues in future.
I tested my theory and it works perfectly. Even extensions are migrated. At least under Windows :) If the user does a Custom install of 3.x to %ProgramFiles%\LibreOffice\ (no version in the name) then when updating to 4.0 just install to the same folder. Then before running for the first time just make a copy of the whole \3 folder (in Windows located at %AppData%\LibreOffice\) and rename it to 4. This is what Windows users expect to happen ;) Maybe TDF can humor Windows users (even if they are a minority of LO users) by making the installer work the way they expect it to work? I believe this would be a good starting point to attract more Windows users...
> Then before running for the first time just make a copy of the whole \3 > folder (in Windows located at %AppData%\LibreOffice\) and rename it to 4. > > This is what Windows users expect to happen ;) Heh ;-) the whole idea of the migration code is to end up with a clean, and well understood state that does not have tons of legacy twists, turns, variants and potential problems in it. Having said that - it's clear that we also intend to migrate far more than we do - work needed; help appreciated etc.
Hi Pedro, I am trying to grasp your workaround correctly, forgive for my inability to precisely understand each step from you previous post. you write: If the user does a Custom install of 3.x to %ProgramFiles%\LibreOffice\ (no version in the name) then when updating to 4.0 just install to the same folder. What does this mean? Of course I have my present LO3.6.5 install in a "\libreoffice 3.6" folder in "\programfiles". Should I uninstall this from "\libreoffice 3.6" and reinstall the same release in a "\libreoffice" only folder? And my settings will be fully migrated, right? After this step 1, step 2 is installing 4.003 in the same "\libreoffice" only folder, i.e. overwriting the 3.6.5 install of the step before, correct? then you write: Then before running for the first time just make a copy of the whole \3 folder (in Windows located at %AppData%\LibreOffice\) and rename it to 4. At this point, step 3 involves that before running the 4.003 upgrade, i move to the "appdata\libreoffice" folder and clone the "\3" into a "\4" one. After this I should be able to run the 4.003 release with all my beloved personal settings at their place, right? If you confirm (or adjust where I am wrong), tomorrow I try give it a try and let you know. Thanks for now!
Hence there is the risk that users lose parts of their user profile, IMHO users should be at least informed that (1) there may be problems with the migration of the user profile from Version 3.6.x to 4.0.0, (2) it is recommended to backup the user profile of the 3.6.x version, in order to be able to recover the user profile or parts of it in case of a data loss. To my opinion the release notes website page would be a reasonable place for this information. Additional info: At the German discuss mailing list a user reported that his AutoCorrect and AutoText data are lost in both (/3 and /4) profiles while installing 4.0.0.3. Hence he made a backup of his profile he could recover his data. In the moment I believe that this not a general problem. I asked the user to reproduce this behaviour.
It is mentioned at https://wiki.documentfoundation.org/ReleaseNotes/4.0#Most_Annoying_Bugs I have just modified many settings in "Tools/Options/LibreOffice Calc" with 3.6. It seems that everything is migrated to 4.0 => it looks promissing with the "Tools/Options" setting. I also tried to do some changes in toolbard and they were not migrated => we should fix this. I wonder if we could check all this somehow more systematically.
The toolbars setting is stored under 3/user/config/soffice.cfg/modules while most of the other setting is stored in 3/user/registrymodifications.xcu
Petr Mladek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8db4f720f536ddf137c2d4d76045ab33b37c4437 migrate menu and toolbars customization (fdo#57061) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1baf540f0d479127fd13a8026f7c44a2811e74b4&h=libreoffice-4-0 migrate menu and toolbars customization (fdo#57061) It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #32) > From a USER and PUBLIC perception it is a MAJOR update. So having a BAD .0 > release is simply BAD marketing. I strongly agree with Pedro. This should have been a blocker. The release criteria page on the TDF wiki (https://wiki.documentfoundation.org/Release_Criteria) specifically calls out data loss as a valid symptom of a blocker bug, and this bug meets the other conditions. It is these kinds of bugs that lead many IT managers in the US to steer away from FOSS and that freak out typical users who are using a previous version. I expect that many non-programmer users who update, and then discover that settings are lost will feel alienated, and will drop LO Writer for another word processing program. I am very concerned that bad migration stories will prove to be a marketing disaster, especially with TDF's major PR for 4.0. In comment 30: > I am sorry but this can't be taken as a blocker. Yes, it is annoying that some > setting is lost. Though, it does not affect the functionality of the software. > It is still well usable. This absolutely affects the functionality of the software. Users can no longer do what they were doing before without massive time commitment to reset everything manually. It is very important to remember the differing perspectives between developers and users. Otherwise eventually it will only be the developers using the software. more from comment 30: > Is it really a blocker when user lost the list of recently used documents or > few 3rd-party extensions that even might need an update to work with the new > release? I agree that the recently used documents list is not high priority: it is transient data that just adds a little efficiency to using the software. However, the extension list is definitely high priority for many users. I would bet you that even most users who heavily use extensions don't even know which ones they have installed. They will attempt to do things in LO 4.0 that worked in their 3.X installation, but won't work now. They may have no idea that this is because of an extension! They may spend significant trouble-shooting the problem to no avail, and just leave LO. Some users have spent many hours customizing their AutoText or AutoCorrect entries, keyboard shortcuts, toolbars and menus. Not migrating those should definitely have been a blocker in my opinion, or at least there should have been clear, easy-to-find information about the bug, with a big warning on the download page. > All linux users lost similar level of setting with the switch from LO-3.4 to > LO-3.5 and I am not aware of any strong complains. Again, a lack of understanding of the typical user. 99% (at least) of users will never post anything to Bugzilla or LO mailing lists or anywhere else. If they get majorly frustrated with the software, they will just go use a different word processor. > Please, read also https://wiki.documentfoundation.org/ReleasePlan#Summary. > The time based release means that .0 release is intended for enthusiasts. It > might include include even annoying bugs. This is also a misunderstanding of the typical user. How would the typical user even find this page? On www.libreoffice.org, no page has a link to the release plan summary. Only 2 pages have a link to the release plan. One is is the pre-releases page, where it is labeled "release schedule", a page unlikely to be read by a typical user. The other is the release policy page, where again the release plan is referred to "release schedule". Typical users are not likely to think there would be something important to them in a "release policy". Even if they do read that page, it says the reasons for 2 maintained branches are large deployments and Linux distribution, not bugs. It goes on to say "as a general rule, The Document Foundation advises all users to upgrade to the new version as soon as possible." And "It is not correct to assume that versions from previous branches are 'safer' or 'more stable'." This would seem to indicate that TDF wants single users to upgrade ASAP, with no mention of the migration or any other bugs. And even if by some miracle a user gets to the release plan page, s/he is not likely to think there would be something important to them in a "release plan". Now the LO home page redirects to a huge, splashy announcement of 4.0, which certainly seems aimed at the general user. No mention of annoying bugs, no mention of the release plan philosophy. The page that the download button takes you to also says nothing about annoying bugs or the release plan, nor even any indication that the user should consider downloading an earlier version. There is a link to what is labeled as the release notes page. (Which is not a real release notes page, since it doesn't even describe what is new in the release.) This "release notes" page says that 4.0.0: "contains many exciting new features, and is suitable for early adopters and private power users", and that 3.6.5: "contains many exciting new features, and is the recommended version for home and corporate users." The first 7 words are the same. Those two sentences make it sound like there may be extra fancy, specialized features in 4.0.0, not that it might be buggy. The very bottom sentence of the 4.0.0 release notes finally mentions bugs, and links to the real release notes page on the TDF wiki for "a few annoying bugs". I believe the typical user of a previous version would consider major settings loss far more than annoying. Finally, on that page, is a link to this bug. This bug is long and technical, with a vague title, and no succinct description of the problem. So .... A user gets excited by the flashy announcement on the home page, and attempts to download 4.0. On their second clicked-through page, s/he may see the line about some bugs. S/he might follow that link to the third clicked-through page, which mentions that some settings are not migrated. It isn't until s/he reaches the fourth clicked-through page where there is even a chance of the user understanding what settings are not migrated. I am not writing all this to attack Petr or any other developer. I am a strong FOSS supporter, and am thrilled to use LO. I am very, very grateful for all the time and energy you all donate to the project! I am just concerned that not keeping in mind the perspectives of typical users will eventually doom the project. It has happened before on other projects. I realize that much of this post touches on larger issues than just this bug. If there is another appropriate place to post this, let me know. I am not a programmer, but am happy to help out in other ways.
It is hard to say who is right. I have heard quite positive feed back about 4.0 so far. I am sure that some people will get annoyed and I am not happy about that but it was not easy to decide. BTW: I am going through the setting and working on patch to improve the migration. The situation in 4.0.0 was not that bad. Majority of the Tools/Options setting was migrated. The list of recent documents and toolbars personalization seem to be the biggest missing part.
Just did an 4.0.0.3 installation over an 3.6.4.3 one via msi deployment on a Windows 7 Prof. x64 workstation. The personal data is well migrated, but seems the user modified paths from Options - LibreOffice - Paths are not migrated. At least the modified template and autotext paths do not show up in the configuration dialog.
Another report about this happening. I updated from LO 3.5.? to 4.0.0.3 on a Windows 7 machine and lost all of my custom dictionaries, extensions (well, I only had one), key mappings and other preferences. The App Data/Roaming/Libre Office/3/ folder contains to files, MIGRATED (date implies it's from a previous update) and MIGRATED4, as well as the folder user. Is there any way I can manually get this data into LO4? And will a bugfix actually help in cases like mine where the damage already has been done?
Petr Mladek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=941fdb183415bcb917dd87446cef22db3756cd82 migrate even more user setting (fdo#57061) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Paul, I'm sorry you got bitten by this issue; however - we have a time based release schedule, and this was not a sufficiently critical issue to hold the release (nor was there a fix in sight for it as/when we went live). > It is these kinds of bugs that lead many IT managers in the US to steer > away from FOSS and that freak out typical users who are using a TDF repeatedly, and emphatically states that "IT managers" should be paying for a professionally supported product version. These versions tend not to be based from a .0 release, better they come with real L3 support that can fix bugs and issues, and without which any migration is likely to fail. So - if your claim is that vanilla LibreOffice at a point-zero release is not adequate for an IT manager - you are quite correct. We can of course improve the wording of our announcements always; in the Free Software world, it's well understood that a point-zero release is always less polished than a point-<N> one :-) we can articulate that better of course. However - driving too many people away may defeat the point: without testers the software will not improve. On that topic, it would be great to have more people running master builds and reporting problems against them to help find problems (such as this) much earlier. Anyhow - thanks for your input ! noted.
Petr Mladek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e2cae964edab85e43d7ce0141d46d962d0ccd4c migrate also custom accelerators setting (fdo#57061) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I went though the officecfg/registry/data/org/openoffice/Office files from LO-3.6 sources and enabled migration of few more items: + paths setting + recently opened files + recovery setting (enable/disable; time) + ODF import/export setting + font anti aliasing setting + windows and toolbars setting (visibility, position, docking) + custom accelerators It seems to work fine and looks safe. People have already complained about many of these items. I was not brave enough to enable few other items, for example:
Ah, I hate the TAB+ENTER combination in bugzilla because it submit the message when I do not wan't. Anyway, let's continue. I was not brave enough to enable some other items, for example: + Office/Canvas + Office/ProtocolHandler + Office/Stripting + Office/SFX + Office/UI/CalcCommands + Office/UI/WriterCommands + I was not sure what they mean and how to modify them + They looked a bit strange + I wonder if they can be modified by the UI at all + Office/FormWizard + Office/WebWizard + Office/Common/Help/Registration + Office/DataAccess/Bibliography + Office/DataAccess/DataSources + the Writer wizard and the other stuff was explicitly disabled in the past, I guess that there was a reason for this
The three last commits should solve most of the mentioned problems. If I did not miss anything, the only remaining problem are the extensions. AFAIK, Stephan mentioned somewhere that the user-specific extensions are migrated. So, the problem is only with system wide extensions but it can't be solved easily. Anyway, the same problem was with any update, for example between 3.4 and 3.5 or between 3.5 and 3.6 => this was always problem => it should not be part of this bug. => I would consider it as FIXED. Feel free to reopen it if I missed something.
If you have already migrated your configuration with LO-4.0.0.3 or earlier, you still have chance to migrate also the missing stuff. One possibility is to migrate it once again. The problem is that you lose the changes that you already did in LO-4.0. Anyway, the steps are: 1. stop LO 2. remove libreoffice/4 user configuration 3. remove libreoffice/3/MIGRATED4 file 4. start LO 4 again Another possibility is to copy only the missing parts: 1. copy libreoffice/3/config/soffice.cfg/modules/* into libreoffice/4/config/soffice.cfg/modules to migrate changes inside toolbars and menus (new items, visible items, different order) 2. copy the interesting parts from libreoffice/3/registrymodifications.xcu to libreoffice/4/registrymodifications.xcu The file seems to be well formatted and alphabetically sorted. The content is relatively easy to understand. You need to copy whole lines and better whole sections with similar prefix. For example, lines starting with <item oor:path="/org.openoffice.Office.UI.WriterGlobalWindowState/UIElements define positions of extra elements in Writer, especially toolbars. Or lines starting with <item oor:path="/org.openoffice.Office.Histories/Histories describe the recently opened files.
(In reply to comment #46) > Another report about this happening. I updated from LO 3.5.? to 4.0.0.3 on a > Windows 7 machine and lost all of my custom dictionaries, extensions (well, > I only had one), key mappings and other preferences. The App > Data/Roaming/Libre Office/3/ folder contains to files, MIGRATED (date > implies it's from a previous update) and MIGRATED4, as well as the folder > user. @kliems, which extensions was that, and was it installed per-user or shared?
*** Bug 60526 has been marked as a duplicate of this bug. ***
(In reply to comment #54) > > @kliems, which extensions was that, and was it installed per-user or shared? It was the Zotero plugin (http://www.zotero.org/support/word_processor_plugin_installation). I can't really remember in which way is was installed -- presumably I installed as suggested on the linked page. From a practical perspective I'm more concerned with my dictionaries and auto-complete entries, as reinstalling extensions is no big deal.
(In reply to comment #56) > (In reply to comment #54) > > @kliems, which extensions was that, and was it installed per-user or shared? > > It was the Zotero plugin > (http://www.zotero.org/support/word_processor_plugin_installation). I can't > really remember in which way is was installed -- presumably I installed as > suggested on the linked page. Ah, that Zotero extension ("tunneled in" via a Zotero-LibreOffice-Plugin-3.5.4.xpi Firefox extension) might indeed be special. Likely that it results in the LO extension being installed shared; and shared extensions are not migrated, see comment 52.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=728f07a13dd3a2c827a94a35897ad5809e394c3c&h=libreoffice-4-0 migrate even more user setting (fdo#57061) It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4f998eb74f797adeaedcd7963167b9458e8f77a&h=libreoffice-4-0 migrate also custom accelerators setting (fdo#57061) It will be available in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hence there was a complaint on the german user mailing list, I checked the migration of macros with version 4.0.0.3. According my test macros are not migrated. I used the same procedure like in comment 24. If necessary I can provide a step-by-step description. Petr: Is the migration of macros also solved with your patches? BTW: Thanks for your commitment.
I checked the migration of several items of the user profile again. Some parts are still not migrated. Hence reopened. Used version: Version 4.0.1.0+ (2013-02-19 08.45.16) (Build ID: 847371bdd92f90b74f33f226f9487d5dbff249b) Result of test: * Recent documents (OK) * LO Window size (NOT MIGRATED) * Some randomly tested options: - Tips (OK) - User data (OK) - „Enable macro recording“ and „Enable experimental features“ (NOT MIGRATED) - Paths > My documents (NOT MIGRATED) - Appearance > Document background (NOT MIGRATED) - Writer > General > Settings > Tab stops (OK) * AutoTexts (OK) * Display additional tool bar (OK) * Additional visible icon in tool bar (OK) * Remove (i.e. not visible) icon from tool bar (OK) * Change order in Menu (OK) * Additional item in Menu (OK) * Macros (NOT MIGRATED) (macro created with macro recorder, macro inserts just some words) * Customize keyboard (NOT MIGRATED) (I assigned „Style > Paragraph > Heading 6“ to CTRL+6)
Petr Mladek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=48bf145cf4f84703b9920e2cffafbba448ae7ae1 migrate even more configuration setting (fdo#57061) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
First, harald-koester@, thanks a lot for testing and great summary. I have pushed another fix into master and nominated it for 4.0.2 and 4.0.1.2 releases. It fixes migration of: * LO Window size * „Enable macro recording“ and „Enable experimental features“ and few more options * Paths > My documents * Macros (macro created with macro recorder, macro inserts just some words) The following two items worked for me with 4.0.1.1 build on Linux, so there was nothing to do: * Tools/Options/LibreOffice/Appearance/Document background * Customize keyboard (assigned „Style > Paragraph > Heading 6“ to CTRL+6 it Tools/Customization/Keyboard) harald-koester@:I am not sure why the two last things did not work for you. Could you please try it once again with the 4.0.1.1 build. BTW: harald-koester@ what system are you testing on, please? Linux or Windows or ...?
Hi Petr, (In reply to comment #63) > The following two items worked for me with 4.0.1.1 build on Linux, so there > was nothing to do: > * Tools/Options/LibreOffice/Appearance/Document background > * Customize keyboard (assigned „Style > Paragraph > Heading 6“ to CTRL+6 > it Tools/Customization/Keyboard) > > harald-koester@:I am not sure why the two last things did not work for you. > Could you please try it once again with the 4.0.1.1 build. OK, I'll try it again on Saturday or Sunday. > BTW: harald-koester@ what system are you testing on, please? Linux or > Windows or ...? My System: Win 7 Prof.
harald-koester@, I have two more ideas what might went wrong. 1. Note that the migration works only in two ways: + LibreOffice -> LibreOffice (between official builds) + LibreOffice -> LODev (from official 3.x build to daily 4.x build) , so you need to do the original changes using the official LibreOffice-3.x build. I guess that you know this but just for sure :-) 2. There is one known limitation. The Tools/Options/LibreOffice/Appearance setting is not correctly migrated from LibreOffice -> LODev build. There is used the "LibreOffice" vs. "LODev" identification => this can't be tested only with official RC builds. If you used LODev daily build of 4.X, it explains why the Appearance > Document background setting was not migrated in your case. 3. The shortcuts are localization-specific. You do not see your changes if you use different localization for 3.X and 4.X builds. I guess that you use your native language localization for 3.x and the English localization for the 4.X daily build => this might explain the non-migrated keyboard customization. Could you please confirm that you used a daily LODev build with another localization for testing?
Here are new test results: User profile created with version 3.6.5 release, UI: German Migration tested with version 4.0.1.1, UI: German Migrated items: * Recent documents (OK) * LO Window size (NOT MIGRATED) * Some randomly tested options: - LibreOffice > User data (OK) - LibreOffice > General > Tips (OK) - LibreOffice > Memory > Undo > Steps (OK) - LibreOffice > Advanced > „Enable macro recording“ and „Enable experimental features“ (NOT MIGRATED), different options cathegory in Version 3.6.x: LibreOffice > General - LibreOffice > Paths > My documents (NOT MIGRATED) - LibreOffice > Appearance > Document background (OK) - Load/Save > General > Save > Edit document properties... (OK) - Language Settings > Show UI elements for East Asien Writing (OK) - Writer > General > Settings > Tab stops (OK) - Writer > Table > Heading (OK) - Writer/Web > Grid > Resolution > vertical und horizontal (OK) * AutoTexts (OK) * Display additional tool bar (OK) * Additional visible icon in tool bar (OK) * Remove (i.e. not visible) icon from tool bar (OK) * Change order in Menu (NOT MIGRATED !!!) Was OK with Version 4.0.1.0+ (2013-02-19 08.45.16) !!! * Additional Item in Menu (OK) * Macros (NOT MIGRATED) (macro created with macro recorder, macro inserts just some words) * Customize keyboard (OK) Petr, your asumptions of comment 65 relating to the appearance and the short cut settings seemed to be correct, both items are migrated now.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b3f49f41be14c79b828963d339117a2475ef0006&h=libreoffice-4-0 migrate even more configuration setting (fdo#57061) It will be available in LibreOffice 4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Harald, thanks a lot for retesting. The following items should get fixed by the last commit: * LO Window size * Some randomly tested options: - LibreOffice > Advanced > „Enable macro recording“ and „Enable experimental features“ - LibreOffice > Paths > My documents * Macros (macro created with macro recorder, macro inserts just some words) I am waiting for one more approval, so I am pretty sure that it will be in 4.0.1.2 build. ------- The only remaining this is: * Change order in Menu (NOT MIGRATED !!!) Was OK with Version 4.0.1.0+ (2013-02-19 08.45.16) !!! I did the following test in Writer: * Add "Bibliography Database" into "File" menu, just after "Close" (OK) * Move "Safe" before "Close" in the "File" menu (NOT MIGRATED) * Move "Zoom" on top of the "View" menu (OK) So, the menu migration partly works. LO-4.0 has the new menu entry "File/Safe As Template". I guess that LO-4.0 somehow enforced the updated "Save *" section and blocked moving the "Save" menu entry. I think that it is a corner case and not-worth fixing. Harald, what changes you did in the menus, please? Do you see the problem with more menu entries?
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-0-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd8dd40d460f5513363bac7505d62f0d0383cca3&h=libreoffice-4-0-1 migrate even more configuration setting (fdo#57061) It will be available already in LibreOffice 4.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #68) > > The only remaining this is: > > * Change order in Menu (NOT MIGRATED !!!) > Was OK with Version 4.0.1.0+ (2013-02-19 08.45.16) !!! > > I did the following test in Writer: > * Add "Bibliography Database" into "File" menu, just after "Close" > (OK) > * Move "Safe" before "Close" in the "File" menu (NOT MIGRATED) > * Move "Zoom" on top of the "View" menu (OK) > > So, the menu migration partly works. LO-4.0 has the new menu entry > "File/Safe As Template". I guess that LO-4.0 somehow enforced the updated > "Save *" section and blocked moving the "Save" menu entry. I think that it > is a corner case and not-worth fixing. > > Harald, what changes you did in the menus, please? > Do you see the problem with more menu entries? I did this 2 tests: (1) In the Writer menu "File" I moved the item "New" below "Open...". This was not migrated. (2) In the same menu I added the Command "Application > Extended Tips" at the end of the menu. This works. (But I just observed another problem: I tested the migration with the German UI. In order to tell you the right English names for the different items I changed to the English UI. But the language of the new inserted menu entry still is in German !! Just for your information. I think this is not a migration problem.) Hence I only performed the mentioned two test cases, I can't estimate if there are more problems with the migration of the menus. From my point of view there are some more test cases necessary in order to get a good 'feeling': change menu items not only in Writer, delete items from the menu, rename menu items, add a new menu group, add submenus, .... I intend to do some more tests according the migration of the menu, but you know, it's not a 5-minute-task ....
I made some more tests according migration of menu changes. User profile created with version 3.6.5 release, UI: German Migration tested with version 4.0.1.1, UI: German Here are the results: (1) Change order: Writer menu: File: „New“ moved on position down (below „Open...“) (NOT MIGRATED) Worked with Version 4.0.1.0+ (2013-02-19 08.45.16) (2) Change order: Writer menu: Table > „Split cells...“: moved 3 postions lower (below „Split table...“) (NOT MIGRATED) (3) Add Item: Writer menu: „File“, „Extended tips“ added to last position (OK) (4) Delete item: Writer menu: Format > „Styles and Formatting“ deleted (NOT MIGRATED) (5) Rename item: Writer menu: View, name of „Ruler“ changed (NOT MIGRATED) (6) Change order in submenu: Writer menu: Format > Anchor > „To page“ moved to the end of submenu (NOT MIGRATED) (7) Add item in submenu: Writer menu: Item added to submenu „Insert“ > „Object“ (OK) (8) Delete item in submenu: Writer menu: Edit > Changes > item „Comment...“ deleted (NOT MIGRATED) (9) Rename item in submenu: Writer menu: Tools > Update > „Page Formatting“ renamed (OK) (10) Rename default menu group. Writer menu: Is not possible. I don‘t know if this is intended. (11) Rename subgroup: Writer Menu: Insert > „Fields“ renamed (OK) (12) Move group: Writer Menu: Move „Edit“ one position to the right (NOT MIGRATED) (13) Create new menu group in Writer menu: Add 3 random items to group and additional one item with a submenu with 2 random items. New group with all items is migrated, but the name of the group is not migrated. After migration the wrong menu group name is „CustomMenu1“. The names of all menu items are correct. (ONLY PARTLY MIGRATED) (14) Change order: Calc menu: View > „Navigator“ moved up 4 postions (below „Status Bar“) (NOT MIGRATED) (15) Add item: Calc Menu: one item inserted in group „Data“ (OK) (16) Delete item: Calc menu: Edit > item „Plug-in“ deleted (NOT MIGRATED) (17) Another observations with all the menu changes above: Writer menu: View: There are two items „Zoom“ with different functions in this menu group: The item, which is wrong here opens the dialog „Zoom & View Layout“ (ITEM WRONGLY ADDED) (18) And another observations also with the menu changes above: Writer menu: In group „File“ a submenu with 4 items has been wrongly inserted between „Digital Signatures..“ and „Preview in Web browser“. The name of this submenu is „TemplateMenu“. This name is not translated to German. The first item of the submenu has not got name, i.e. there is only an empty place. (SUBMENU WRONGLY ADDED)
Update: just installed 4.0.1.2 Many progresses in user data migration. However some settings are still not migrated: 1) Java version is not selected (was manually selected in 3.6.5.2) 2) Online update checking was manually unselected in 3.6.5.2 and is selected again in 4.0.1.2 Because pathnames where changed, all Shared extensions were lost and need to be reinstalled. More on this in the QA mailing list.
I too, tried 4.0.1.2: I uninstalled 3.6.5 from the "Libreoffice 3.6" folder; I the installed 4.0.1.2 in the default "libreoffice 4.0" folder. Unfortunately, no personal setting was migrated, starting from personalized toolbars, which are gone and replaced by the standard ones. Am I missing something? Shouldn't the 4.0.1 solve this? Maybe I have to install it in the same "libreoffice 3.6" folder of the previous version? Or I should not uninstall 3.6.5 before installing 4.0.1? Any hint is really welcome, thanks
(In reply to comment #73) > I too, tried 4.0.1.2: > I uninstalled 3.6.5 from the "Libreoffice 3.6" folder; > I the installed 4.0.1.2 in the default "libreoffice 4.0" folder. > > Unfortunately, no personal setting was migrated, starting from personalized > toolbars, which are gone and replaced by the standard ones. > > Am I missing something? Please, read the comment 53. You need to remove the "libreoffice/4" configuration and also the "libreoffice/3/MIGRATED4" file to trigger the migration.
I see. I have now solved my own case by applying Pedro's advice (basically, first moving the 3.6 install in a generic "libreoffice" folder, and then installing 4.0.1.2 on top of it, plus some other details). However, I thought that the 4.0.1 sub-release was aiming at giving user an effortless migration experience from 3.x.... if you still have to fiddle with hidden files and folders in "appdata/libreoffice", I would say the process is not ready for prime time yet.
(In reply to comment #75) > However, I thought that the 4.0.1 sub-release was aiming at giving user an > effortless migration experience from 3.x.... if you still have to fiddle > with hidden files and folders in "appdata/libreoffice", I would say the > process is not ready for prime time yet. That was not the only goal of 4.0.1 Fixes in the 4.0.x branch will continue until version 4.1.0 is released. So keep posting problems on this bug report. For further discussion go to http://nabble.documentfoundation.org/Install-path-for-LibreOffice-under-Windows-tp4041530.html
(In reply to comment #75) > However, I thought that the 4.0.1 sub-release was aiming at giving user an > effortless migration experience from 3.x.... if you still have to fiddle > with hidden files and folders in "appdata/libreoffice", I would say the > process is not ready for prime time yet. The fixes will help people who newer started 4.0.0 but they start testing the 4.0 release with 4.0.1 build. The fiddling with the hidden files and folders is needed only for people who already migrated with 4.0.0 release and they want to do it once again with the improved 4.0.1. By other words, we could not fix already migrated configuration automatically. It would remove changes that people made with 4.0.0.
I have finally got time to look at the migration problems again and I am able to fix only one thing easily. The rest is more complicated :-( 1. Java setting is not migrated (comment 72 by Pedro) + one reason is that we do not copy user/config/javasettings*.xml + but even if we copy the file, it does not help because there is modified the list of supported vendors in /opt/libreoffice4.0/ure/share/misc/javavendors.xml; This change would cause re-detection and reset to the default java even if we do not move the migration. We could do better but this is an old bug. It would happen even if we did 3.7 instead of 4.0. I would suggest to solve it separately. 2. Online update checking was manually unselected in 3.6.5.2 and is selected again in 4.0.1.2 (comment 72 by Pedro) + This can be fixed by enabling the migration for "/org.openoffice.Office.Jobs" in officecfg/registry/data/org/openoffice.
Grr, i have this "TAB" + "Enter" behavior in bugzilla. Let me continue: + I am going to put the fix for the online checking after some investigation 3. Many changes in menu entries are not migrated (comment 71 by Harald) + it seems that the menu entries are filtered by a pretty old code added by http://cgit.freedesktop.org/libreoffice/core/commit/?id=97e96b230c86d10cb31793d3737c7d1d97041dfb + IMHO, the problem is that the code does not know if the menu entries were added/removed/renamed by the user or by the new version. It has to guess and it seems to be using the following approach: a) it ignores renamed entries because they might be renamed by the new version; It helps to be compatible with help and tutorials; By other words, it always enforces the name from the new version; This explains the non-renamed menu items - problem 5, 13, 16 from comment 71. d) It ignore moved entries because the move could be caused by new version. It again helps to be compatible with help and tutorials. The only exception are menu entries added by the user, see below. By other words, it resets the order according to the new menu. It keeps the entries that are not longer in the new menu on the location where they were before. This explains the non-migrated moves - problems 1, 2, 6, 12, 14 b) It tries to do not lose any user added entry. It keep all entries from the old user menu that are not in the new menu. This explains the forgotten menu entry - problem 18 from comment 71. c) It tries to do not loose any new menu entry from the new application. It keep all entries from the new menu that are not in the old user menu. This explains the non-deleted entries - problems 4, 8, 16, 17 from comment 71. Note that the two zoom items are caused by non-deleted old "Zoom" entry. So, it is explained. The questions is what to do with it. I do not see any easy solution. The current logic sounds reasonable. If we want to solve it properly, we would need to store information about all menu changes between all old OOo and LO release and use it in the update logic. This would be a real hard hack and I am not sure if it is worth the effort. It would be actually needed even for update between minor versions that modify menu entries as well. If we want to better solve the menu migration, I would open separate enhancement bug for it.
Petr Mladek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7cb3fef6e7f25b7391963f316ffd72535c3f923f Migrate also Java and Online Update setting (fdo#57061) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #80) > Petr Mladek committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=7cb3fef6e7f25b7391963f316ffd72535c3f923f > > Migrate also Java and Online Update setting (fdo#57061) Well done Petr ;) Since these are all bug fixes (and not new features) can't they be cherry picked to the 4.0.x branch so that they can be tested and added to 4.0.2?
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f569b6b787586671626f03a61c20b39142a2304&h=libreoffice-4-0 Migrate also Java and Online Update setting (fdo#57061) It will be available in LibreOffice 4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
82 comments later can we close this as FIXED and give Petr a big thank you? ;)
I have opened separate bugs to track the two remaining problems: + bug 62241 for enhancing java migration + bug 62242 for enhancing custom menus and toolbars migration All other mentioned problems should be fixed in 4.0.2.1 build. Please, note that you need to manually trigger the migration if you want to try it again, see the comment #63 for more details. Let's close this long bug and keep fingers crossed :-)
Well done, Petr :) Just updated to 4.0.2.1 All settings that I modified were imported, even the Updates check. Kudos!
(In reply to comment #8) > Hence I expect a lot of user complaints, if this bug is not corrected. > Furthermore it will not really raise the image of LibreOffice especially at > the start of a new major release (Version 4.x.x). IMHO it's necessary to > correct this problem before the release of version 4.0.0. You bet. I'm very surprised that this happened at all. I had deliberately skipped 4.0, in anticipation that such gross errors would be eliminated in the next release (4.0.1.2), which I installed. Dead wrong. Fortunately, I know how to manually move the user files. Those who don't and have much customization done could be screaming mad. (On the safe side, I had even backed up the whole folder just before installing.) Good this this is fixed for the next release. Still, I think it's very important to trace how this could have happened, and implement some kind of protocol to prevent it.
> Good this this is fixed for the next release. Still, I think it's very > important to trace how this could have happened, and implement some kind of > protocol to prevent it. Kumara - we have such a protocol; it is called pre-release builds. I'm glad you agree that this is important, so you can get involved in testing those quite easily - please do so. Master builds -should- be usable for daily work, and in some cases have more bug fixes than the release builds. Failing that - you could contribute some unit tests for migration - currently there are zero of them; it would be fantastic to have some :-) Failing that, if you can't program, then getting involved with manual testing & bug triage is greatly appreciated. Thanks !
Michael, I'm aware of testing the pre-release builds. I don't recall having done it before, and am very grateful to people who have. I should consider doing it, but admit that I'm unable to at this time. At any rate, this isn't exactly the protocol I wasn't speaking about. Perhaps "protocol" is not the right word to use. I'm interested in solving a bigger "bug": the *reason* such a bug happened despite the existing testing protocol. (There are other surprising bugs on LO4.) Could it be that the alloted time frame for testing is not long enough? Could it be that the range of testers isn't wide enough? ("Range" as in the variety of people who uses LO in different ways.) We need to ask such questions. I apologise if I'm using a wrong platform for this. Let me know if there's a better place to discuss this. Come to think of it, this kind of work is more suitable for me than testing, as I'm unwilling to risk losing data.
This isn't the right place to discuss this, and if you're saying that the best you can do is suggest better ways for other people to volunteer their time, I'm afraid you can stand in a long line. There are hundreds of suggestions for us to implement changes but often times people say exactly what you said "I don't have the time to help". I am part of the QA team, if you'd like to get involved with testing, triaging and making better and more efficient check systems, please feel free to contribute through QA, if not, I'm sure you can understand that a group of overworked volunteers will hit snags occasionally, we do our best and are constantly putting in tens of hours a week for no pay to make our process better. If you have specific suggestions on how to make QA better (which is what you're saying), please send emails to QA mailing list. The more specific the better as general comments aren't very useful. Just to give you an idea of what we face, over 1,000 bugs/enhancements were reported in February alone, we have a very small team to manually sort through these, confirm issues, and then of course help developers priortize. With millions of users worldwide, the ratio of QA testers/triagers to users becomes mind numbing. As these comments have clearly gone off from the main topic of the bug, I ask that you end it here and move it to the QA mailing list where it is more appropriate.
forgot to say: @Pedro - thanks so much for so much work on this one. If you have just a little time a week to help out QA we would love to have you join our team :) Please feel free to email me directly, join our mailing list and of course chat with us on #libreoffice-qa :-D
I have faced this problem b4 during a migration of my G Suite account. All I needed was to read this G Suite data migration guide from https://spinbackup.com/blog/g-suite-data-migration-guide/, and It has helped me tremendously.