Last Comment Bug 89822 - Changing multiple bugs fails to cause midair collisions
: Changing multiple bugs fails to cause midair collisions
Status: NEW
:
Product: Bugzilla
Classification: Server Software
Component: Creating/Changing Bugs (show other bugs)
: 2.13
: All All
: P2 major with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: default-qa
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-07 23:37 PDT by Dave Miller [:justdave] (justdave@bugzilla.org)
Modified: 2016-03-26 17:09 PDT (History)
12 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Dave Miller [:justdave] (justdave@bugzilla.org) 2001-07-07 23:37:18 PDT
If you change several bugs at once, and someone makes changes to one of the bugs
you're changing after you loaded the change multiple form, but before you hit
Commit, it fails to cause a midair collision.  Matty and I just tested this on
landfill.
Comment 1 Matthew Tuck [:CodeMachine] 2001-07-08 00:27:47 PDT
There are a number of issues that need to be decided here.

Firstly, we need to decide whether all bugs are checked for midairs before any
changes are made, or all bugs are processed one at a time.  I'd prefer the
former, but it would mean the bugs would remain locked for longer, and we'd
probably need to redo the code more.

Secondly, UI.  Currently with single change it's logically a different page that
occurs upon collision.  What should happen with midairs?

If we check for midairs before making any changes, this is rather simple - we
either have a page of midairs or a page of changes.  If not, we will probably
put the midairs in between other processed bug messages if that's where they
would appear.

In any case, given that you might want to press ahead with some of the bugs but
not all, when midairs appear we should probably have a checkbox per midair and a
"Submit my changes to checked bugs anyway" button.
Comment 2 Asa Dotzler [:asa] 2001-09-26 14:11:07 PDT
unsetting version so that Bugzilla specific versions can be removed from the
Webtools Product. 
Comment 3 Jacob Steenhagen 2001-09-27 05:33:18 PDT
Oops... this was filed in Bonsai :)
Comment 4 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-11-17 18:21:07 PST
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Comment 5 Gervase Markham [:gerv] 2002-08-12 00:18:24 PDT
I'd say this is a feature, not a bug. 

If I want to set 100 bugs to be assigned to me, I don't really care if someone
else has assigned it to themselves 10 seconds before. He'll notice I've stolen
it, and we can fight it out.

Implementing this would make mass changes much more of a hassle to do for the user.

Gerv
Comment 6 Bradley Baetz (:bbaetz) 2002-08-12 05:03:47 PDT
Well, what if I do a mass-component change after you've changed the product
separatrely? We probably get half the changes and/or die half way through.

Large mass changes are quite rare, and if you have to go through an extra
confirmation screen, I don't see it as a problem. We just have to make sure that
we show the midair page for all changed bugs at once.
Comment 7 Simon Paquet [:sipaq] 2003-08-14 13:36:44 PDT
Not a mac classic issue
Comment 8 Joel Peshkin 2004-03-18 16:02:38 PST
Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.
Comment 9 Max Kanat-Alexander 2005-03-05 04:50:11 PST
This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.
Comment 10 Frédéric Buclin 2005-04-09 08:48:25 PDT
(In reply to comment #1)
> Firstly, we need to decide whether all bugs are checked for midairs before any
> changes are made, or all bugs are processed one at a time.  I'd prefer the
> former, but it would mean the bugs would remain locked for longer, and we'd
> probably need to redo the code more.

Locking tables for such a long time sounds bad to me. I prefer to process one
bug at a time.


> If we check for midairs before making any changes, this is rather simple - we
> either have a page of midairs or a page of changes.

That means you could stop the *whole* process because of a *single* bug which
has been changed since you loaded the page. And this page would mention, for
instance, that bug 123465 has been changed by another user and would offer you
to submit anyway. As you took some time to read the comment and to click the
"Submit anyway" button, you did not notice that during this time some other bugs
got changed by some users and you now changed several other bugs, thinking you
were changing only one.


> put the midairs in between other processed bug messages if that's where they
> would appear.

Yeah, I like this idea, really. And at the bottom of the page, a quick summary
such as "374 bugs successfully changed, 15 midair collisions (force changes for
all bugs | show these bugs as buglist and throw my changes away)."


> In any case, given that you might want to press ahead with some of the bugs but
> not all, when midairs appear we should probably have a checkbox per midair and a
> "Submit my changes to checked bugs anyway" button.
> 

I like that too. All these checkboxes could be grouped near the summary I
suggested above.

Is that a solution justdave and myk would approve? (justdave and I discussed
about this in IRC today but we did not agree on the right solution to adopt).
Comment 11 Frédéric Buclin 2010-10-25 06:39:26 PDT
Could we get some traction on this bug? Personally, I agree with gerv in comment 5 that this is not necessarily a bug. You don't want to block your changes due to some bugs only.

What we could do is to proceed bugs which don't have midair collisions, and leave the other bugs unmodified, and redisplay the buglist with these unmodified bugs only, and a message of the form "Changes to the bugs below haven't been committed, because someone else edited them meanwhile. You can view them individually to see what changed, or confirm your changes by clicking the 'Yes, commit changes' button at the bottom of the buglist."
Comment 12 Max Kanat-Alexander 2010-10-26 13:54:02 PDT
Hmm, or maybe a "warn me about midair collisions" checkbox on the edit-multiple page that can be unchecked? I think that might be the simplest solution.

With our current architecture, we can check for midairs on every bug before updating any bug, so it probably wouldn't even be that hard.
Comment 14 Jerry Shaw 2015-02-12 02:07:21 PST Comment hidden (spam)
Comment 15 mail 2015-02-12 02:42:48 PST
(In reply to Jerry Shaw from comment #14)
> The java script running bug is messing me up specially when I try to launch
> my website 

Hi Jerry,

This comment is not related at all with this bug. Assuming you use Firefox please visit https://support.mozilla.org/en-US/ for support options.
Comment 16 Jerry Shaw 2015-02-12 03:05:22 PST
Oh, Sorry for wrong posting... My apology

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