https://bugs.documentfoundation.org/show_bug.cgi?id=160018
--- Comment #3 from Colin <[email protected]> --- (In reply to ady from comment #2) > Repro with 7.6.5.2. and in recent alpha. > > No repro with 7.5.3.2. > > @Colin, > > It would be better to have more precise steps to reproduce. Since you have a > better idea of what you expect to see and how you work with the list(s), > please try to come up with a minimal set of steps to reproduce the problem. > Hunch: headers should be visible, so to hide/show groups of columns and rows > (more easily). > The precise steps to reproduce in 7.6.5.2 really are as simple as; Unhide the defined range for the header "Fruit & Veg" - which is the local name for the defined range "Veg" - this will expose all relevant products. Sort column B "Fruit & Veg" using any of the predefined sort criteria. Observe the chaos Perhaps a description of a previously encountered and reported bug may help. If more than one range is defined in a column then they must be seperated by at least one cell. If there is no seperation zone and data is inadvertently entered into the cell(s) between tables then the upper range will overflow into the lower range. This will cause the filter function to consolidate both tables and act as if they were one table. the sorting will be upon everything in both tables - even to the extent of moving the "header" cell with its own filter to the (in)appropriate place in the list. I don't know if there has been a remedy for this since I first reported the underlying bug - my workaround worked until this morning. As mentioned, the only method of avoiding this is to have a clear demarcation zone between the lower row of the first table and the upper row of the next table ad infinitum. As it's far too easy to inadvertently add something into the "forbidden zone" then each end zone had been Menu>Data>Validated as "data entry forbidden" with a contrived data validation of "must be a whole number greater than 999999999999 with empty cells permitted". This results in a STOP. The first time I used the sheet after yesterday's update was 04:30 today and the moment I sorted on the product description it contrived to almost randomly modify the Data Groups - which previously permitted the products in the various departments to be concealed - and applied the sort across every bit of data in column B. Undoing the action returned the status quo and sorting on any of the adjacent filters didn't destroy the integrity of the tables. As you can see, the values within the departments are accumulated and summarised in the cell adjacent to the department name. My apoligies if I assumed that the moment somebody followed my instructions _ open the table and sort it, then the impact would have been obvious. Nobody would want to see a whole list of departments merged into one contiguous column with "randomised" data groups Background story; the two stores are adjacent to each other and publish all their prices online. ICA gives us old 'uns an extra 5% discount so when I go shopping I just put in the prices and my shopping list then tells me where is the best deal and how much it should cost me. Yes, the departments are in "walk through" order and the products similarly organised. I'm retired - what else am I gonna do? Is that too much information ;) -- You are receiving this mail because: You are the assignee for the bug.
