If you save a text document, the value of the option "LibreOffice Writer, General, Update link when loading" is saved together with the document. So this value becomes a property of the document!! If you open the document again the value of the option "LibreOffice Writer, General, Update link when loading" is overwritten by the property of the document.
This behavior is quite irritating because I expect that a general option is not influenced by opening a document. Furthermore especially when several documents are opened you don't really know which value of the option is active. Also it is not obvious if a general value for this option still exists or not.
Proposal: In order to avoid the mentioned problems the "property" could be displayed and changed in the file property dialog. Then the option "LibreOffice Writer, General, Update link when loading" could be used to set the initial state of this property when creating a new file.
Platform (if different from the browser):
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:188.8.131.52) Gecko/20111103 Firefox/3.6.24
reproduced on LibO 3.5.0 beta 1 on Fedora 64 bit
this option saved in file settings.xml inside of odt file and consist of this:
<config:config-item config:name="LinkUpdateMode" config:type="short">2</config:config-item>
It is good idea to move options that saved inside of document to File->Options
But it is much work. My be at first time place text "saved inside of document" to those option that saved inside of document.
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit
This bug is no more with LO 4.1.1 on Windows 7 SP1: the option chosen is saved together with the document, but it doesn't overwrite the "universal" value chosen in the general options when you re-open the doc.
I checked the problem again with with Versions 3.5.3 and 4.1.1. The behaviour is equal. For me the problem still exists in both versions. Hence I reopened the bug.
Perhaps my first description was not clear enough, I was not very experienced in writing bug reports at that time. So in order to reproduce the problem I wrote a new and hopefully better step by step description:
(1) Start LO and open a new text document.
(2) Set option “LibreOffice Writer > General > Update > Update links when loading” to “Never”.
(3) Insert some text.
(4) Save and close document.
(5) Open another new document.
(6) Open option dialogue, option of step (2) is set to “Never”. Change option to “On request”.
(7) Close document. You do not need to save it.
(8) Open first document again.
(9) Open option dialogue, option is set “Never”. This is already a little irritating, hence the option has been set to “On request” in step 6. Go on with step (10a) or (10b)
(10a) Assume that you like to open another new document with “Never” at this point: A change of the option seems to be not necessary. Hence close options dialogue with “OK” or “Cancel” and open new document.
(11a) Open options dialogue again. Option is set to “On request”. Expected: Option is set to “Never”.
In this case the problem is step (9). The displayed option is a property of the document and not a general option. But the general option of step (6) is still active and this is not obvious to the user!
(10b) Assume that you like to open another new document with “Always” at this point: Change option to “Always”. Then “OK” and open new document.
(11b) Open options dialogue again. Option is set to “Always”. Then click “Cancel”. This is OK but ...
(12b) … change to first document again and open options dialogue. Option is set to “Always”. Expected: “Never”.
In this case the problem is step (10b). LO can't know at this point, if a user likes to change the option for a new document or to change the option of the first document. LO changes both.
There are some more options that behave in the same manner. Hence the option “Update links when loading” is just an example and therefore I changed the subject of this bug to “Intransparent Use of Options”.
I checked only Writer options. I assume that there are options in other components (Calc, Draw,..) that behave equal.
This problem seemed to be not really a severe problem. Otherwise there would be more complaints. This may be due to the fact that options are changed not very often. And if a user does this she/he will manage it somehow (e.g. change options several times) in order to get the wanted result.
But sometimes there may be a bad feeling left at the users, because the use of this kind of options is not very transparent and I think that in most times they do not really understand what happens. So I think it is worth to think about a better solution.
Oohh..., I just stumbled across the option “Load/Save > General > Load > Load user-specific settings with the document”. In the test steps above this option has been checked. If it is unchecked, the behaviour is different. Now even for me, who did several tests, it becomes more and more confusing. It seems that this option has an influence on other options. I think, hardly to understand for users. Also the Help of this option does not really help. It is not clear which options and perhaps also which file properties are effected by this option. Another reason to think about a better solution.
The primary goal for a change should be to make it easier for a user to understand the functionality. In my first report I proposed to move the current state of an option to the document properties dialogue and the corresponding option in the options dialogue should only be the initial state of a document property. After some thinking I would even go a step ahead: I would also move the initial state from the options dialogue to the document properties dialogue. In this case both the property (or option) of the current document and the initial value for new documents of this property (or option) should be displayed side by side. Then a user would see and recognize at first view the function of each property (or option).
We need fresh confirmation of this issue from QA - moving to UNCONFIRMED.
Reproduced and agree that it wouldn't hurt to somehow guide the user better.
Win 7 64-bit Version: 184.108.40.206.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
*** Bug 41918 has been marked as a duplicate of this bug. ***
With version 6.0.2. the problem with intransparent options, which are saved together with the document, still exists.