[Libreoffice-bugs] [Bug 107385] Autofilter sorting breaks rows data alignment without warning

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=107385

--- Comment #13 from b. <newbie-02 at gmx.de> ---

(In reply to Luca from comment #12 and OP)

> Obviously you don't understand the nature of this bug and its destructive 
> potential, ... 

it may be that i'm on the wrong trail, let me explain my understanding: 

> This is the kind of bug that can destroy any recursive backup, because 
> possibly you realize that Calc destroyed the rows integrity only after having 
> backed up the whole mess.

??? imho calc wont harm a backup from before your daily work in the evening,
won't harm a backup from 13:30 at 14:00, and won't harm a backup from before
sorting with the sorting, consider external backups or time stamped backups
with the script from c#11, the one 'always create a backup copy' you can
activate in calc is not sufficient for important work, and has the drawback to
kill your undo buffer ... 

> Sure. That's why you can *usually* select a set of columns before applying the 
> sorting in Calc. That's exactly why this is a serious bug: Calc *in this case* 
> does not honour the user's selection choice and arbitrarily decides to sort 
> what it likes. If this behaviour doesn't change, there *must* be a warning 
> here.

from your OP: 

> Autofilter sorting doesn't affect non autofiltered columns, 

> 4) Select Data/Autofilter, to setup autofilter labels on A and B, but not C.
> 5) Click on the A lable
> 6) Select Sort/Descending (or Ascending, depending on how you sorted data in 
> the first place)

> Actual Results:  
> Only the A and B column get sorted, while the C column sticks to the original > sorting. Raws data alignment is broken. Big mess. 

what do you expect calc to do after you explicitly! told it to work on columns
A and B ??? do something other? it does it often enough, in this case it
doesn't ... you decided the target, don't complain, 

> 7) Select a cell in the C column
> 8) Select Data/Sort...

> Autofilter labels on A and B columns get lost.

that's because you don't work with 'defined database ranges', in such cases
calc constructs one - only one! - 'anonymous' database range per sheet for the
users comfort, but changes that every time it's used for another area, thus
somewhat unstable. solution: <data - define range - select the area you want to
work in>, and calc will work in a way that's easier to understand and where the
user has a handle to steer it, 

i'm not against a warning as proposed in c#1, but that's not a critical bug but
an enhancement request, 

from c#3: 
> Nope. Please, go to step 4, then try selecting whichever area you want 
> (column, group of cells, or select all) then apply step 5 and 6, look what 
> happens. You have no control whatsoever on the area to be sorted: sorting 
> always applies to all columns with the autofilter label, and never to the 
> other columns, no matter which area you selected before sorting. So, if you 
> wanted to create *your* mess, you couldn't. It's the program that *always* 
> create the mess of its own choice. 

no ... imho it's a three step process, in step 1 you define col A+B as
autofilter target, in step 2 you select another range, in step 3 you work with
the autofilter defined in step 1, the range selected in step2 doesn't have an
autofilter ... quite easy to get other behaviour, select new target area, apply
<data - autofilter>, sort with autofilter, it worked for me, 

or ... dont use autofilter for sorting, there is <data - sort> which will work
independent from your range definition ... 

if i'm wrong just tell me, what exactly is a fail! in calc's behaviour, for the
moment i'd say 'sharp knifes carry risks', and with defined ranges you can
reduce your risk, 

> Nope. It's quite the opposite.

you selected col. A and B as target, and got calc to work there, that's the
small gap where calc couldn't stop you from making your faults ... 

sorry if i'm wrong, but then your description may have shortcomings too ... 

reg. b.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200608/ac59af93/attachment.htm>