Change in menu (user configuration) will cause new menu items in next versions of LibreOffice to be invisible, when the userprofile is migrated from the previous version Test: - Start 3.6.x with clean userprofile. - Change menu of Calc (Tools > Customize) - Close - Copy <3.6_userprofile_path>\user to <4.0_userprofile_path>\user - Start 4.0.0alpha1 - Look at Calc, Format > Condintional Formatting > only two sub menu items are visible - Close LibreOffice - rename <4.0_userprofile_path>\user - Start 4.0.0alpha1 again - Look at Calc, Format > Condintional Formatting > now four sub menu items are visible Reason: imported from 3.6 is /home/cono/.config/libreoffice/440alpha1/user /config/soffice.cfg/modules/scalc/menubar/menubar.xml which determines what is shown as menu.
this is confirmed often by observations over a long time ;-)
I did not do any own test. This seems to be related to "Bug 43489 - [Task] Incorrect behavior using existing User Profile for upgrade"? I wonder why I can#t find a related AOOo issue. @Stephan You have much knowledge in this area, what do you think?
(In reply to comment #2) > This seems to be related to "Bug 43489 - [Task] Incorrect behavior using > existing User Profile for upgrade"? Yes, since 'incorrect behavior' can is a broad definition, it is. > I wonder why I can#t find a related AOOo issue. Probably we did discuss is in the past, but did not file an issue. I even think to remember that Stephan in that time replied with ideas for the need of a verion number in the xml files as one possibility to overcome this problem. Or one could compare the predefined menu-xml files with the user defined ones. But prolly one should need the previous versions predefined menu-xml too, to get a reliable outcome. Maybe it's easier to have some notification after the upgrade, e.g. in this case that a message explains that file abc.xml has been used from your previous installation, but that there might be some new menu items that therefore are not visible - and point the users to the feature info for the new release.
By the way: I only mention the menu since I do not use toolbars. But I would expect we see the same behavior there ;-)
(In reply to comment #3) > Maybe it's easier to have some notification after the upgrade, e.g. in this > case that a message explains that file abc.xml has been used from your > previous installation, but that there might be some new menu items that > therefore are not visible - and point the users to the feature info for the > new release. And the very least that nearly any one could do, is add info to the README and the new versions feature info to warn people for this.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team
need to check how this works now
(In reply to Cor Nouws from comment #7) > need to check how this works now But anyone can check. It's not OS related or so :)
(In reply to Cor Nouws from comment #8) > (In reply to Cor Nouws from comment #7) > > need to check how this works now > > But anyone can check. It's not OS related or so :) I can't check this with a normal migration. But, assuming that re-use of the user profile means reuse of the user configuration (<version>/user/config/soffice.cfg/modules/..) I simply tested this with 1 - the main menu in Writer for 4.4 versus master 2 - the tool bar Standard in Writer for 4.4 versus 5.0 Result situation 1. A change in any menu, will make all menu changes from next versions invisible. Result situation 2. A change in the toolbar will make all toolbar changes in the next version invisible. So AFAICS, nothing changed here. Let's set this to a nice enhancement :)
*** Bug 101297 has been marked as a duplicate of this bug. ***
The issue of new features that are not exposed to the user because of previous configurations is not limited to the menu. It also affects the sidebar, e.g. the new pages tabs introduced with 5.2. (Would be good to rename the issue accordingly.) An option would be to create a new user profile, but without any migration the user may lose a lot of individual settings.
yep .. (Not sure why this needs ux-advice in CC, by the way)
(In reply to Cor Nouws from comment #12) > (Not sure why this needs ux-advice in CC, by the way) It's an enhancement, we have made no proposal yet, and the issue affects the user experience. I would call for UX when only one of these is true.
(In reply to Heiko Tietze from comment #13) > It's an enhancement, we have made no proposal yet, and the issue affects the > user experience. I would call for UX when only one of these is true. OK, but I would guess that the need is : show new items and merge custom changes from previous versions (and show conflict data..) /me now hiding for @sbergman's comment ;)
I mentioned this issue when it came to the new toolbars introduced in 4.4 that may users werent seeing the new buttons because they had modified their toolbars and suggest to the ESC that in 5.0 we should move to a new user profile number, but they chose not to agree because of the problems that occurred when the user profile directory was changed when LO 4.0 was released. So now this issue will be affecting toolbars, menus and also sidebars. The sidebar issue was brought up in ESC this week and they concluded "creating new user profiles is not a great solution. => put it in a bug."
in short: it's extremely complicated
*** Bug 99716 has been marked as a duplicate of this bug. ***
I think configuration stuff over more modules typically belongs to framework
Why not consider this: keep two separate set of files as in a) standard dictionary + customised (added words), b) bundled templates + customised templates c) standard autocorrect list + user-defined list d) standard document format styles + user-defined .... That is more structured approach than merging. Merging could lead to problems. When an update/upgrade is performed, rename the existing files to filename_old and copy the updated files. Add option to use standard ones plus what was there in the previous version. This could be one way to keep both old and new.
(In reply to Chandanathil P. Geevan from comment #19) Good idea. Alternatively we could ask what to do (override, merge, ignore) for new features. Or we just override the system default and keep what the user creates in his space, like for other stuff. But the table styles are taken from the user space only. Anyway, developers are welcome... ;-)
*** Bug 115598 has been marked as a duplicate of this bug. ***
I can't talk about styles etc. but for GUI customization, the approach should be IMHO: 1. try to merge 2. if that fails: inform user I don't think you need to ask the user for confirmation. For starters, this complicates the update process: you need to have detailed information available in every language and the UI gets more complicated. Also, users with standard menus don't get asked either, so why ask this particular group? In most cases, merging should work fine - you simply traverse the list of root menus, menu items, sidebars.. etc. in the user's xml configuration file until you find your anchor point ("add forms menu before tools menu") and then add the new item. In some cases (menu items, toolbar buttons), this might fail if the user removed everything the update process specifies as an anchor - in that case, add the new item at the end of the target menu/toolbar - perhaps show a quick notification? This approach should only fail if the user manually edited xml files, e.g. he removed the entire "View" menu with a text editor (you can't do this using the GUI) and the update process wants to add a new item to this menu. In that case, a simple warning that LO tried to update some part of the GUI but the file path/to/foo.xml seems to be either broken or manually tempered with plus a link to the release notes should do the job.
*** Bug 132905 has been marked as a duplicate of this bug. ***
So here we are in 2020, and this is still an issue. See the duplicate bug 132905 that I just closed. The new table styles are only available after creation of a new profile. This should not be necessary.
*** Bug 138578 has been marked as a duplicate of this bug. ***