[Bug 162417] PIVOTTABLE: Warning does not show range when overwriting destination range contents

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #19 from Robert Lacroix <muxlab at hotmail.com> ---
(In reply to ady from comment #18)
> My impression is that the main issue presented in comment 0 is not the same
> as later (or more recent) comments (e.g. comment 17). Am I wrong?

No, you are correct. In probing this issue through our discussion, it is clear
the real issue I am having is the (my) unexpected expansion of multiple pivot
tables when some field values are unchecked in them. But there are so many
pivot tables dependent on the same source range, it is difficult to know which
ones will overwrite on expansion. So it is appropriate to keep this bug about
comment 0 and fork the rest into a new bug.

The title of this bug is akin to "place moisture sensors in the basement"
whereas the latter content is about "fix the leaking roof". They are related,
but the fixes are independent and we should have both.

> Attempting to sum up comment 17 (which may or may not be equivalent to
> comment 0, IIUC):
> 
> * When the PT is filtered and the filter is different than showing "All"
> items, then new data items should be added as hidden (not as shown, not
> "checked" in the filter of the PT) when the PT is refreshed (updated).
> 

Yes! This should be a new bug. Let this title remain about comment 0 since
there's still value in identifying which PT is wants to overwrite content for a
given popup warning (there are multiple warnings, but not as many as there are
PTs using the same source range).

> FWIW, I am not sure that every use-case or user would agree with such
> change. There may be other use-cases in which the current behavior would be
> better suited. In the PT's properties dialog, maybe there should be some
> option in the "Options" area or in the "Source and Destination" area, since
> there is already an "Add filter" option.

Agreed. This is what I was thinking about when proposing a "locked" property.
However it's clear that Excel does not use one. Users who are accustomed to the
way LO-Calc works now may prefer it, and users who are accustomed to Excel may
prefer it the other way. I am in the latter camp. So this would be better as a
global property or compatibility option. 

> I admit, I might be misunderstanding, in part, or all.

Indeed, confusion is warranted since it is I who has been less concise and
unfocussed. But you have grokked it completely now, it is 2 issues rolled into
one bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.