Steps 1. Open a new LO spreadsheet. Fill some data, select and make a chart. 2. While the chart is active, go to File->Close . "Your changes will be lost if you don't save them" -> Press "Save" 3. The save dialog saves as type "ODF chart" (and no alternative). Fill some filename and save. 4. The document gets closed. Go to Open->Recent: only the chart is available, the spreadsheet is lost! If the document had already been saved, it works. However, while the chart is activate, one cannot save (Ctrl-S fails silently, and so a user might believe that the document has been saved, while it hasn't)
Hi Hernan, Thanks for the issue. I can confirm the problem. Saving a chart from a not saved spreadsheet, should not set the files flag Modified to false. Best, Cor
*** Bug 85839 has been marked as a duplicate of this bug. ***
*** Bug 90179 has been marked as a duplicate of this bug. ***
** 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.0.5 or 5.1.2 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
The bug is still present in 5.0 branch (tested here on linux mint 17.3), but it depends on the way we create the chart (I work with X-Y chart). If the data cells are selected "before" I click the chart button (typical), I have the bug directly. However, if I manually select the X and Y cell ranges (in the chart assistant), the "save" (or save as) function in chart mode then saves the spreadsheet (correct). But if I return in chart mode to edit the chart, I still have the bug. Very nasty...
Bug still present, as originally described. Tested on Version: 5.1.2.2 Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f, win7-64
Bug verified in 5.2.2.2 64 bit on Windows 8.1. Seems quite high risk of data loss. Open LibreOffice, create a new Calc document. Enter data into the spreadsheet. Create a chart from some of the data (example using bar chart). Double click on chart to change some formats etc. Use File, Save while chart is still in edit mode, saves only the chart into .odc file. User probably not going to notice that it is saved as .odc file. Close spreadsheet document, no warnings are given. Reopen the document and the user finds only the chart. Only data that was in the chart data table can be recovered, but not easily.
Let's adjust severity to critical, because this issue can lead to data loss.
*** Bug 103853 has been marked as a duplicate of this bug. ***
I am teacher. Even if you say to students "pls before saving you have to click somewhere to table, you dont need to stay in chart", some of them forget to do it. And when they come next week, half of them forget again. You have to tell this them each time, each week. Its really unpleasant. All their work has just gone. There is always one or two of them.... Pls change this behaviour. File - Save should always save all the work, all the table with all lists.
With version 5.2.5.1 (Linux), bug as described in comment#7. Actually, the spreadsheet is correctly saved if I save before exiting the chart mode for the first time. However, if I quit this mode and then return to edit, then saving at this point leads to the bug (if no saving has been done before).
(In reply to bruno.binet from comment #11) > With version 5.2.5.1 (Linux), bug as described in comment#7. Actually, the > spreadsheet is correctly saved if I save before exiting the chart mode for > the first time. However, if I quit this mode and then return to edit, then > saving at this point leads to the bug (if no saving has been done before). Correction: bug at this point even if a saving has been done before.
Another way to show the bug: 1. Open an existing spreadsheet 2. Modify some data => Save icon shows that file needs to be saved 3. Open a chart or create one 4. While chart is open, File > Save => As described (and expected) only chart is saved 5. Exit chart Actual behavior: Save icon shows that file does NOT need to be saved Expected behavior: LibO should know that only chart has been saved but not the entire spreadsheet which has been modified in step 2. Save icon must indicate that file needs to be saved.
Confirmed. I add some more information about usability. Another problem having to see with this one and that occurred today to a user: 1. she created the chart within an existing ods 2. she then saved while the chart was selected. 3. As discussed, LibreOffice asks to save (as odc). 4. She sees the "odc" thing then changes it manually to "ods" so that the underlying calc spreadsheet be saved 5. She confirms the replacement message ("of course I want to update my ods!") 6. The save process completes and she closes the document. -> When opening it back, surprise! It's the odc (made-up to ods by herself unknowingly) which appears. The original ods is gone and unrecoverable: the .bak in the backup directory is also the made-up odc. Clearly, to me, to the data loss possibility, there's a usability problem here. Most people don't know anything about what an odc is. They think they did something wrong then want to correct manually, thus defeating the software original intend. I think some kind of *very* clear message should be displayed in this situation so that the user can realize what is at stake.
** 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 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 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: 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
Bug still present in latest version of LibreOffice. Same behaviour as in description (also comments #13 #14). Version: 6.0.5.2 (x64) Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU threads: 4; OS: Windows 6.1; UI render: default; Locale: es-AR (en_US); Calc: group
Bug still present, (Ver 6.0.1.1, Windows10 as this was latest at term start), still CRITICAL and still causing trouble to students in the middle of exams, when their files are lost, except for one chart. It seems to be very difficult to solve.
Fixed by removal of the chart export feature.