Created attachment 47188 [details] Pls see original report I found that with "LibreOffice 3.4.0RC1 – WIN7 Home Premium (64bit) English UI [OOO340m1 (Build:11)]" Steps to reproduce: 1. open attached "sample.ods" 2. Click A21 3. Click Fill handle and drag / drop it until cells ...A25 will be filled. So you should have done the Fill > Series function and new contents of cells should be numbers 21 ... 24 in A21:A25 4. click undo button before nest test All new contents should disappear 5. Use Filter: Click Auto Filter arrow in column E with ehading "e" 6. Filter "empty" Nothing should happen, all cells are empty in this column 8. redo from step 2 ... step 4 Expected: same result, numbers 21 ... 24 in A22:A25 Actual: All new cell contents is "20" I also tested with OOo 3.1.1, there fill handle works as expected also with active filter. I only see that problem having used Auto Filter. Doing the same filtering with Standard Filter does not show the broken fill series effect. I believe this is a regression, I believe I would have remarked if that would had happened in stable LibO versions. Related Help: <http://help.libreoffice.org/Calc/Automatically_Calculating_Series>
confirmed using LibO 3.4.1RC1 on linux 32bit
Can you retest with 3.4.1 RC2 or RC3? I think Katarina changed something post 3.4.0 RC1 but otherwise I might have a look at it.
For me the auto fill series is not working on this data set even without playing with the filter.
This is a side effect of fixing this bug: https://issues.apache.org/ooo/show_bug.cgi?id=89232 This was fixed by someone from IBM in OOo, whose patch we've integrated. With this change, when performing autofill on a database area, auto-increment no longer works even when the selected range contains no filtered rows.
Interestingly, Excel has the same limitation. When you try to autofill within a range that has autofilter on, you can never do incremental autofill. Even the manual fill series doesn't work. So, this behavior may be intentionally introduced by that change. I can sort of see why since incrementing over a filtered area is quite complex.
Better title. The word 'corrupt' is too strong a word for this sort of limitation. And since the change may have been intentional, I don't consider this a regression. However, it would be nice to be able to do incremental autofill over a database range. So I'll leave this bug report open for that.
Is solved in master. We now always skip hidden rows/columns regardless if they are from an autofilter or from manual interaction.
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff5fef04c9a0c0c722d2af815333bcec172c15d7 uitest for bug tdf#37623 It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The test exist, set status to Verified.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9c2d5c877d61965d6e5fc9ef2d81299f0e04892c tdf#37623: sc: Move UItest to CppUnittest It will be available in 7.4.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.