[Libreoffice-bugs] [Bug 133336] New: calc: fileopen: filter: irregular reading and saving of filter definitions in ods format affecting all filters

[bugzilla-daemon at bugs.documentfoundation.org]

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

            Bug ID: 133336
           Summary: calc: fileopen: filter: irregular reading and saving
                    of filter definitions in ods format affecting all
                    filters
           Product: LibreOffice
           Version: 4.1.6.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:
filter conditions are saved incorrectly in ods format starting with the second
save. 

e.g.: first save no tag 'table:orientation="column"', field-number(s) "0" and
"1", 

after save - close - reopen - save without modifications: 

range has an additional tag 'table:orientation="column"', field-number(s) "-1"
and "0", 

starting with the reload of the first save access to filtered fields by macros
/ basic fail. 

preconditions: the filtered range should not start at fields A1-B2-C3-D4-E5-F6
..., in such cases you get the wrong flag 'orientation', but can't spot the
'field-number' errors because 'row-offset' and 'column-offset' have the same
value, 

imho the second save is wrong and violates the tdf standard for documents as it
applies a filtering condition to a field '-1' off relative to the addressed
range and thus outside of it, 

imho the initial fail is the read/load of the first save, after that the
'.field' values accessible by basic/macros are messed up, 

imho fails like this are critical as they undermine any downstream work,
analysis and fixing, 

will apply sample documents in next comments, observe that on loading them you
have a re-read condition, thus don't get the initial correct state, it's better
to check them with a packer and open the content.xml file inside and / or
create the files from scratch as described in 'steps', 

this bug affects 'autofilter' too, as well as advanced filters, 

this bug is related to bugs filed during my approach to the problem, e.g.
129105, 132120, 132488, it's not! a dup as it's reg. all filters while the
others mention only the behaviour of autofilter, 

someone is working in that area and added '// FIXME this was wrongly exported
to the TABLE namespace since 2011' to XMLExportDataPilot.cxx shortly?, would be
nice and might also help him if he could have a look at this bug, 

@xisco: if you like to group the bugs together please! let this one as new as
it's a clear description, 

let's hurry up and get this fixed before 7.0 release ... 

Steps to Reproduce:
1. fresh sheet B3:a C3:b D3:c, B4:1 C4:2 D4:1, B5:2 C5:1 D5:2, B6:3 C6:1 D6:1,
B7:2 C7:2, D7:2
2. data - define range "b" B3:D7
3. data - more filters - standard filter 'a = 2' AND 'b = 1'
4. save file, close file, reload file, save file with new name
5. inspect files with packer - e.g. 7-zip - and look into the contained
'content.xml' file
6. first save: 
------------
<table:database-ranges>
   <table:database-range table:name="b"
table:target-range-address="Sheet1.B3:Sheet1.D7">
      <table:filter>
         <table:filter-and>
            <table:filter-condition table:field-number="0"
table:data-type="number" table:value="2" table:operator="="/>
            <table:filter-condition table:field-number="1"
table:data-type="number" table:value="1" table:operator="="/> 
------------
7. second save: 
------------
<table:database-ranges>
   <table:database-range table:name="b"
table:target-range-address="Sheet1.B3:Sheet1.D7" table:orientation="column">
      <table:filter>
         <table:filter-and>
            <table:filter-condition table:field-number="-1"
table:data-type="number" table:value="2" table:operator="="/>
            <table:filter-condition table:field-number="0"
table:data-type="number" table:value="1" table:operator="="/>
------------
8. observe: 
8a. the additional tag ' table:orientation="column"' for the database range, 
8b. the different values for 'field-number' changed from "0" and "1" in the
first save to "-1" and "0" in the second, 
9. the tag 'column' changes the interpretation of the field-number values from
'column-offset' to 'row-offset' and thus the gui works (correct (double
incorrect) labels if you reopen the filter definition), but access by basic
(macros) fails, 

Actual Results:
deviating definitions on subsequent saves violating the document standards

Expected Results:
identical definitions on subsequent saves holding the document standards, 


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc:

-- 
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/20200524/ec1c23c1/attachment.htm>