<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - calc: fileopen: filter: irregular reading and saving of filter definitions in ods format affecting all filters"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=133336">133336</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>calc: fileopen: filter: irregular reading and saving of filter definitions in ods format affecting all filters
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>4.1.6.2 release
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Calc
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>newbie-02@gmx.de
</td>
</tr></table>
<p>
<div>
<pre>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:</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>