Bug 89754 - using autofill on dates is wrong when increment should be 0
Summary: using autofill on dates is wrong when increment should be 0
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Andreas Heinisch
URL:
Whiteboard: target:7.2.0 target:7.1.3
Keywords:
Depends on:
Blocks: AutoFill
  Show dependency treegraph
 
Reported: 2015-03-01 14:29 UTC by almos
Modified: 2021-03-15 16:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
tests (11.80 KB, application/vnd.oasis.opendocument.spreadsheet)
2015-03-02 09:09 UTC, raal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description almos 2015-03-01 14:29:24 UTC
Grabbing the handle in the bottom right corner of a cell can be used to fill an area with automatically increased values. If more cells are selected initially, they define the autoincrement value. If all selected cells contain the same value, the increment will be 0.

The last one doesn't work for date datatype. If I have e.g. 3 cells containing the same date, e.g. 2012-01-10, select them, and grab the handle, the next 3 cells will contain 2012-01-11, the next 3 cells will contain 2012-01-12 and so on. If I start with N cells, the value will be incremented every N cells. There should be no increment.

I'm using the newest LO version available in Debian Unstable.
Comment 1 raal 2015-03-01 20:39:48 UTC
Please describe steps to reproduce. Thank you.
Comment 2 almos 2015-03-01 23:36:52 UTC
Step 1: open a new spreadsheet in Calc
Step 2: type 2015-02-22 into a cell
Step 3: copy it to the cell below it (control-C, cursor down, control-V)
Step 4: select both cells (press control, click once on each cell, release control)
Step 5: grab the handle in the bottom right corner of the cell with the mouse
Step 6: drag it down a few cells (preferably more than 2 cells)
Step 7: release the mouse button
Step 8: enjoy your new copies of the same date (not)

Do you need more details?
Comment 3 raal 2015-03-02 09:09:57 UTC
Created attachment 113814 [details]
tests

I can confirm with LO 4.4dev, linux and with LO 4.4.0.3, win7

The same problem as with date is with string_number, for example "A1".
Comment 4 GerardF 2015-03-02 09:59:08 UTC
Confirmed with 4.3.5.
Workaround is holding the Ctrl key while dragging.
Comment 5 tommy27 2016-04-16 07:23:14 UTC Comment hidden (obsolete)
Comment 6 almos 2016-04-16 09:58:59 UTC
Still the same with LO 5.1.2.1.0 (Debian unstable). The workaround in comment 4 works, but it's inconsistent with other field types.
Comment 7 QA Administrators 2017-05-22 13:23:08 UTC Comment hidden (obsolete)
Comment 8 almos 2017-05-22 14:04:49 UTC
Still the same with LO 5.2.7 (Debian unstable) and LO 5.3.3 (Debian experimental).
Comment 9 Aron Budea 2017-10-28 18:34:44 UTC
Bug is already in 3.3.0, adjusting version field.
Comment 10 QA Administrators 2018-10-29 03:57:20 UTC Comment hidden (obsolete)
Comment 11 almos 2018-10-30 00:27:37 UTC
Still the same in 6.1.1.2
Comment 12 QA Administrators 2019-10-31 03:36:16 UTC Comment hidden (obsolete)
Comment 13 almos 2019-10-31 18:14:08 UTC
Still the same in 6.3.2.2
Comment 14 Andreas Heinisch 2021-03-06 09:40:37 UTC
https://gerrit.libreoffice.org/c/core/+/112054
Comment 15 Commit Notification 2021-03-11 10:07:45 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3ba901f050d262cdeccefa5b21b0d32aa7332dc7

tdf#89754 - don't increment non different consecutive date cells

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Andreas Heinisch 2021-03-11 15:26:02 UTC
The unit test for this issue is still missing, since the python uitest could not address the specific behaviour in order to reproduce it.

Code pointer for me:
https://opengrok.libreoffice.org/xref/core/sc/qa/unit/ucalc.cxx?r=6b00d057#4820
Comment 17 Commit Notification 2021-03-11 23:24:20 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/1982768ba3db819b84445830ae24e55ecd373d9a

tdf#89754 - don't increment non different consecutive date cells

It will be available in 7.1.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2021-03-12 07:51:43 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d8e1892d7dd3eb5d4724ef32ce7a110a0087d9e1

tdf#89754: sc_ucalc: Fix test

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Andreas Heinisch 2021-03-12 07:56:25 UTC
Thx Xisco for the test! I think we should not close the bug, because of coment 3. I will come up with a patch, when I am back from the hospital.
Comment 20 Andreas Heinisch 2021-03-15 16:47:08 UTC
I tried to reproduce the issue in comment 3, but I cannot reproduce it with

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 347878c717f317e6eb608ca242739fc9e6cc6d78
CPU threads: 6; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL

so I will close this report.