Bug 57466 - Change in UI user configuration will cause new UI items in next versions of LibreOffice to be invisible, when that previous userprofile is used
Summary: Change in UI user configuration will cause new UI items in next versions of L...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 101297 115598 132905 (view as bug list)
Depends on:
Blocks: User-Profile-Upgrade
  Show dependency treegraph
 
Reported: 2012-11-23 22:39 UTC by Cor Nouws
Modified: 2021-08-24 06:31 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2012-11-23 22:39:32 UTC
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.
Comment 1 Cor Nouws 2012-11-23 22:40:11 UTC
this is confirmed often by observations over a long time ;-)
Comment 2 Rainer Bielefeld Retired 2012-11-24 08:36:08 UTC
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?
Comment 3 Cor Nouws 2012-11-24 09:03:28 UTC
(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.
Comment 4 Cor Nouws 2012-11-24 09:04:34 UTC
By the way: I only mention the menu since I do not use toolbars.
But I would expect we see the same behavior there ;-)
Comment 5 Cor Nouws 2012-11-24 09:06:49 UTC
(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.
Comment 6 QA Administrators 2015-01-05 17:51:33 UTC Comment hidden (obsolete)
Comment 7 Cor Nouws 2015-01-28 19:05:48 UTC
need to check how this works now
Comment 8 Cor Nouws 2015-03-07 21:29:11 UTC
(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 :)
Comment 9 Cor Nouws 2015-07-07 22:04:40 UTC
(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 :)
Comment 10 Cor Nouws 2016-08-06 00:43:32 UTC
*** Bug 101297 has been marked as a duplicate of this bug. ***
Comment 11 Heiko Tietze 2016-08-06 07:56:15 UTC
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.
Comment 12 Cor Nouws 2016-08-06 08:05:42 UTC
yep ..
(Not sure why this needs ux-advice in CC, by the way)
Comment 13 Heiko Tietze 2016-08-06 08:08:32 UTC Comment hidden (no-value)
Comment 14 Cor Nouws 2016-08-06 08:45:18 UTC
(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  ;)
Comment 15 Yousuf Philips (jay) (retired) 2016-08-06 08:53:52 UTC
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."
Comment 16 Cor Nouws 2016-08-06 08:58:55 UTC
in short: it's extremely complicated
Comment 17 Heiko Tietze 2016-09-16 08:57:35 UTC
*** Bug 99716 has been marked as a duplicate of this bug. ***
Comment 18 Cor Nouws 2016-09-19 16:39:37 UTC
I think configuration stuff over more modules typically belongs to framework
Comment 19 Chandanathil P. Geevan 2018-02-07 17:05:21 UTC
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.
Comment 20 Heiko Tietze 2018-02-07 17:35:16 UTC
(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... ;-)
Comment 21 Maxim Monastirsky 2018-02-10 17:07:22 UTC
*** Bug 115598 has been marked as a duplicate of this bug. ***
Comment 22 lo-bugs 2018-02-10 18:04:18 UTC
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.
Comment 23 Alex Thurgood 2020-05-14 08:26:35 UTC
*** Bug 132905 has been marked as a duplicate of this bug. ***
Comment 24 Alex Thurgood 2020-05-14 08:29:04 UTC
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.