Open Bug 89822 Opened 23 years ago Updated 8 years ago

Changing multiple bugs fails to cause midair collisions

Categories

(Bugzilla :: Creating/Changing Bugs, defect, P2)

2.13

Tracking

()

People

(Reporter: justdave, Unassigned)

Details

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.
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.
unsetting version so that Bugzilla specific versions can be removed from the
Webtools Product. 
Version: Bugzilla 2.13 → other
Assignee: tara → myk
Component: Bonsai → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.13
Oops... this was filed in Bonsai :)
Severity: normal → major
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.16
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
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
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.
Not a mac classic issue
OS: Mac System 8.5 → All
Hardware: Macintosh → All
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.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → ---
(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).
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → create-and-change
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."
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.
(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.
Oh, Sorry for wrong posting... My apology
Flags: needinfo?(andres.micheal77)
Flags: needinfo?(andres.micheal77)
Flags: needinfo?(sadavis)
Flags: needinfo?(sadavis)
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.