Bug 146883
| Summary: | Fill Series behavior broken in Calc | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mgm <missile-29> |
| Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | danpeig, dcbw, fedora, gauthier.ancelin, gustavo.seabra, janez.kosmrlj, j-fro, jrodary, jslupski, marco, mmesser, scott, volker, zing |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-04-01 08:01:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
In description I said "1.1.3-2.5-fc4" above. I meant -fc3. Typo -- sorry... As a temporary workaround, rather than dragging down the fill, select the area you want to fill, including the top entry and use edit->fill->down Workaround works and helps a lot! Highlighting as described and using Ctrl-D (shortcut for Edit->Fill-Down) works as well. Thanks! It should also be noted that this applies to fields with simple numbers in them, not just formulas. If I have fields with "1" "2" "3" "4" "5" in them and I drag that series into the next row/column I also get the error reported above. This has really cut down the usability of OOCalc. Just want to confirm that this bug is still around in version: openoffice.org-1.1.3-6.1.3.kde FC3 / KDE *** Bug 147252 has been marked as a duplicate of this bug. *** Simple case: 1. put value 1 in A1 2. drag lower right corner down Effect: 1. "Insert" tooltip while dragging 2. "Fill Series" dialog opens after releasing mouse Expected effect: 1. Automatic fill of selected area with (1, 2, 3, 4, ...) sequence 2. Automatic fill with unchanged data (1, 1, 1, 1, ...) if holding Ctrl Bug sitll exist in openoffice.org-1.1.3-6.5.0.fc3 This will be fixed in the next release. This is also the case in Enterpries WS 4 with openoffice.org-1.1.2-18.6.EL4. Should a duplicate bug be opened for Enterprise or will this thread be passed along to the correct people? Fixed in: RHEL3: 1.1.2-22.2.2.EL3 RHEL4: 1.1.2-22.6.EL4 FC2: 1.1.3-9.4.0.fc3 FC3: 1.1.3-9.5.0.fc3 devel: 1.9.82-1 I just updated to 1.1.3-9.5.0.fc3 but as I can still reproduce the bug. I confirm Comment #12. This bug ISN'T fixed in 1.1.3-9.5.0.fc3. This is a SERIOUS BUG, and it's been around for months! Is it really that hard to solve? or is it just not getting the attention it deserves? Hmmm... I disagree... sortof. I just updated to 1.1.3-9.5.0.fc3 and when I try to drag to fill, I still get the Fill Series dialog box. Annoyingly, none of the radio buttons, including "default" is selected, so I have to make some choices. From what I can tell: Choosing "linear" works for filling linear integers, but will not work with formulas. Choosing "default" will work for fomulas, but will not work for integers (or at least it doesn't do what the feature used to do by DEFAULT, which is detect the existing pattern and extend it). So, I suppose the problem is "fixed" in that you can make it fill formulas, but it's still VERY poor. This feature used to be a quick and easy way to fill series down the sheet, and it knew what I wanted automatically without having to ask me. Now it's a complete hassle that has the potential to corrupt existing data in the sheet if the wrong settings are chosen in the dialog box. Why was it changed? I can't see that the new way adds anything. And if it has to pop up a dialog box, would it be so hard to have "default" actually be selected by DEFAULT, and have default work correctly for integers, etc.? I can confirm that upgrading to openoffice.org-1.1.3-9.5.0.fc3 doesn´t fix it. It also looks like to me that Bug 147257 is a duplicate of this bug. Since this bug has serverity high and 147257 normal mark 147257 as dup. https://bugzilla.redhat.com/beta/show_bug.cgi?id=147257 I confirm that 1.1.3-9.5.0.fc3 fixes bug 147257 which I reported, but doesn't fix this one (but 2.0beta does). Jacques: are you saying that 2.0beta from upstream fixes the bug, or that the 1.9.83 build in Rawhide fixes the problem? Sorry: Idon't understand what "from upstream" means. I downloaded OOo_2.0beta_LinuxIntel_install.tar.gz which contains openofficeorg*1.9.79-1 rpms. It is also fixed in 1.9.84-1 found in ftp://ftp.openoffice.org/developer/680_m84. (1.9.79-1 was found in ftp://ftp.openoffice.org/stable/2.0beta). Unfortunately both aren't fully localized and I am a kind of impatient :-) But 1.9.84 database doesn't work, as it seems (of course this has nothing to do with this bug). That's what we mean as upstream, i.e. from www.openoffice.org and not our rawhide 1.9.83 or 1.9.84 rpms from download.fedora.redhat.com or its mirrors. Now comment #14 is the current status of this on the versions of OOo available from us, and is the intended behaviour. So the fill series functionality is available from the dialog once you select the type of fill you want to do. Unfortunately that's the way its going to stay. These changes address intellectual property concerns that may cover the removed feature. Caolan, I beg your pardon. I don't think I understood your message (Comment #21) right - can you explain it a little better? Do you mean that the fill series in the *redhat* version of OOo Calc is behaving weird because of *proposital* changes made by redhat? So it is not working as it should *on purpose*??? How can "intelectual property concerns" justify that? Caolan: I don't understand: there isn't any dialog box with openofficeorg-calc-1.9.79-1! So, comment #14 is gonna be it, huh? That's bummer, because (as I said in comment #14) the current behavior, intended or not, really cuts down on the usefullness of this feature. Could someone please elaborate on the IP concerns? Also, though I don't love the dialog box, if it has to be there, is there any reason that the "default" radio button can't be selected by default when the box opens? And, is there a reason that "default" can't do the things that the feature used to do by default (so that it will give you what you want most of the time, with formulas and linear series of integers, etc.)? Or, have the dialog open with the most likely choice of radio button and values already selected/filled in. ("default" for formulas or whatever, "linear" with start and increment values filled in for an obvious series of integers, etc.). Certainly this is possible, and the code to detect what the user probably wants already exists, because that's what used to happen pre-dialog-box. One more thing... Though I haven't tried them, here people are saying that upstream versions (1.9.79-1, 1.9.84-1) from openoffice.org are fixed, do not show a dialog box, etc. Are these versions newer or older than what went into 1.1.3-9.5.0.fc3? So who has the IP concern, here? RedHat? Sun? OO? Who? Upstream is unaffected. Red Hat reviews and scrubs its code for intellectual property issues. Our approach has always been conservative, i.e., if there is any question, resolve the issue or remove the code. Red Hat recently implemented a number of changes in its distribution of OpenOffice to address such issues. These changes should not be construed as implying any immediate intellectual property problem; rather, they have been implemented to assure that no such immeidate problems arise. While implementing these changes in our own distribution of OpenOffice, we have also made them available to the OpenOffice project. Clicking on the bottom *left* corner wouldn't do it? :-) (In reply to comment #26) Caolan, I can understand redhat not wanting to deal with IP issues, and I respect that. However, that just explain how deliberately breaking an **open source** code can protect redhat from anything other than satisfied customers! OO.o is already open source so redistributing it as it is cannot be a IP violation. (or can it? how?) (Or is there more to it than what you mentioned in your comment? care to elaborate a little further on the specifics of this issue?) This is not acceptable: the way the program works does not match its documentation (see chapter "Auto Filling Cells"), so this is a bug by definition. Please reopen, and at the very least change the documentation accordingly. I also agree strongly with comment #24 that "Default" should be selected by default (otherwise, the name does not make any sense, and that would be yet another bug.) Reopened. Sorry, but I agree with comment #29. Until the default is actually the default, this is still a bug. IP concerns or not... You're only shooting the messenger reopening the bug. The "bug" can't be further addressed, (by me in the forseeable future at least), for reasons outside my control. Since it looks like we are somehow stuck here, my question is: Is there a diffrent solution to this problem. Ex. Can we add a version without this bug to fedora extras, if it is not possible to include it in the standard distr. Is this bug included with a patch or do you guys realy remove (change) the source - wich means do we have a possibilty to recompile the package without applying this patch so that this bug is not included? If there is no patch to this - can you at least provide one - so that every user can make its one choice to inlcude the bug or not. Maybe some of this has already been done - is somebody aware of a repository wich contains the rpms without the bug? I am not trying to start a flame here by using the term bug all the time. For me it is a bug because it bugs me (and others) - and since this has been changed, serveral things dont match anymore. If there would be a good explenation what exactly this IP concerns are this would be a lot easier - anyhow - I really dont care if we find a solution here - if I find one some where else. I also use other rpms from other repos - if this means I will have to use OO-rpms from another source - it is ok for me. Bug 153084 filed for documentation update. Sorry, Caolan... wasn't trying to shoot anybody (messenger or otherwise). Nor do I mean to complain about software that I get essentially for free. Understanding that it's out of your control, I agree with comment #32 about finding a solution outside of the official FC releases. That said, is there a clean way for those of us who want to "risk" the IP issue to use OO-rpms from another source that will be keeping this feature the way we liked it, or will the upstream code be converting to dialog-box version of this feature, too? I guess we never really got straight who had the IP concern in the first place. If it's Redhat, then perhaps OO will be keeping the "old" version of the fill series feature, and Redhat will continue to patch each upstream release to provide the -FC release. Please elaborate on how this will work going forward. If indeed the upstream source will continue to work the "old" way, what's the cleanest way to have yum use another repo for OO? (I use rpms from other repos, so I know how to do that, but if I add a new repo that provides OO, how do I get yum to differentiate when both repos offer the same package? I'm thinking that the name of the package (i.e. a package that doesn't have -FC3 in the name) will be how it knows, but please correct me if that's not right. Thanks for your efforts on this. We really do appreciate your work, even if we do complain from time to time... --mgm mgm: all we can say is the following. We can't elaborate any more on the issue other than what is below: ---------------- Red Hat reviews and scrubs its code for intellectual property issues. Our approach has always been conservative, i.e., if there is any question, resolve the issue or remove the code. Red Hat recently implemented a number of changes in its distribution of OpenOffice to address such issues. These changes should not be construed as implying any immediate intellectual property problem; rather, they have been implemented to assure that no such immeidate problems arise. While implementing these changes in our own distribution of OpenOffice, we have also made them available to the OpenOffice project. ---------------- How upstream chooses to use the changes, if at all, is up to them. Anyone is free to roll their own RPM packages from whatever source, and create a yum repo for them. Dag does it, ATrpms does it, etc. As long as you follow the license that each package is distributed under, you are free to distribute your own versions to anybody you wish. Yum is fairly well understood and there are pages around that tell you how to create a repo. Its quite easy. Sorry if I disturb anyone. But there is no bug with openoffice.org-1.1.2-11.5.fc3, always availilable on some mirrors, (e.g. quicknet.nl), nor with openofficeorg-1.9.79-1. For anyone interested... This nug (and for me it still a bug!) does *not* appear in the 1.1.4 version of OpenOffice available from kde-redhat-testing repos. :-D *** Bug 171764 has been marked as a duplicate of this bug. *** *** Bug 201740 has been marked as a duplicate of this bug. *** *** Bug 307191 has been marked as a duplicate of this bug. *** *** Bug 748459 has been marked as a duplicate of this bug. *** *** Bug 748452 has been marked as a duplicate of this bug. *** |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: After upgrade to 1.1.3-2.5-fc4 using yum, the Fill Series feature in Calc does not work with formulas. I routinely continue a column with a formula (running total column in checkbook, for example) by highlighting one or two cells in the formula column and then dragging the box down into blank cells (or across if continuing rows). The default behavior used to continue the formula into the new cells, or if the original cells had an obvious series, it would continue the series. Behavior after upgrading to 1.1.3-2.5-fc3 is that it will open a Fill Series dialog. However, this dialog either results in a "invalid value" error or replaces the formula with a value rather than continuing the formula. Version-Release number of selected component (if applicable): openoffice.org-1.1.3-2.5.fc3 How reproducible: Always Steps to Reproduce: 1. Open new spreadsheet 2. Enter a few cells of data in a column (ex: A1=1, A2=2, A3=3, A4=4...) 3. Enter a formula using this data in one or two cells of the next column ( ex: B1=A1*2, B2=A2*2 ) 4. Attempt to continue the formula in col B down to rows 3 and 4 by highlighting B1 and B2, releasing mouse button, then dragging the little box at the lower right corner of the highlighted area down the column. Actual Results: Opens Fill Series dialog box. The Fill Series dialog box cannot be made to continue the formula. The best it will do is suggest a series that duplicates the values themselves (in the simple example above where it increments by 2) but will not handle formulas at all. Expected Results: Older versions of openoffice, other spreadsheets, etc. will automagically continue the formula down the column as you drag. Or, if the original highlighted cells in the column contained an obvious series, it would continue the series automatically. It never even opened the above dialog. Additional info: Perhaps this is related to bug #146580 about insert/paste now shifting cells down. I discovered the paste/shift thing after Fill wouldn't work, and insert/fill/paste behavior in general seems to have changed with ths update. I called this a severe bug because, along with #146580, Calc is nearly unusable, and you can easily corrupt a complex spreadsheet if you do this operation a few times before you realize it is broken.