This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 146883 - Fill Series behavior broken in Calc
Fill Series behavior broken in Calc
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Caolan McNamara
:
: 147252 171764 201740 307191 748452 748459 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-02 09:53 EST by mgm
Modified: 2011-10-24 10:16 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-01 03:01:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description mgm 2005-02-02 09:53:40 EST
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.
Comment 1 mgm 2005-02-02 09:59:08 EST
In description I said "1.1.3-2.5-fc4" above.  I meant -fc3.  Typo --
sorry...
Comment 2 Caolan McNamara 2005-02-02 10:34:52 EST
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
Comment 3 mgm 2005-02-02 11:08:34 EST
Workaround works and helps a lot!  Highlighting as described and using
Ctrl-D (shortcut for Edit->Fill-Down) works as well.  Thanks!
Comment 4 Scott Baker 2005-02-07 14:03:16 EST
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.
Comment 5 Gustavo Seabra 2005-02-15 09:11:09 EST
Just want to confirm that this bug is still around in version:
openoffice.org-1.1.3-6.1.3.kde
FC3 / KDE
Comment 6 Caolan McNamara 2005-02-16 08:05:06 EST
*** Bug 147252 has been marked as a duplicate of this bug. ***
Comment 7 Jan Slupski 2005-02-20 09:50:51 EST
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
Comment 8 Dan Williams 2005-02-20 10:48:23 EST
This will be fixed in the next release.
Comment 9 Eric Jones 2005-02-23 16:46:39 EST
This is also the case in Enterpries WS 4 with
openoffice.org-1.1.2-18.6.EL4.
Comment 10 Eric Jones 2005-02-23 16:50:52 EST
Should a duplicate bug be opened for Enterprise or will this thread be
passed along to the correct people?
Comment 11 Dan Williams 2005-03-07 00:54:55 EST
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
Comment 12 Alexander Appel 2005-03-11 18:35:24 EST
I just updated to 1.1.3-9.5.0.fc3 but as I can still reproduce the bug.
Comment 13 Gustavo Seabra 2005-03-12 09:48:29 EST
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?
Comment 14 mgm 2005-03-13 13:16:07 EST
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.?
Comment 15 Henry Ritzlmayr 2005-03-16 04:50:43 EST
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

Comment 16 Jacques Rodary 2005-03-16 07:54:33 EST
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).
Comment 17 Dan Williams 2005-03-16 10:16:41 EST
Jacques:  are you saying that 2.0beta from upstream fixes the bug, or that the
1.9.83 build in Rawhide fixes the problem?
Comment 18 Jacques Rodary 2005-03-16 11:11:43 EST
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.
Comment 19 Jacques Rodary 2005-03-16 16:32:09 EST
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 :-) 
Comment 20 Jacques Rodary 2005-03-16 20:36:37 EST
But 1.9.84 database doesn't work, as it seems (of course this has nothing to do
with this bug).
Comment 21 Caolan McNamara 2005-03-18 05:29:05 EST
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.
Comment 22 Gustavo Seabra 2005-03-18 11:00:52 EST
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?
Comment 23 Jacques Rodary 2005-03-18 11:35:42 EST
Caolan: I don't understand: there isn't any dialog box with
openofficeorg-calc-1.9.79-1! 
Comment 24 mgm 2005-03-18 13:58:20 EST
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.
Comment 25 mgm 2005-03-18 14:14:40 EST
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?
Comment 26 Caolan McNamara 2005-03-21 04:02:24 EST
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.
Comment 27 Jacques Rodary 2005-03-21 07:36:15 EST
Clicking on the bottom *left* corner wouldn't do it? :-)
Comment 28 Gustavo Seabra 2005-03-21 11:50:54 EST
(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?)
Comment 29 Michael Jakob 2005-03-22 14:01:03 EST
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.)
Comment 30 mgm 2005-03-31 19:13:56 EST
Reopened.  Sorry, but I agree with comment #29.  Until the default is actually
the default, this is still a bug.  IP concerns or not...
Comment 31 Caolan McNamara 2005-04-01 03:01:35 EST
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.
Comment 32 Henry Ritzlmayr 2005-04-01 07:18:02 EST
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. 
Comment 33 Dan Williams 2005-04-01 09:37:39 EST
Bug 153084 filed for documentation update.
Comment 34 mgm 2005-04-01 09:51:51 EST
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
Comment 35 Dan Williams 2005-04-01 10:22:32 EST
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.
Comment 36 Jacques Rodary 2005-04-01 15:55:42 EST
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.
Comment 37 Gustavo Seabra 2005-04-07 12:55:05 EDT
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
Comment 38 Caolan McNamara 2005-10-26 03:31:05 EDT
*** Bug 171764 has been marked as a duplicate of this bug. ***
Comment 39 Caolan McNamara 2006-08-08 13:56:05 EDT
*** Bug 201740 has been marked as a duplicate of this bug. ***
Comment 40 Caolan McNamara 2007-10-02 05:43:35 EDT
*** Bug 307191 has been marked as a duplicate of this bug. ***
Comment 41 Caolan McNamara 2011-10-24 10:16:31 EDT
*** Bug 748459 has been marked as a duplicate of this bug. ***
Comment 42 Caolan McNamara 2011-10-24 10:16:54 EDT
*** Bug 748452 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.