Hi Niklas,

seems to be yours. Please give us a short comment.

Frank

Filtered rows are skipped only for copy&paste from the filtered range
to another cell range. This is the intended behavior.

Is it really intended behavour to allow deletion, overwriting and/or reformatting 
of hidden values? I would really like this isse to be considered again as autofilters 
current behavour makes it unusable for most applications that I have seen it used 
for.

Please try again the following test: 

1) Create a blank spreadsheet with 
row 1 containing 2 column headers, e.g.
A1='Item' and B1='What'
2) Fill columns 
A2 to A16 with numbers 1 to 15
3) Add text 'ZZ' to columns B2 : B16
4) Add replace 'ZZ' 
with 'XX' to columns B5, B10 and B14 only

5) Turn on AutoFilter: -standard-what=XX  
This should hide all but rows 5, 10 and 14

6) Select the 3 visible cells in column B 
and hit delete.

7) Switch AutoFilter off (all display -all- on column B). This shows 
that ALL cells B5:B14 have been cleared. Surely one would ONLY expect cells B5,B10 and 
B14 to be cleared and B6:B9,B11:B13 to be left intact as per all other spreadsheet 
applications I have used.

This behavour seems to apply to any type of cell changes 
not just deletion. For 6) above try setting the 'XX' values to bold with a double border 
and see what happens to the other cells. This procedure is often used to highlight sub 
totals - but as it operates now it cannot be used for this.

Behavior should be reconsidered by PM => Enhancement

*** Issue 11500 has been marked as a duplicate of this issue. ***

*** Issue 13187 has been marked as a duplicate of this issue. ***

*** Issue 8008 has been marked as a duplicate of this issue. ***

Ugh, this messes up find and replace too. Rows hidden by a filter are
affected by find and replace, thus massively limiting it's
usefullness. This is not the behaviour in Excel, or any of the other
spreadsheets I've used.

Big table....

Filter on one column, do find and replace to change all values,
whoops, it changes everything, not just the columns that show. This is
broken, broken, broken. Why hide content if content can still be
affected by operations?

I agree. There are only two things preventing my organization from
ditching MSOffice for OOo, and the biggest one is the screwed up
autofilter. If I hide cells with the autofilter, then fill down, OOo
1.1 and earlier fills the HIDDEN cells as well. Excel does not do
this, and since I use a spreadsheet all day for stuff like this, the
screwed up filter behaviour is completely unacceptable - I could end
up totally messing up my spreadsheet without even knowing it.  I hope
that this behaviour is reconsidered, if it's intentional.  Sadly, with
a recent CS degree my coding abilities are too amateur to fix this,
but I would if I could!  This is a defect, IMHO.

*** Issue 17090 has been marked as a duplicate of this issue. ***

I cannot believe that this major defect has been left as a P3 
Enhancement - e.g. less important than http://www.openoffice.
org/project/www/issues/show_bug.cgi?id=11465 

One look at all the comments from this and all the duplicate issues 
show that there are many users who frequently use autofilters in the 
course of their jobs and understand how they are meant to work, unlike 
the OpenOffice one. My checks show that both MS Excel and Lotus 1-2-3 
do NOT allow autofilter hidden fields to be altered.

Please can someone take a proper look at this AND CHECK OTHER 
SPREADSHEET PROGRAMS and leave it as a high priority DEFECT. 

Like the comment From tmanning 2003-07-20 10:36 PDT this is one of the 
last reasons I cannot switch to OpenOffice and am unable to recommend 
it to colleagues or customers.

Creo que es importante corregir este error.

@Namor67: The preferred language here is English. If you set this
issue from NEW to STARTED, then you say that you want to fix this
issue. Is this your intention?

So is this issue really being worked on?

I still see this in 1.1RC3, so I change status.

This is no chicken feed, this bug makes calc unusable for many
applications, I agree with John and suggest target milestone 1.1.1

Rainer

still happens in 1.1rc5...

like tmanning said:
"So is this issue really being worked on?"

there has been no answer from Namor67 who set this issue to new, if he
is working on it.

Could some developer please verify, if there is someone working on it.
If not please resolve and reopen the isse so the status becomes NEW.

Namor67 only said, "I believe it is important to correct this error."
If he set it to STARTED, I believe it was by mistake; based on his
comment. 

Richard Holt.

Yes, I agree that it maybe by mistake. OK I modify the status. 
Resolved (but I didnt know which to choose, so I choose wontfix) and
after this I will reopen it

reopen

Hi All,

if you want this fixed, just do not reassign, change prio and / or
Issue type !

This was considered as enhancement and has to go it's way through it.
Weird changes in such fields just prevent a developer from
implementing it as he never knows that he should do something for it
and it prevents the feature guys from their work as they do not know
that this Issue exist !

Frank

This is not an enhancement, it is a serious defect.  I once destroyed
an entire spreadsheet (and several hours work) because this bug allows
you to overwrite data that is hidden. I bet I'm not the only one.

If you wish this program to continue to be broken and remain useless
to a probably significant number of the OOo and StarOffice targeted
users, I don't mind, but it should be given serious thought. Though I
would love to have StarOffice (and Linux) deployed throughout my
organization (I could make it happen - I head up the IT department at
a consulting company), it has become apparent that this fix will be a
year or two in the making.  In the meantime, we've just purchased some
new MSOffice licenses that will do us for a while, until this issue is
resolved. Sad, but true.  As I said, I'm not complaining, as I already
have a less broken spreadsheet program, and my clients don't know
about OOo yet (I can hardly recommend a program with a bug like this).
I'm just stating the facts.  :(

As the original reporter and one who has spent some time to research 
this issue in Lotus 1-2-3 (the first BIG spreadsheet program) and MS 
Excel, I believe I have a say in this matter. 
This is a serious DEFECT. If the developer thinks it is working as 
intended (i.e. designed) then I'm afraid to say the design is wrong - 
just look at the comments for this and all the related/duplicate 
issues from people who know how autofilters are meant to behave.
Why can't the OO team accept this and change this to a P2 DEFECT and 
then we may have some chance of getting this fixed.

Here goes my vote for this issue.
It really seems to be a serious defect in the Calc application.

I really hope that it'll be finally fixed for 1.1.1 as it is currently
indicated in the "Target Milestone" field.

Greetings,
Gabriel Gazzán

Hi Frank,
I agree, all these changes are not helpful at all. I can live with
actual status if it would really be fixed in 1.1.1, but because it is
classified as an ENHANCEMENT, I do not believe it.

This is a DEFECT, there can be no doubt at all, and it is a serious
defect, because it can cause dataloss. So I can not understand why
this issue can be an ENHANCEMENT.

I will respect your hint, but I am not convinced at all.

Rainer

!!!  Everything has been said concerning severity of this issue      
              !!!

!!!      Please no more comments except patches or solutions      !!!

!!!                 Please VOTE without any comment!              !!!


Rainer

I agree. This is not a feature, this is more of a bug. why go thru 
all that trouble of setting up and not take advantage of that work?

As the original reporter and based on all the comments others have put 
in I am trying to set this back to a P2 DEFECT for the follwing 
reasons:

DEFECT - it is an issue in existing feature/functionality
P2 - it causes data loss

A warning has been implemented since OOo 1.1 coming up at the moment
one is pasting content into other cells with content to avoid unwanted
modifying of existing content. In a second step (for Office later) we
could implement a solution like an option asking whether one want's to
consider hidden cells at using autofilter.

This doesn't fix the fill down issue, and you can still overwrite your
data unknowingly. I don't mean to be rude, but I don't understand the
reluctance to classify this as a defect.  Perhaps the problem was not
explained properly. Try putting this data in OOo, and try it in
Excel/Lotus/whatever, and see what happens:

A
-----
1
2
1

Autofilter, select to show the number 1 only.  Then fill down from row
 1. NO warnings seem to pop up.  Everything must be ok.  Take the
filter off.  What do you see?  In OOo, you see a column of 1's.  In
more useful spreadsheets, you will see that the data has not changed.

Hi Bettina,

the warning you mentioned helps for nothing: everyone will switch it
off soon, because that alarm is really boring for normal work with the
spreadsheed. Ad, as mentioned by you, it can avoid only 1 of many
dataloss dangers.

But please see something else: dataloss is only one of the problems
caused by the actual design. It also makes impossible to work with the
spreadsheet for many applications. I very often need the filter
function to select data sets with a common characteristic and than to
do e operation with all those (and only allthose) selected data sets.

Example:
I have measurement results for outdoor air temperature and humidity,
and I want to calculate "average relative humidity for all datasets
with an air temperature below 0°C".
In all other spreadsheets I can mark all visible data sets by mouse
easily and then do the operation. With OOo filtering is no problem,
but then I have to select every single visible dataset separate with
<Cntrl-Mouseclick>, what is a little boring if I have 625 data sets
with temperature below 0 ;-)

This is a _serious_ limitation for the usability of OOo Calc. could
you please considerate this separate from the dataloss problem?

CU

Rainer

I totally agree with the comments from Rainer. 

However I think the real problem is that the OpenOffice developers 
don't understand how critical a proper functioning autofilter is to a 
modern day spreadsheet for doing suchlike things.

A warning is useless. I imagine that no one in the world will 
deliberately use the option to allow hidden data to be destroyed 
unless it is done maliciously to a colleages machine.

We now have a situation where OpenOffice is seen as a serious 
alternative to MS Office for word processing but with such a brain 
damaged spreadsheet it cannot yet rival Excel or Lotus 1-2-3

This is a very serious DEFECT - treat it as such

*** Issue 21915 has been marked as a duplicate of this issue. ***

Well that 21915 was me. :)
Your immensely complex, ugly, awkward 2-page search form had found -- 
nothing. And I had searched 2 times for 'autofilter', but well -- it 
might actually be I set the 49th of those 50 options wrongly :-)
This is a form for developers, not for users, mind you!
Would be nice if there was a simple form also for simple search, for 
John Doe. These special features provided there are only needed in 1 
out of 1000 cases.

==

Back to the original problem:
I fully agree with John C. that it is a SERIOUS DEFECT.
Having to spend SEVERAL HOURS to fix my spreadsheet is really not a 
cool thing.
And well, it's on you guys: be as reluctant as you are at the moment 
to eventually fix it, and you've lost another OOo client.
Seriously. I won't spend this amount of hours again nor do I want to 
do everything by hand instead.
Nah. If this happens again, OOo gets replaced by excel.
Seriously, too.
-AE-

*DIRECTLY* to John:

(quote)
"As the original reporter and based on all the comments others have 
put 
in I am trying to set this back to a P2 DEFECT for the follwing 
reasons: 

DEFECT - it is an issue in existing feature/functionality
P2 - it causes data lossAs the original reporter and based on all the 
comments others have put 
in I am trying to set this back to a P2 DEFECT for the follwing 
reasons:

DEFECT - it is an issue in existing feature/functionality
P2 - it causes data loss (/quote)


Could you please tell me why this is STILL an ENHANCEMENT today, 
after 11 days you posted the above?
Did you actually set it to DEFECT and some other guy put it back to 
ENHANCEMENT or what?
I wasn't here at that time, so please clear this up. Thanks.

-AE-

*In response to Andreas*

As can be seen (but not very well) under Issue Activity I originally 
reported this as a DEFECT but it was rejected as a WONTFIX as the 
developer said it worked as intended!

I reopened it and it was changed back to a P3 ENHANCEMENT. I have 
changed it back (twice I think) to a DEFECT and each time it was set 
to an ENHANCEMENT.

I am beginning to give up and feel I will have to put up with Excel 
forever!

John

Don't the number of votes alone indicate the seriousness of this issue
(60 at the moment!)? Whatever it takes - lets get this escalated!

Hello Richard, the votes are taken very seriously, otherwise this
issue would not have been reset to the target OO.o 2.0, although this
feature does not belong to a defined keyfeature for the Q (OO.o 2.0).
But before setting the target to the next milestone we had to discuss
possible solutions for this problem and that also considering our
resources for Q (discussion took place before the 02.11.). That can
unfortunately take time. 
Now to the suggested solution:
There are in principle two cases. Cells hidden by use of the
autofilter and cells hidden manually.
If there are hidden cells in a filtered area within a selection, then
this selection will be handled always as a multi-selection, that means
the hidden cells are not edited.
If there are hidden cells, which are not within a filtered area, then
these cells are treated as it happenes currently, they are edited.

This is a suggested solution, which will now get into a specification.
Nevertheless further suggestions are always welcome.
Hi Falko, please take over this issue for specifying. Thank you.

I'm copying this info into issue 2977 issue 21773 as 2977 seems to be
focussed on PASTING and 21773 seems to be related to COPY'ing.

Does someone want to decide whether to include copy AND paste
operations in issue 2977 (the older, more discussed, voted on etc
issue), or keep the issues separate. Due to the complication of COPY
CUT PASTE and DELETE (see below) I suggest a single issue.

When looking in 1.1 Help to check terminology I found a page titled
'Only Copy Visible Cells' in the index under 'hidden cells / do not
copy'. This page indicates there are 3 behaviours when COPYING:
a) copy of autofilter - only visible cells copied
b) move of autofilter (cut/paste or drag) - visible and hidden cells moved
c) copy OR move of explicit hide or Outline Group hidden - all cells
copied or moved.

I confirmed by testing that the above help info does indeed matches
current 1.1 Calc behaviour for COPY, provided that 'visible cells' is
defined as the visible result of the autofilter WITHOUT any cells
hidden by formatting or Outline Group / Hide Group.

MS Excel exhibits the following behaviour (using the example from
issue 2977) - sorry this is long:
1) Create a blank spreadsheet with row 1 containing 2 column headers,
e.g. A1='Item' and B1='What'
2) Fill columns A2 to A16 with numbers 1 to 15
3) Add a text 'XX' to columns B5, B10 and B14 only

4a) Turn on AutoFilter: -standard-what=-empty-  This should hide rows
5, 10 and 14.
4b) Select A1:B16, COPY and paste to a new worksheet.
Result: Only visible cells are copied (12 rows total=15 rows excluding
B5,B10,B14)

5a) Keep the above and hide row 7.
5b) Select A1:B16, COPY and paste to a new worksheet.
Result: only visible cells are copied (11 rows total=15 rows excluding
5, 10, 14 and 7)

6a) Keep above and use the PivotTable/Outline function to group row 12
and hide it.
6b) Select A1:B16, COPY and paste to a new worksheet.
Result: only visible cells are copied (10 rows copied=15 rows
excluding 5, 10, 14, 7 and 12)

7a) Keep the above but remove the AutoFilter
7b) Select A1:B16, COPY and paste to a new worksheet.
Result: all rows are copied.

8a) Return to step 4a (unhide hidden rows and Outline Group, apply filter)
8b) Select A1:B16, CUT and paste to a new worksheet.
Result: ALL rows are moved.

9a) Keep above (undo CUT or move data back) and hide row 7.
9b) Select A1:B16, CUT and paste to a new worksheet.
Result: ALL rows are moved.

10a) Keep above (undo CUT or move data back) and use the
PivotTable/Outline function to group row 12 and hide it.
10b) Select A1:B16, CUT and paste to a new worksheet.
Result: ALL rows are moved.

11a) Return to step 4a (unhide hidden rows and Outline Group, apply
filter).
11b) In empty cells in column B enter O (enter individually - don't
use paste!)
11c) Select A5:B8, DELETE, then remove filter to see effect of DELETE.
Result: Only selected visible cells (rows 5, 7 and 8) were DELETE'd

12a) Return test data to state after 11b)
12b) Hide row 7
12c) Select A5:B8, DELETE, then remove filter to see effect of DELETE.
Result: Only selected visible cells (row 5 and 8) were deleted.

13a) Return test data to state after 11b)
13b) use the PivotTable/Outline function to group row 7 and hide it.
13c) Select A5:B8, DELETE, then remove filter to see effect of DELETE.
Result: Only selected visible cells (row 5 and 8) were deleted.

14a) Return test data to state after 11b)
14b) Remove AutoFilter
14c) Hide row 7
14d) Select A5:B8, DELETE, then remove filter to see effect of DELETE.
Result: Rows 5-8 deleted.

So the outcome of this test is that in Excel 97:
i) COPY only operates on visible cells whenever an AutoFilter is
active (different to OOo, as it copies only visible cells not hidden
by the autofilter, hidden cells OR hidden Groups).
ii) COPY operates on all cells (visible and hidden) if no AutoFilter
is active (same as OOo)
iii) CUT/move operates on all cells at all times (same as OOo)
iv) DELETE operates similarly to COPY (OOo DELETEs all cells at all times)

PASTE is the subject of issue 2977 and well described there. 

Comparing Excel to OOo:
i) When AutoFilter on, OOo copies all cells not hidden by AutoFilter,
Excel copies all VISIBLE cells
ii) Excel and OOo same.
iii) Excel and OOo same.
iv) OOo deletes all cells at all times, Excel's DELETE operates
similarly to COPY: if AutoFilter on only DELETEs VISIBLE; if
AutoFilter off, DELETEs all cells.

Although the above Excel behaviour is not intuitive to me, it does
follow the 'do not destroy' behaviour if AutoFilter is on. This is the
same 'do not destroy' request of issue 2977 for pasting. And although
not intuitive it IS what MS Office users would expect.

Does anyone want to confirm the Excel behaviour in 2000 or XP
versions? Are there any properties that allow the behaviours to be
modified/customised?

Based on the above, and the expectation that we want to be compatible
with MS Office users, should the Excel 97 behaviour be what is
required in this issue? Is it worthwhile including a preference to
allow this behaviour to be explicitly defined? Spreadsheet / General
has Input settings that it could be related to.

FT: Thank you very much for you competitive analysis with Excel. This
really helps a lot!
This issues will cover all(!) kinds of operations (paste, cut, delete,
copy) for hidden cells.
Since I am very busy for at least next year writing specs for OO.o I
will touch this issue _not_ before early 2004.

FT: Thank you very much for you competitive analysis with Excel. This
really helps a lot!
This issues will cover all(!) kinds of operations (paste, cut, delete,
copy) for hidden cells.
Since I am very busy for at least next year writing specs for OO.o I
will touch this issue _not_ before early 2004.

*** Issue 21773 has been marked as a duplicate of this issue. ***

Modified title

*** Issue 22177 has been marked as a duplicate of this issue. ***

I have just done a search and found 7 duplicate issues have been 
closed and marked as duplicates of this fundamental **DEFECT** in the 
operation of the autofilter, yet again it has been reduced to a P3 
ENHANCEMENT.

Come on OOo team - accept this is a real issue that needs to be fixed 
urgently or initiatives such as the MG Rover and Newham Council trials 
will show that the spreadsheet is not viable as an alternative to MS 
Excel and the chance will be lost for years. Do you really want such 
well publicised trails to record the fact that using the spreadsheet 
DESTROYS USERS DATA.

See:

http://www.computerweekly.com/articles/article.asp?liArticleID=125960

*** Issue 19891 has been marked as a duplicate of this issue. ***

Hi,

Summary of issue 19891 describes the problem much better than the old
summary of this one, so I repace the old summary
"Paste and delete modify cells hidden by autofilter"
by
"Calc-Document with Filter; Cells not shown are modified
(multicellselection)"
(for details please see  Comments From Richard Trout 2003-11-03: _all_
filters and _all_ modifications are touched, not only "Auto Filter"
and "Paste / Delete")

Rainer

*** Issue 14541 has been marked as a duplicate of this issue. ***

*** Issue 14541 has been marked as a duplicate of this issue. ***

A related question is whether copy & paste of whole columns or rows should copy
the "hidden" state of manually hidden columns/rows (currently it doesn't).

nn, my comment of 2003-11-03 apply to selections of cells AND whole columns AND
whole rows equally.

*** Issue 24451 has been marked as a duplicate of this issue. ***

*** Issue 24472 has been marked as a duplicate of this issue. ***

*** Issue 26877 has been marked as a duplicate of this issue. ***

Will this also fix SUM to automatically use SUBTOTAL?

On MS Excel, filter a sheet by a code. 
Press SUM icon for a column, the formula used will be SUBTOTAL( 9; range ). Calc
will use the regular SUM, which gives the total for all sheet. 

Please use SUBTOTAL automatically when the sheet is filtered.

mandreiana I don't think this issue is intended to address your problem with the
sum toolbar icon for choosing sum/subtotal. You will need to check for other
issues or create one yourself.

*** Issue 27196 has been marked as a duplicate of this issue. ***

*** Issue 27385 has been marked as a duplicate of this issue. ***

dodgy filtering has blighted Open office for me for quite a while. I agree 
with the reporter. 
 
Furthermore, pasting copied filtered data subset OUTSIDE oo.org actually 
pastes the whole data set, not only the filtered data. 

FT: This issue is not for EA but for Beta, since it will require no Ui in its
first step.

Priority is wrong.  This is DEFINITELY a defect that will keep many of us from
recommending OOo (or StarOffice, for that matter) to anyone who needs an office
productivity suite.  Data loss through this kind of error will be regarded as
inexcusable by the PHBs.

Please change the priority to at least P2, Defect from P3, Enhancement.  Heck,
I'd prefer seeing it bumped up to P1.  The issue is that critical.

Thanks.

Me too. I think it's accademic whether it's a defect or a lack-of-a-feature. It
means lots of us won't recommend using Openoffice. I have recently advised
someone to buy M$ Excell for this very reason, and always save as excel when
sending a worksheet anywhere. 

It's REALLY holding the free office suite back and needs to be fixed, ideally
before 2005 when v2 is scheduled.

Over 2.5 years have gone by since I first reported this issue. In that time it
has cost me real money as I have had to buy MS Office for both my son and
daughter for their university PCs as I we felt the risk of data loss was too
great and could jeapordise their degree work. I have given up demanding this is
a defect which must be fixed and dont even have OOo installed on my new laptop.
I have also recommended to my customers they do not use OOo yet. 

If someone ever gets around to fixing this could they ensure that the default
option is to prevent data loss, and that ANY operation prevents such a data loss
including: paste, copying via dragging other cells, multi selecting and typing
etc. The simple rule should be the when autofilter is on, the operation should
only affect visible cells and no others. This is what both MS Excel, Lotus 1-2-3
do and is in my opinion intuitive.

I would be happy to test a dev version if someone wants me to, or answer direct
queries from the developer. You may even encourage me back to the OOo fold. In
the meantime I will live (begrudgingly) in MS Office land!

John

FT: Here's what we are evaluating for OO.o 2.0:

Whenever the user has a filtered range the following action will only apply to
the visible/filtered selection:
==============================
- Deleting the content of this selection
- Applying all available kinds of text formatting (font, font effects, font
position)
- Applying all available kinds of cell formatting (numbers, font, font effects,
alignment, borders, background, protection)
- Find & Replace will only be applied to the selection
- Paste from clipboard in case it fits to the target (content in clipboard is a
single cell)

What will not change:
====================
- Cut the selection (will always include "data in between")
- Paste from clipboard unless it fits to the target

I agree with the following comments:

I would suggest that clipboard paste should not affect any hidden cells. If the
number of rows/columns are more than the target it simply overwrites or creates
further rows or columns beyond the target. If the rows/columns are less, then
the visible data should be overwritten up to the no. of rows/columns and no more.

I hope this helps

John

FT: No, this is not an option:
In case theuser tries to paste more than one cell (content) into a filtered
range we will still overwrite hidden data.
Any other behaviour will lead to unpredictable results/comments from various users!
BTW,that's also theway Excel does hint.

FT: No, this is not an option:
In case theuser tries to paste more than one cell (content) into a filtered
range we will still overwrite hidden data.
Any other behaviour will lead to unpredictable results/comments from various users!
BTW, that's also the way Excel does it.

How is "fit to the target" in pasting limited to a single cell? There might well
be several consecutive rows visible after filtering.
Anyway, paste doesn't handle multiple selection, so it probably has to stay the
way it is for now.

"What will not change" is "everything else", of course, if we change individual
functions.

Another thing that might be considered is deleting rows.

How about showing a little warning message before such a multi-cell pasting eats
hidden cells?  That would be a friendly warning to the users IMHO since some
users may not expect their hidden cells simply get overwritten, even though
Excel does it that way.

Of course, such a dialog would contain a check box "Do not show this warning
next time...".

Kohei

Why not make it a configuration if we have to have it both ways ? That and the
warning suggested by kohei (the default would be to only paste visible cells)
would make it perfect !

May this be clarified please? "- Paste from clipboard in case it fits to the
target (content in clipboard is a single cell)" - i assume this includes the
case where the user grabs the corner of a cell and drags it down over the
filtered rows, so the single cell is pasted repeatedly onto the visible rows
only? This will be most welcome. But if the user grabs two adjacent cells in a
row and drags down then the behaviour is different? 

Also it might be helpful to explain, is the discussion only about the most
correct behaviour, or is there some problem with the implementation that
prevents some things that are agreed as desirable?  

If more than one adjacent cell is grabbed and dragged across filtered cells, I
would expect only the visible cells to be updated and not the hidden cells. I've
just checked and this is exactly what Excel does. Not only that, but if you drag
beyond the range of the filtered cells Excel "copies" the content into the
extended visible range, still with no change to the hidden cells.

John

Spec is written and can be found at
http://specs.openoffice.org/calc/ease-of-use/editing_of_non-filtered_selections.sxw

to Uwe: please review spec and approve
to Oliver: please review spec and approve and set up test plan
to Niklas: please review spec and approve and start implementation
to all: Thx!

IMHO this is an admirable effort to address the most critical issue - undetected
deletion of data. And I'm humbled to see my meagre contribution in the spec.

A question: will this job stay open for the paste-side issues, should a dupe'd
issue be re-opened, or should a new issue be opened (per spec section 7. Future
Tasks)?

*** Issue 33437 has been marked as a duplicate of this issue. ***

*** Issue 33436 has been marked as a duplicate of this issue. ***

This task will make it into OO.org 2.0, therefore set to FIXED
Note: Since not all of the requirement are making it into 2.0 I kindly request
all submitters of additional feature to issue new tasks on their requirements
with the target "OfficeLater"

Looks like we've got a good start toward fixing some of these issues.  I wonder
what will happen in 2.0 when a user tries to fill down through filtered rows by
dragging the corner of the cell as usual.....?  The document never really
addressed that. Will that be fixed too, or will it wipe out the hidden data as
it does now?

Created generic issue 33851 as a carry-on to this issue 2977 post-2.0, per ft's
request.

I recommend those interested in this issue to vote on issue 33851 and post their
own comments on required functionality.

*** Issue 35582 has been marked as a duplicate of this issue. ***

*** Issue 35583 has been marked as a duplicate of this issue. ***

Verified and therefore case closed.

*** Issue 43613 has been marked as a duplicate of this issue. ***

This very issue is not yet working in the latest snapshot build, 1.9.m113 as of
14 July 2005 Yet, this issue was closed in november 2004 ? 

This issue is not resolved in 1.9.113. Please reopen.
Add in one column numbers : 1, 2, 2, 6, 7, 7, 2, 9, 8, 3
Use AutoFilter, Standard and say Column A > 2
It will hide rows 1, 2, 3 and 7.
Now paste 10 numbers (lets say 10 numbers of 11) over Filtered column.
Those pasted numbers will delete 7th number 2. Only the numbers that were first
on the Filtered list were not overwriten.

Do you need Calc document?

Overwriting of hidden cells during pasting is handled by #i33851#. Please do NOT
reopen this issue.

*** Issue 52165 has been marked as a duplicate of this issue. ***

*** Issue 52165 has been marked as a duplicate of this issue. ***

*** Issue 52165 has been marked as a duplicate of this issue. ***

*** Issue 54580 has been marked as a duplicate of this issue. ***

*** Issue 67087 has been marked as a duplicate of this issue. ***

I agree with those who think this is a severe DEFECT. 

I discover today this OO 'feature' pasting a single cell over a filtered range
and discovering I overwrited all the hidden cells between (hundred of cells). 
I checked other calc documents and found that many data have been corrupted in
this way.
I think this is an unfaithful behaviour because data are modified without user
perception of it and since cannot be accepted.

gianpi