https://bugs.documentfoundation.org/show_bug.cgi?id=162417
--- Comment #21 from Robert Lacroix <[email protected]> --- > No global or compatibility option; definitely not. OK, not wanting to chase moving targets is a good basis for this stance. Too much confusion among users, not enough developers who understand this system or the other. I'm pretty easy-going, I could live with a per-PT option, for the sake of backward compatibility. It's a once-per-PT click. I don't churn out new PTs every day, I just work with the 50+ PTs I already have in that 45 sheet workbook. I *could* live with it as an option, but I will take the position that changing it is the right thing to do, and not only to lessen the aggravation of expanding PTs. > First, Excel might change its (default) behavior (in some version or in the > rolling 365 target). That's an unfounded proposition since it affects computational results when PTs are refreshed, and changing computations capriciously in Excel is an extremely remote possibility. It's more likely for the user interface to change. There is a deep history that will enrage a lot of monied enterprise users if a snot-nosed kid at MS changes the way Excel's pivot tables work. You may not realize that Excel is the grand-daddy which outlived its peers. It existed in the late 1980s, when I first used it on a Mac SE, years before Windows made its debut. That's a long time with a lot of users to make sure that MS got this functionality right. By the same token, it's unlikely that the default (proposed PT option) will flip in LO-Calc some day in the future - there has to be a very good reason to change it - and mere compatibility with Excel isn't it. I argue that Excel's current way is the better way, since LO-Calc changes PT results capriciously with new unrelated source data rows, as demonstrated in comment 13. If Excel ever changes the way PT's work, and LO-Calc preserves the current Excel behaviour, then score one for LO-Calc! I'm not a proponent of compatibility when functionality is at stake. > Second, and more important, the same user might need one behavior for one > workbook but the other behavior for another workbook, depending on layouts > and use-cases. Someone might even think that this could be different in > different worksheets of the same workbook, or even a different behavior for > different PTs on the same workbook. And there you have it; the option (if > implemented) is for each PT, not global. So backward compatibility for the current user base is your paramount consideration, and it is possible that some use case depends on it. (Thowing down the gauntlet) I challenge anyone to produce a use case that works better the way LO-Calc does it now, than the way Excel does it. -- You are receiving this mail because: You are the assignee for the bug.
