When you add or fill in custom properties in an ODT file, this change is not recognised, so closing the document does not lead to a Save prompt, and both the Save button and the Save menu item (in the File menu) remain greyed out. Steps to reproduce the bug: 1. Create a new text document in Writer, add some random text and save it. 2. Go to File > Properties > Custom Properties, and fill in a few properties. 3. Confirm the change by pressing the OK button in the Properties dialog. 4. Notice that the Save button on the toolbar and and Save item in the File menu are greyed out. Close the document: observe that Writer does not present a dialog that prompts you to save the changes. Note: I could not reproduce this issue in LibreOffice Calc (nor in OpenOffice.org Writer 3.2.0). Current workaround: use "Save as" after adding custom properties.
Confirmed with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 and LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-3.3.1.2 I'm using Windows 7 Sp1 x64. Both Windows and LibO are Italian version.
Also confirmed with LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-3.3.1.2 on Linux (Kubuntu 10.04).
I confirm this behavior on : LibreOffice 3.3.2 OOO330m19 (Build:202) tag libreoffice-3.3.2.2, Debian package 1:3.3.2-1 The issue occurs both when new fields are added in the customer properties, but also when existing custom or standard fields are modified (e.g Document Title). This is a very painful issue, because the user data can be silently lost. Let's take the following example: - document is edited, then saved - the user modifies or add document properties - the user presses CTRL-S, and does not see that nothing happened - the user closes the document, openoffice - the changes in the properties were lost It happened to me on three files yesterday ; I noticed the bug because I actually had to re-open the property editing dialog to do another modification. The effects can be very bad: take the example where the modification in the document properties consisted in removing a specific information in, e.g. the document title; if this change is lost, then the user gets a file that, even after saving as a PDF, will leak the information that the user wanted to remove. Given the data loss issue described above, I'm marking this bug as 'critical'. (I don't known the policy on whom is legitimate to position bug severity, but I think the use case above is clearly a user data loss)
*** Bug 35063 has been marked as a duplicate of this bug. ***
With LibreOffice 3.3.2 I can add file properties, but then not change them anymore later. Modified file properties don't get saved and LibreOffice also doesn't update associated fields in the current file when properties get changed. (For the later see "Bug 30857 - The File-Properties set could not reflect to corresponding document fields.") See this problem on Windows 7 (64 bit) and on Mac OS X 10.6.7. No such problem with OpenOffice.org 3.3.0.
[Reproducible] with "LibreOffice 3.3.2 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]". No problem with CALC, DRAW! 3.4Beta not tested yet. @Cédric: Your area?
[Reproducible] with LibreOffice 3.4.0beta5 – Windows Works with Calc: floppy icon (Save) turns blue as soon as the properties window is closed.
I have the same exactly the same problem when i tray save large document (about 130 pages), when I open document save is gray and always stand .lock file - LO 3.4 . In LO 3.3 that problem didn't exist -cy
*** Bug 38640 has been marked as a duplicate of this bug. ***
SfxObjectShell::SetModified is called when "ok" is called in calc, but not in writer.
triggered by 9a3f243c and 0b21b8b1 If SfxBaseModel::getDocumentProperties is called with no prior XDocumentProperties one is created and a listener is added to it which sets the doc as modified if the properties changed. But if SfxBaseModel::setDocumentProperties is called, then the new XDocumentProperties has no listener set on it, so changes to the properties don't set the document as modified.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=10c0e027b8940e6cead7282fb69796cb28d2aeb9 add a listener to the XDocumentProperties that get set. Fixes this. caolanm->noelp: be good to have a double-check of this for me. Maybe for 3-4 if necessary. (Might be the case that we should store what we set as a listener in order to remove it as a listener to avoid leaks/circular references. Never sure about that, current code doesn't, so no worse there.)
(In reply to comment #12) > http://cgit.freedesktop.org/libreoffice/core/commit/?id=10c0e027b8940e6cead7282fb69796cb28d2aeb9 > > add a listener to the XDocumentProperties that get set. Fixes this. > > caolanm->noelp: be good to have a double-check of this for me. Maybe for 3-4 if > necessary. > > (Might be the case that we should store what we set as a listener in order to > remove it as a listener to avoid leaks/circular references. Never sure about > that, current code doesn't, so no worse there.) looks ok to me ( like you say no worse than before ), I know no more about removal of the listener either :-/ have seen this before in many many places, presumably leaving it to the broadcaster's local list of listeners alone ensures there would be no leak ( or strange circular ref scenario like you mention ). I guess it is worth pushing this to 3.4 . Have to say though that I don't know why I set the compatible "com.sun.star.writer.DocumentProperties" for 'normal' writer documents ( although the extra properties are hidden from the ui, only available from the uno api etc. ) Hmmm I can't remember whether it was intentional or not
*** Bug 40970 has been marked as a duplicate of this bug. ***