[Libreoffice-bugs] [Bug 133529] New: calc: ui: filesave: conflict between sort and filter, unclear use of tag 'table:orientation'

[bugzilla-daemon at bugs.documentfoundation.org]

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

            Bug ID: 133529
           Summary: calc: ui: filesave: conflict between sort and filter,
                    unclear use of tag 'table:orientation'
           Product: LibreOffice
           Version: 3.5.2 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: newbie-02 at gmx.de

Description:
all of the following happened for defined 'database-ranges' (<data - define
range>) which do not start on the 'diagonal' cells A1-B2-C3-D4-E5-F6, as it's a
result of 'row-offset' and 'column-offset' of the range being different, and
the wrong of them is used for some calculations, 

while working on tdf#133336 it came up that filter and sort definitions depend
on the definition of the 'table:orientation' ('row' by default, 'column' can be
set), 

sort has an option to set 'horizontal' sorting, see 'options' tab in the dialog
<data - sort> (left to right, sort by values in one row, changing the sequence
of the columns), 

this orientation is marked by something in memory at runtime, and by a tag
'table:orientation="column"' on save of the sheet. 

it's conflicting with the definition of filters, which also evaluate and affect
the orientation of the table-range, 

this results in some irregularities: 

- if you set 'sort' new and select the key first, then go to the tab 'options'
and change the direction and confirm with ok on that tab, sometimes the sorting
is not done, on a recheck you see the key is set to 'undefined', 

- if you additionally filter a range with horizontal sorting (this
automatically happens vertically), a wrong key is displayed for a recheck of
'sort', and the sorting direction is set back to 'top to bottom', 

- starting with the first save, wrong and not standard-conform values for
'table:field-number' are written to the files for sort, and starting with the
second save for filter, 

- reading in filters stored in files works only partially, for access via the
UI two errors cancel each other out, for access via basic / macros the
filterdescriptor.filterfields(x).field values are useless, !!that's my main
concern!!

i don't know spontaneously how to solve this, the orientation is obviously used
by two procedures - sort and filter - each according to its own gusto, and a
change in one area harms the other, 

Steps to Reproduce:
1. spread values 1 to 9 in B3:D5, 
2. apply a name to that range <data - define range>
3. sort this range by some row, horizontally, 
4. recheck the sort, same key and direction proposed, 
5. add a filter <data - autofilter - push-button - select a value> 
6. recheck the sort, wrong key proposed, recheck the sort direction, is reset
to 'top to bottom', 
7. this detail is the fastest to check, the .field values not functional is the
bad impact to work of macro programmers, 

Actual Results:
settings of orientation for sort and filter conflicting, 

Expected Results:
settings for sort and filter independent and all options working, 


Reproducible: Always


User Profile Reset: Yes



Additional Info:
all versions from 3.5.1.2 till today,

-- 
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/20200530/0aff4590/attachment.htm>