Description: In Calc can sum a column at least two ways: #1 select cell at bottom of column of numbers and click Sum button at left of Input line. Contiguous range above selected cell is selected. =sum(<range>) in input line. Click green check and formula is entered in selected cell. #2 select column of numbers and empty cell beneath column. Click sum button. =sum(<range>) appears immediately in empty cell. No need to confirm. For both methods =sum() formula is inserted in empty cell In Writer if attempt to sum column similar to #1 above then after inserting cursor in empty cell range to be summed must be selected after clicking sum button. And then must click green check to complete summing operation. If range to sum is selected and end of selection is empty cell presumed to be destination for sum formula then sum button clicked selected range is emptied and Input line appears with =sum() formula with third-to-last selected cell loaded as range of formula. Clicking check to enter formula causes 0 to be entered in last cell, value in second-to-last cell to again be visible, and value in third-to-last cell and any cells above to be empty. This is very unexpected behavior. Especially if one is familiar with either method of summing described for Calc. Request Writer table cell sum feature be modified to work like descriptions provided for Calc. Alternately, request Writer table cell sum feature be modified so that if range is selected prior to clicking sum button then sum is entered in last cell of selected range vs current behavior of emptying range. Steps to Reproduce: 1. create a multi row table in Writer 2. enter numbers in a column in the table, leave at least one empty row beneath last number 3. select column of numbers and empty cell beneath 4. click Sum button on table toolbar 5. after clicking Sum button all selected cells are empty 6. click green check mark next to =sum formula in input line 7. all except last two cells that were selected are now empty. Last cell has 0 entered. Next to last cell has number that was there before Sum button was clicked. Actual Results: The result cell value is set to 0 (zero). The cell above the result cell returns to its original value. All cells above these last two cells have been emptied. Expected Results: Selecting column of numbers then clicking sum button should sum the numbers and enter result in last selected cell. Summing cells should work way it works in Calc. Reproducible: Always User Profile Reset: Yes Additional Info: see attachment for bug demo
Created attachment 167993 [details] demonstration of bug
Thank you for reporting the bug. I can confirm that the bug is present in Version: 7.2.0.0.alpha0+ Build ID: d9ccee2231a8d8984302e1b2f578bf73b4d60c35 CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Additional comments: When reproducing bugs the results changed a bit. The “result” cell calculates a sum of the range selected; however, the range which previously had numbers is now empty with the exception to the last cell within the sum range (not the result cell but the one immediately before it). This also happens if you try to sum values horizontally, and with any other formula.
Same behaviour already in 3.3.0
Dear Alan, 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
Checked again with current versions of LibreOffice, 7.4.3 and 7.3.7. Bug still exactly as described. Bug can be reproduced exactly as described. 7.3.7.2 Help About Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 1; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded 7.4.3.2 Help About Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 1; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded