Bug 59312 - AUTOFILTER: in non functional after 'Copy Sheet' in new sheet
Summary: AUTOFILTER: in non functional after 'Copy Sheet' in new sheet
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: AutoFilter
  Show dependency treegraph
 
Reported: 2013-01-13 08:49 UTC by Rainer Bielefeld Retired
Modified: 2020-05-14 06:38 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Document (18.55 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2013-01-13 08:49 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2013-01-13 08:49:05 UTC
Created attachment 72950 [details]
Sample Document

Steps to reproduce with parallel installation of  "LOdev  4.0.0.1 rc   -  GERMAN UI / German Locale  [Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)]"  {tinderbox: @6, pull time 2013-01-10(?)} on German WIN7 Home Premium (64bit) with separate /40 User Profile for Master Branch:
1. Open attached Sample Document
2. 'right click Stheet Tab "Tabelle21" -> Move/Copy Sheet - 
   Copy - Move to End Position <OK> '
   > Sheet "Tabelle21_2" created
3. Click an Autofilter pulldown Icon (in Cell "Tabelle21_2.A1")
   Current behavior: Nothing happens
   Expected behavior: Autofilter action

After 'Save -> Close -> Remove' the Autofilter Icons will have been removed. They should have been removed immediately after creation of new sheet.

              
Operating System: Windows 7
Version: 4.0.0.1 rc
Comment 1 Rainer Bielefeld Retired 2013-01-13 08:57:16 UTC
Already [Reproducible] with Server Installation of "LibreOffice 3.3.3  German UI/Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit) 
and
AOOo 3.4.0
The Appearance is a little different with the old autofilter design, but the result is as in latest versions: no function.

So inherited from OOo
Comment 2 Rainer Bielefeld Retired 2013-03-16 18:53:54 UTC Comment hidden (obsolete)
Comment 3 QA Administrators 2015-02-19 15:32:11 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-03-07 11:39:20 UTC
Still reproduced.

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 5 tommy27 2016-04-16 07:24:13 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2017-05-22 13:24:53 UTC Comment hidden (obsolete)
Comment 7 Zineta 2017-08-25 13:19:33 UTC
Still reproducible.
Win7. Versions:5.2.7.2 , 6.0.0.0alpha0+
Comment 8 QA Administrators 2018-08-26 02:39:34 UTC Comment hidden (obsolete)
Comment 9 Oliver Brinzing 2019-02-20 17:58:02 UTC
still reproducible with:

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0ae876595e9d9af44fc4d4bc948f8a42d8a27e8d
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded
Comment 10 b. 2020-05-14 06:38:08 UTC
for the Bug Hunting Session 7.0.0.0.a1+: 

OP behaviour still repro, 

same action (copy sheet with defined autofilter) with some other data works ok!, you gain functioning autofilters in the copied sheet, e.g. http://bugs.documentfoundation.org/attachment.cgi?id=56922 from #45958, 

difference: 

the file 'source.ods' for this bug has! a 'defined range' which the filter is 'mapped'? to, 

('forfilters' defined with '<table:database-range table:name="forfilters" table:target-range-address="Tabelle21.A1:Tabelle21.I9" table:display-filter-buttons="true" table:orientation="column"/>' in content.xml)

while 'example.ods' from #45958 doesn't have such a definition, and the filter is mapped to an '__Anonymous_Sheet_DB__0', 

(such database ranges are defined automatically when you apply an autofilter which doesn't find a defined range to apply to, '<table:database-range table:name="__Anonymous_Sheet_DB__0" table:target-range-address="Hoja1.A1:Hoja1.C1048574" table:display-filter-buttons="true"/>' in content.xml)

(forfilters does have a 'xml_tag'? table:orientation="column" which is applied - mostly? - when re-saving a file after save-load cycle and is relevant for other misinterpretations, e.g. https://bugs.documentfoundation.org/show_bug.cgi?id=132488 - dunno if that steps in here too) 

and! forfilters is a 'defined range' which is a name 'global to a document'? and can: 
- neither have multiple definitions with different 'scopes' like 'named ranges' may have, 
- nor is a 'per sheet' definition, as '__Anonymous_Sheet_DB__0' is, which as well can have multiple definitions within one document, one per sheet, thanks @Eike for clarification, 

thus it's logically impossible to create an identical fully working copy of a sheet with an autofilter defined referencing a 'defined range', 

unless you e.g. work with new names like e.g. 'forfilters_01' ..., or define and set 'scopes' for defined ranges, or other creative solutions, 

be aware that the behaviour of #132488 messing around with the .field values might step in for any development and tests of this problem ... i can't judge this reg. very small knowledge about the structures and the code (in fact i just stumbled across this bug when i was looking for the steps in which 'table:field-number=' and 'table:orientation="column"' are defined for the save to file and are read back for runtime representation, any tips for that would be highly appreciated - in #132488 o.c.), 

all above looked for and said by a 'newbie', i apologize for any mistakes I may have made ... 

as well i apologize for the length of my contribution, I try to analyze and present the situation clearly, i hope for 'old bugs' such an approach is allowed, 

maybe you should introduce a new category: 'currently not solveable' and declare such bugs as enhancement requests? 

simply omitting the filter buttons as suggested by the OP would not be a solution in my opinion, the copy of the sheet would be incomplete,