Cannot add or remove DataGroups for Columns but OK for Rows

English
#1

Version: 7.5.9.2 (X86_64) / LibreOffice Community
Build ID: cdeefe45c17511d326101eed8008ac4092f278a9
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

A little background; I “dropped back” to this version because the update 7.6.5 installed on 4th March turned the named range auto filter functionality into a pavement pizza – Bug 160018.

I have a workbook with multiple sheets - some hidden - with many of the sheets having rows and or columns concealed with DATA>Group&Outline>Group or F12.

I know the functionality was correct on 1st March because that’s when I perform a monthly update and shuffle my primary focus columns along so I see the current month’s column together with appropriate preceeding and following columns. Everything irrelevant is concealed.

Today, on one sheet only, the system refused all commands to ungroup a range of columns either by [Ctrl]+F12 or selecting from the menu. It also refused to allow creation of new columnar groups. However, it will allow me to add or remove groups by either method when they relate to rows. Also, previous annual versions of the same file behave as expected.

There is simply no response when trying to remove the Columnar Grouping and trying to create a new group on “fresh” columns elicits the warning “This function cannot be used with multiple selections” - even if only one column is selected.

I imagine something that occurred during the “downgrade” affected just this sheet in this workbook.

I have tried (on the affected sheet only):-
Restarting in safe mode
Making OS copies of the file
“Save As” in LO
“Save Copy” in LO
Removing embedded charts
Removing embedded URL buttons
Exposing and concealing all rows and columns

Can any of you “Big Boys” think of something that may work?

Thanks in anticipation

#4

Select All rows and unhidden them. Now you can group/ungroup.

1 Like
#5

@mariosv I didn’t attempt that because then I would have to redefine all the Row Groups :frowning:
I discovered that it’s related to the fact that there is also an autofilter on a defined range commencing on row 14 for just 6 columns and 60 rows - directly adjacent to another hidden column and “concealed” by an overlaid chart.
Removing the filter - re-grouping - re-applying the filter solves the problem

#6

You can see that it happens with filtered rows, not with manually hidden rows.

And I think it is because the cells hidden by a filter are not part of the column selection while the manually hidden ones are.

When copying from a filtered range, only the visible cells are copied, while copying from a range with hidden cells, they are all copied, visible or not.

Attached is an example file, for testing.
Untitled 1.ods (9.4 KB)

#7

I made an adjustment to your sheet by dragfilling A16:A22 1 - 7 and then applying grouping (F12) to rows 17-21 and copying all the ranges to column J. - As you noted, it disallows the copying ONLY when the concealment is due to the filter

I had observed (and reported that as a bug) 3-4 years ago because it seemed illogical to allow the range copy on two types of hidden rows and not the third concealed by a filter.

I hadn’t identified at that time that it also wouldn’t permit grouping of columns whilst the filter is actively concealing something but it will permit grouping of rows under the same circustances.

In my experience it becomes quite tedious when filling formulae to find it works in one direction but not the other. Consistency would be a lot more convenient.

I certainly use filters to “mask” data I don’t wish to see in charts but I can’t imagine ever wanting to have it not sequentially copy columns and rows when I drag fill.

If you can see the logic in that perhaps you could share an example…

#8

tdf#45958
Only Copy Visible Cells (after a filter) doesn’t work when only unfiltered columns are selected - FIXED

#9

I can see how the debate on what should and should not be COPIED has arisen and that the system now complies with the concensus at that time.
I don’t see any evidence that the concensus ever considered either the relevance of creating or deleting columnar groups not working whist working for row groups or that the columnar “feature” is only apparent when there is an active autofiltered array outside the columnar target.
Perhaps that fix created a new unrecognised feature that doesn’t seem to fit the logic of a fairly straightforward columnar group creation.
Do you think it’s working logically?
I think it’s just adhering to the specification for cutting and pasting hidden cells when it is neither cutting nor pasting anything.

#2

aka tdf#160018

to narrow that down :
https://wiki.documentfoundation.org/QA/Bibisect

:pray:

#3

It probably predates tdf#160018
A new bug report has been filed tdf#160470

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.