Bug Hunting Session
Bug 94857 - default template location overwritten by installation
Summary: default template location overwritten by installation
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Desktop-Integration
  Show dependency treegraph
 
Reported: 2015-10-07 12:26 UTC by Orwel
Modified: 2019-09-02 16:59 UTC (History)
4 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 Orwel 2015-10-07 12:26:18 UTC
Every update of LO changes the registry entry of Windows:
HKEY_CLASSES_ROOT/.odt/LibreOffice.WriterDocument.1/ShellNew - FileName

If you create your own template which should be used by default in Windows Explorer by right-click menu "New"-Text document (.odt), this template is stored in the mentioned registry entry HKEY_CLASSES_ROOT/.odt/LibreOffice.WriterDocument.1/ShellNew in the value name "FileName".

After every update of LO this value is set(rewritten) to LO-default: "C:\Program Files\LibreOffice 5\share\template\shellnew\soffice.odt" which means you have to edit the registry after every update of LO to change this value to your own template.

LO installation should not affect this registry entry. This behaviour is present since I can remember therefor I do not post the earliest version of LO affected.

Last tested on update to 5.0.2
Comment 1 FutureProject 2016-01-17 16:29:43 UTC
Hello, and thank you for bringing this issue to our attention.

I'm relatively sure this is working as intended. The installer sets everything up and overwrites old entries to make sure everything is up to date and no fragments of older versions remain, which could lead to issues along the road. As you can see, it points to a folder named "Libre Office 5", which is in conflict with older versions.

If you like you can open a new report and make enhancement suggestions how this behaviour should be addressed - perhaps the ability to set the template via options or any other ideas you might have.

Setting status to RESOLVED NOTABUG.
Comment 2 FutureProject 2016-01-17 21:36:08 UTC
I'm sorry about the confusion, but I have looked into the issue some more and have a question.

Did you change the registry entries manually to point to the other template? Because I found two different ways templates work.

A. The windows registry holds the path to a blank template that is used when new documents are created via "Right-click -> New -> OpenDocument Text". This is what is reset on every update. This works like every other file type as in that it creates a blank file.

B. LibreOffice has a setting for a default template that gets used when a new document is opened inside the application, but it does not seem to change the windows registry key from A. < see: https://help.libreoffice.org/Writer/Changing_the_Default_Template >

If using the default template setting is a viable option for you we can leave it at that. If not we might need some more opinions. Please let us know how you would like to proceed.

I'm changing the status to NEEDINFO. Please set it to UNCONFIRMED when you have commented.

--
Windows 10 Pro, Version 1511 (OS Build 10586.36)
Version: 5.0.4.2 Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: de-DE (de_DE)
Comment 3 Orwel 2016-01-18 08:22:16 UTC
Hi,
thank you for dealing with this issue.

Indeed, the way I use to create a new odt and i had described is the A. True is, i NEVER create a blank document from a template inside from LO (File-New-Text document). The reason for it is I use LO also for business documents and there are 2 ways i work with new documents: either i have to look for a matching folder where i want to place a new file (which is easier in Windows/searching file program) or i have to create a new subdirectory somewhere in the folder tree, which is also easier to do in Win. And when I am pointed in this folder, it is much more quicker and easier to create a new odt through the right click menu in Win as Open LO, create a empty odt and save it in the way you have to find the matching folder again.

Sure i can understand if this is not a bug although i thought it is one because i am not sure if this behaviour should be usual for an "update". In some way I can understand a full blank installation (and rewrite of registry paths) in the case of an "upgrade", but i think, when you use your own template each update (e.g. from XX.0.1 to XX.0.2) should not affect the path in the registry. 

Let me explain, for common users who are not able to find the way how to change Windows registry or are afraid to do it, the way (A) they create new documents (right click) has to be very muddy after the update. Or better to say - it is useless/impossible, because you can not do it without changing the registry. I think setting an own template as "default" should cause each technique (A or B) do the same. If B is not affected by an update, I think A should be neither.

I am not sure if it is possible to set in the registry 2 values for the purpose as described by  FutureProject 2016-01-17 - e. g. A) own template, B) default template for the case A is not working - this could be one possible solution.

Other possible suggestion is to add some entry in the Custom install process to keep the old paths. I really believe that there are also other users who prefer to create a new odt directly from Windows Explorer. But this way is not possible for less skilful users who use their own templates. I believe the way you have to go inside Windows registry to fix the path after every small update is not very user-friendly. 

But I understand if this is not a major opinion.

One more time thank you for deal with this.
Comment 4 tommy27 2016-11-26 05:46:12 UTC
@Orwel
has anything changed using latest LibO 5.2.3.3 release?
Comment 5 Orwel 2016-11-28 10:40:10 UTC
@tommy27 
Hi, no change in LO 5.2.2.3, i have just tested it. The affected registry key becomes still changed by update of LO. 
Steps for reproducing:
1. LO uninstalled  (Control panel/Programs)
2. Installed LO LibreOffice_5.1.5.2_Win_x64
3. Changed the registry key  HKEY_CLASSES_ROOT/.odt/LibreOffice.WriterDocument.1/ShellNew to the own template location on disk E: + changed/imported this template in LO-writer (File/Templates/Manage + setting the correct path (in Options/Paths) for the template on E:, deleting the default templates location on c:/...
4. Installed (updated) LibreOffice_5.2.3.3_Win_x64 (from a downloaded installation file).
Result:
After installing of 5.2.2.3 the registry key changed to the default value - path on c:
Comment 6 Pierre C 2017-08-24 15:01:22 UTC
One solution could be changing the ACL registry Key by removing the writing right to Administrators and System.

When reinstalling LO, an error message occurs telling us that the registry key could not be written. Just click Ignore. And all is seems right.

Pierre
Comment 7 Orwel 2017-08-25 07:30:48 UTC
My opinion is the solution should be more user friendly. I do not think changing the ACL registry with an error message by each update is the right way.

If it is not possible to keep the right way of the default template for security or other reasons (I really do not understand why is this necessary indeed) at least some check mark for example in the Custom installation settings should be added ("Keep actual template" or something similar).

This behaviour is really annoying...
Comment 8 Pierre C 2017-08-25 08:34:00 UTC
(In reply to Orwel from comment #7)
> My opinion is the solution should be more user friendly. I do not think
> changing the ACL registry with an error message by each update is the right
> way.
> 
> If it is not possible to keep the right way of the default template for
> security or other reasons (I really do not understand why is this necessary
> indeed) at least some check mark for example in the Custom installation
> settings should be added ("Keep actual template" or something similar).
> 
> This behaviour is really annoying...

I Absolutely agrees with that. I was just giving a (poor) workaround

From my little knowledge of registry.
The hkey_local_machine is a machine configuration location, and it can't be changed by a user.

So, a solution could be :
- The LO installation process changes the ACL of theses particulars keys, and gives user a write access
- When a user changes LO option to change the default template, this is also changed in the registry.
- At each new first start after installation, LO keeps consistence between registry and LO default template.

This could be a little problem. On a PC under Windows, each user can have a different default template setting. But as this is stored in the local_machine registry, each user has the same config by right-click --> new.

So definitively, this should be done during the installation process. In the advanced installation process, on step could be to give the path to the default template used.

Sorry you had my thoughts while I was writing
Comment 9 ydutrieux 2017-08-26 09:50:59 UTC Comment hidden (obsolete)
Comment 10 ydutrieux 2017-08-26 09:55:35 UTC
Hi all,

problem reproduced.

(little change in step in case of... ;) )

I agree with Orwel, If I remember correctly, in old version it was not a problem.
For me, Libo should react like this (like before) in this sequence :
1)See in the user folder : %appdata%/libreoffice/4/user/template/shellnew if there is a template soffice.xxx  if it's the case, use it
2)See in the global folder: ProgramData/Microsoft/windows/templates (/shellnew ?) if a template soffice.xxx exist, if yes use it
3) use the registry key Filename under HKCR/.odt/ (in case user has change to change the directory)
4) Nothing exist in previous folder located in step 1) and 2) and 3), use the default template of Libo (in the installation folder) and don't look or modify registry for this.


Yves.
Comment 11 Buovjaga 2017-09-08 15:18:12 UTC
NEW per comment 10
Comment 12 QA Administrators 2018-09-09 02:39:31 UTC Comment hidden (obsolete)
Comment 13 Orwel 2018-09-10 07:36:03 UTC
Hi,
this very annoying bug (I do an update of LO very rarely because of it) is still present in 6.0.6.2, tested on Win10, 64bit version of LO.
Thank you.
Comment 14 Orwel 2019-09-02 16:59:00 UTC
Still present in 6.2.6.2