Say that we create a chart with a defined data source. Then we add rows to the data source. LibreOffice should detect this and whether ask us if we want to add the rows to the chart or do it automatically.
Thanks for bugreport in 3.5.2 with adding rows this works with columns not works, but it makes not much sense Please, tell if existing functionality not enough
I can't seem to make it work here. Here's what I do: - Enter theses data: 1, 2, 3 in the first column (cells A1-A3). 10, 20, 30 in the second column (cells B1-B3). - Create a chart with these data. - Click on cell A4. - Enter these data: 4 in cell A4 40 in cell B4 Results: The chart data source doesn't get updated to include row 4. Note that it should also extend the data source if I were to either: - drag/paste the data from row 3 to row 4 instead of inserting a line. - insert a row after clicking on cell A4.
Thanks for additional information. So we have several bug. Sorry for may previous comment. I confused rows and columns. Steps to reproduce: 0. Start Calc and enter these information: > 1, 2, 3 in the first column (cells A1-A3). > 10, 20, 30 in the second column (cells B1-B3). > - Create a chart with these data. 1. enter 4 and 40 in row 4 Expected: row 4 included into chart Actually: nothing happens IMHO it is functionality request for adding such functionality. Will be useful for creating chart when all data on sheet intended for diagram. Will create problem when when on sheet is another information. Therefore should be option for disable/enable this functionality. 2. place cursor in cell B2 , right mouse click, "Insert" from context menu, "Entire row" Expected: new row included into chart Actually: not included. The same situation by inserting rows by another means. It is another bug or functionality request. 3. Select column A or content of it 4. place cursor in B1 and use Paste Special, select option "Shift right" Expected: new column included into chart Actually: not included. It is a bug. When we insert column by other means, new column included.
** 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 (4.4.0.3 or later): 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-02-19
No change with version 4.4.0.3 on Windows 7 x64.
** 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.0) 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-02-21
Just tested this in 5.0.5.2 (Build ID: 1:5.0.5~rc2-0ubuntu1~trusty1) Bug is still present, but behaviour differs from comment 3. Inserting a row does add the data to the chart's data range. However, here are the issues that remain: 1. Adding data below the range does not add it to the chart automatically 2. Inserting a column does not add the data to the data range IMHO, I do not think the first one is a bug. The second one definitely is as the behaviours differ between columns and rows, and most users would expect inserted data to be added to the range.
** 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.2.5 or 5.3.0 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-20170306
Testing with KXStudio 14.04, LO details as follow: Version: 5.2.5.1 Build ID: 1:5.2.5~rc1-0ubuntu1~trusty0 CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: group Here is what I see: Data *will* be added if the data series range is extended by adding cells inside it: - If data series are in columns, adding a row inside the range will include the new data. - If data series are in rows, adding a column inside the range will include the new data. New data will *not* be added if a row or column is added *outside* the ranges of the data series, i.e. if a column is added between two columns of data series, or before or after them; or if a row is added between two row of data series, or above or under them. Similarly, if we add data under or above the ranges, it will not be automatically extended. I now think that the current behaviour is consistent and expected, and believe that this bug should be closed. But I'd like to hear back from others first. If there is a more specific issue, maybe a new bug should be opened as it seems that we have been talking about a few different issues in the comments. (For example, if you think that writing data next to an outer edge of a data series range should automatically extend the boundaries, please open a new specific report.)
I thought that Excel did it, but I just tested it and it doesn't. However, Google Sheets does it automatically whether we insert a row at the end of the range or we just add values in rows at the end of the range (not at the start). Anyway, I think LO should at least suggest us to automatically extend the range. But it probably can't be considered a bug, so I'm switching it to enhancement.
Thomas, you might want to reword the title to be more specific then.
Following your suggestion, I changed the title. If you have a better idea, just tell me.
Inserting rows at the end (not only adding data) works if Menu/Tools/Options/LibreOffice calc/General - Expand references when new rows/columns are added. But I agree it should detect adding data.
*** Bug 47584 has been marked as a duplicate of this bug. ***
I used to add rows at the beginning, don't want to scroll down. But inserting a row moves the data range down one row. Do we need to detect this too? In other words what action is accepted as extending the data range and when does such a convenience function fail?
There are a lot of questions in the forum about this matter. https://ask.libreoffice.org/search?q=chart%20range%20%23english
The topic was on the agenda of the design meeting but didn't receive further input. To summarize: Inserting a row between start/end adds it to the data range; before start or after the end does not unless the option "Expand references when new rows/columns are added" is checked. Adding data to the end is usually done without adding a row and should be detected. And we should consider to enable SID_SC_INPUT_REF_EXPAND by default => needsDevAdvice whether this bears any harm.