Steps to reproduce: (1) Open new text document. (2) Set Option „Load/Save > General > Save > Edit document properties before saving” (3) Insert some text. (4) Save document: File > Save. The “Save as ...” dialogue is displayed. Type in file name, choose file type and choose folder, then ”Save“. The dialogue “Properties of Untitled1” is displayed. Expected: “Properties of [just chosen file name] should be displayed. (5) Click tab “General” Displayed file name: “Untitled”. Expected: File name typed in at step (4). Type: Text document. Expected: File type chosen in step (4). Location: A folder is not displayed. Expected: Folder chosen in step (4) This bug also appears if you like to save an existing document under a different name, type and/or folder with “Save as...”. In this case the previous name, folder and type are displayed. This bug also appears with Calc, hence I suppose all LibreOffice components (Draw, Impress,..) are effected. Comment: You can argue, that the displayed information of file name, file type and location are correct, hence the document has not been saved yet. But from my point of view it's quite irritating, when I have just determined name, type and folder and one second later these data are not displayed. Possibly for a better understanding a message could be displayed in the properties dialogue, e.g. “Document has not been saved yet. It will be saved with OK.” There is also another solution for this bug: Change the order of both dialogues, first display the “Properties...” dialogue and then the “Save as...” dialogue. To my opinion this solution is also more logical, hence the option says “...before...”. For this possibility I would also replace some words of the “Properties…” dialogue: (a) Content of field File Name: Not: “Untitled”, better “(untitled)” or “(File name not determined yet)”, with brackets in order to avoid a mix-up with a file name. (b) Not “Type”, better “File type”. (c) In field “Type” or "File type”: Not “Text document”, better “Undetermined text document format” (d) Not “Location”, better “Folder”. (e) In field “Location” or “Folder”: “(Folder not determined yet)” Hint: I already described this bug in Bug 53034 together with another problem which has been solved meanwhile.
I confirm, but I'll let someone else to confirm. I set as inherited from OO. (In reply to Harald Koester from comment #0) > Comment: You can argue, that the displayed information of file name, file > type and location are correct, hence the document has not been saved yet. Actually, the document is saved BEFORE document properties dialog appears. Also, if we save the document (new or save as), and cancel the (empty or existing) properties dialog, and then close and reopen the document, it will have the correct (new or saved as) properties. Solution should be either: - Rename "Edit document properties BEFORE saving" to "Edit document properties AFTER saving" and display saved properties in the properties dialog OR - Change the order of both dialogues, first display the “Properties...” dialogue and then the “Save as...” dialogue (as proposed by submitter).
Reproduced. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ Build ID: 9de1d53a2ce3ee7036b4688b373db7b2235af4d9 TinderBox: Win-x86@39, Branch:master, Time: 2015-05-14_00:07:12 Locale: fi-FI (fi_FI)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug still exists in version 5.2.1 with Win7.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Bug still exists with version 5.4.2 (64 Bit, Win 10).
Need UX eval to decide on opted solution.
The option "Tools > Options > Load/Save > Edit document properties before saving" shows the document properties dialog on saving with the issue that the entered filename is not taken into it. The proposed solution to show properties first and save subsequently makes sense from UX POV (Timur points out comment 1 that the file is saved after the first dialog, so the alternative solution is not ideal). This change is likely an easy hack.
I would like to work on this bug if it is open. Can I get an idea, where I can start? Thanks.
(In reply to Mihir from comment #9) > I would like to work on this bug if it is open. Can I get an idea, where I > can start? Searching for "Edit document properties before saving" [1] I get EditProperty, which in turn brings "EOption::DocInfSave" that would be the internal variable for this option. Maybe you can make your way through the code with this info. Otherwise dev wisdom is needed. [1] https://opengrok.libreoffice.org/search?project=core&q=%22Edit+document+properties+before+saving%22&defs=&refs=&path=&hist=&type= [2] https://opengrok.libreoffice.org/search?project=core&q=EditProperty&defs=&refs=&path=&hist=&type=
(In reply to Timur from comment #1) > Actually, the document is saved BEFORE document properties dialog appears. This is incorrect. And one can easily check that: while the properties dialog still open, use a file manager to check if the file has been updated (check file modification time); even better it's seen when a file is created/saved as: the new file is simply absent yet. > Solution should be either: > - Rename "Edit document properties BEFORE saving" to "Edit document > properties AFTER saving" and display saved properties in the properties > dialog OR So - this is a wrong option (wrt that "AFTER").
A code pointer: SfxStoringHelper::GUIStoreModel in sfx2/source/doc/guisaveas.cxx (see the "if ( aOptions.IsDocInfoSave() ..." condition). In my opinion, more easy and safe would be to keep the order, but just augment the aModelData.ShowDocumentInfoDialog() with required arguments to override some displayed properties (which otherwise are taken from current media, which is not the new file at the moment of the dialog execution). The other option (to show the dialog prior to file picker) possibly needs more work, e.g. careful cleanup after user has canceled the save operation in file picker (I am not sure if there is such code currently in case of failed save operation). Or may not, depending on if you consider setting the properties as part of save or not (a separate editing operation).
(In reply to Mike Kaganski from comment #11) > (In reply to Timur from comment #1) > > Actually, the document is saved BEFORE document properties dialog appears. > > This is incorrect. And one can easily check that: while the properties > dialog still open, use a file manager to check if the file has been updated > ... If you cancel the properties dialog the file shows up anyway. Of course it might be two independent procedures but OTOH the file saving could also not have been finalized. Anyway, the best solution is to show properties before save. The cancel thing is relevant for both solutions.
(In reply to Heiko Tietze from comment #13) Cancelling the dialog is a valid way to tell "this time no need to edit properties" - this does not (and should not) cancel the save.
(In reply to Mike Kaganski from comment #14) > Cancelling the dialog is a valid way to tell "this time no need to edit > properties" - this does not (and should not) cancel the save. True. Actually the whole option is nonsense - for what purpose a user wants to edit properties with every save? If empty, yes, but not always.
(In reply to Heiko Tietze from comment #15) > (In reply to Mike Kaganski from comment #14) > > Cancelling the dialog is a valid way to tell "this time no need to edit > > properties" - this does not (and should not) cancel the save. > > True. Actually the whole option is nonsense - for what purpose a user wants > to edit properties with every save? If empty, yes, but not always. The dialogue "Properties..." is only displayed if the document is saved the first time or it is saved with a different name. Hence it is not correct that the dialogue is displayed with every save.
Dear Harald Koester, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Harald Koester, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug