Issue 101513 - Migration of User Settings neccessary
Summary: Migration of User Settings neccessary
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOO310m11
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: mikhail.voytenko
QA Contact: issues@framework
URL: http://wiki.services.openoffice.org/w...
Keywords: oooqa, usability
Depends on:
Blocks:
 
Reported: 2009-05-03 19:50 UTC by Mechtilde
Modified: 2017-05-20 10:20 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Mechtilde 2009-05-03 19:50:31 UTC
If the user use an extension which also create a separate menu entry he/she
didn't get the changes initialized by a new OpenOffice.org version.

The concret problem disappeared with the change of the menu point "Navigator".

The old entry is "Edit -> Navigator", the new one is "View -> Navigator". 

But if you use additional menu entries then you can't see this changes.

The consequenze is, that the help entries are wrong for you since this time the
help is updated to the new menu entries.

Also it is not possible to test under real circumstances.
Comment 1 Mechtilde 2009-05-06 20:55:26 UTC
I found the next problem :(

I read http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1 and
wonder why i didn't found the new menue entries in Base.

How can we publish which file in the user configuration should be created new to
get the new menu entries?
Comment 2 jolatt 2009-06-11 14:23:13 UTC
This is a basic problem if a user change a menu and/or a toolbar. In this case
there settings are saved in the user directory.
After a update of OOo changes in menu or toolbar has no effect because of the
settings stored in the user directory.

Workaround: Delete in the user directory (may be deleting the directory 'config'
is enough) and start OOo. Then you must customize your menu/toolbar again.
Comment 3 Mechtilde 2009-06-11 14:50:48 UTC
this is not a workaround in a productive environment

then you need exact informations which file(s) contains these informations

Otherwise you lost *all* settings in your productive environment like personal
dictionary, installed extensions, autotext, and many more things.

There is also a thread at users@de.openoffice.org in German 
Comment 4 Mechtilde 2009-06-11 14:54:46 UTC
I add fs to CC

because there are some menu changes since 3.0 which are not vivible by some users
Comment 5 Olaf Felka 2009-06-15 14:47:41 UTC
of: I'll have have look and ask cd for a comment/solution.
Comment 6 carsten.driesner 2009-06-15 15:03:01 UTC
cd: Add myself on CC.
Comment 7 carsten.driesner 2009-06-15 15:05:27 UTC
cd: I see the problem but I don't have a solution I fear there is no good
solution at all. The root cause is that the customized menu/toolbar is
completely copied from the user settings to the user data of the new version.
This results that entries which were added by a new version are not visible. So
only copying cannot be the "real" solution at all. Something like merging must
be done but. Unfortunately this can be a very complicated task and in the end
could also lead to bad results. Think of sub menus which were moved from one
place to another one. What to do with changes there? Create this sub menu again
in the new version? May be someone create a new menu and removed a old one. Then
you are definitely lost. Although I have thought about a good solution for
several months now I still have now good solution. The best algorithm I
currently see is add all user changes into the new version. If a sub menu is
missing it will be recreated. Dependent on the sum of changes between two
versions this could result in a good or bad user experience. The only good thing
is that the user won't lose his/her changes and could access all new functions.
It should be clear that there is no easy solution at all. A short-term
workaround could be to add version numbers to user interface configuration files
and don't copy user data for all elements that have changed between two version.
This would be an "optimized" version of the proposed workaround to completely
delete the user interface data.
Comment 8 Mechtilde 2009-06-15 15:51:29 UTC
@ cd

I have the following idea.

Is it possible to add to the user configuration file only the new menu entries.
Therefore you need a diff between both files.

In the case the user delete an entry this one should only be set to hidden. So
you only add really new entries (similar to "Migrate Code..." in Base)

If there is to change an entry (like Autotext). you have to look if it is on the
old Place and if it is set True or False. you have to moe it to the new place
with the same flag.
Comment 9 Frank Schönheit 2009-06-15 19:33:08 UTC
fs->cd: versioning information sounds like a good thing ...
Other that that, I think that simply resetting the menu/toolbar configuration is
better than not giving the user the new menu/toolbar items at all. Imagine the
Project Renaissance, and what it might do to our user interface: Do we really
want every user who just modified a *single* item in her menu/toolbar to not
benefit from all those hundredths of changes?

fs->mechtilde: I suppose that the approach you suggest would be possible in
general, but arbitrarily difficult to implement ...
Comment 10 Mechtilde 2009-06-15 19:51:59 UTC
in addition to my post before

the package management of Debian help the users to hold their own configuration,
take the new one or can look at the difference between the two difference
versions of the configuration file.

"Users" here means the one you has the rights therefore.

So while the user install such a program (s)he can decide what can happen.

In spezial I use it for the my.cnf the configuration file for the mysql server e.g.
Comment 11 Mechtilde 2009-06-20 19:54:54 UTC
cd: Add myself on CC.
he wrote himself in desc 7 so I do it

I'm interesting to discuss it to a possible solution. 

I think a solution here is very important.
Comment 12 Olaf Felka 2009-06-22 14:46:54 UTC
@ cd: We should find out what might be the best solution. As suggested, this is
to risky for 3.1.1.
Comment 13 cno 2009-06-22 14:59:56 UTC
Not a new problem.
The summary of this issue is not clear.
IMO the situation is:
 - when a user changes a menu /toolbar, this change is migrated to a
 new installed version;
   - however, possible changes in the menu/toolbar from that new version
   are not visible (reasen explained by others)
 - when a menu / toolbar is changed by an extension, this change also is
 migrated to new installed version
  - plus: possible changes in the menu/toolbar from that new version
  are normaly visible 

So if I understand the problem correct, the summary should be something as
"Customization of menu / toolbar prevents visibility of possible change on this
menu/toolbar in new installed version".
Comment 14 cno 2009-06-27 17:20:26 UTC
@mechtilde: is the summary as I suggested
  http://qa.openoffice.org/issues/show_bug.cgi?id=101513#desc14
a correct description of your problem?
Comment 15 Mechtilde 2009-06-27 17:33:54 UTC
Cor wrote:
- when a menu / toolbar is changed by an extension, this change also is
 migrated to new installed version
  - plus: possible changes in the menu/toolbar from that new version
  are normaly visible 

After installing extensions with menu entries, we havew the problem that the new
entries by the new version are *in*visible

Yes i think your suggstion is right.

Also if this isn't a new propblem, now it affects many many users because more
and more users are using one or more extensions. Then they don't get the new
functions of the newer version.
Comment 16 cno 2009-06-27 17:58:40 UTC
@mechtilde:  when your problem is
  after installing extensions with menu entries, that are defined in 
  the Addons.xcu from the extensions package (oxt), that is installed in the 
  user configuration path, the new menu entries (if any) by a new version of
  OpenOffice.org are *in*visible ..
then this is *not* the situation I described!
If so, I can check with installing m51 over m50.
Comment 17 cno 2009-06-27 18:16:49 UTC
cornouws wrote "If so, I can check with installing m51 over m50"
Of course I can't. I'll have to check with verions that I know give new menu
entries. 
Comment 18 Mechtilde 2009-06-29 13:28:28 UTC
a workaround can possibly be done with the informations under 
http://wiki.services.openoffice.org/wiki/Framework/Article/Addon_Menu_Toolbar_Merging

Comment 19 Frank Schönheit 2009-06-29 13:38:18 UTC
> After installing extensions with menu entries, we havew the problem that the
> new entries by the new version are *in*visible

Mechtilde, can you give examples for such extensions? Actually, menu entries
added by extensions should *not* make the new entries added by the new OOo
version disappear.
Comment 20 carsten.driesner 2009-09-15 08:34:26 UTC
cd: There is no specification for this issue. Therefore I have to shift this to
the next release.
Comment 21 carsten.driesner 2009-11-30 12:18:11 UTC
cd: Fixed by Wu Yan from CS2C.

cd->wuyan: Thanks for your work, Yan.
Comment 22 carsten.driesner 2009-11-30 12:20:59 UTC
cd: Added link to the specification.
Comment 23 carsten.driesner 2009-12-07 09:25:55 UTC
cd->of: Please verify.
Comment 24 carsten.driesner 2010-05-31 16:07:22 UTC
cd.>mav: Please verify.
Comment 25 mikhail.voytenko 2010-06-01 13:25:12 UTC
Verified in uimigration01 cws, the test configuration was merged successfully.