Changing multiple bugs fails to cause midair collisions

NEW
Unassigned

Status

()

Bugzilla
Creating/Changing Bugs
P2
major
16 years ago
a year ago

People

(Reporter: justdave, Unassigned)

Tracking

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.

Comment 2

16 years ago
unsetting version so that Bugzilla specific versions can be removed from the
Webtools Product. 
Version: Bugzilla 2.13 → other

Updated

16 years ago
Assignee: tara → myk
Component: Bonsai → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.13

Comment 3

16 years ago
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.

Comment 7

14 years ago
Not a mac classic issue
OS: Mac System 8.5 → All
Hardware: Macintosh → All

Comment 8

13 years ago
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

Comment 9

12 years ago
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 → ---

Comment 10

12 years ago
(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).

Updated

11 years ago
QA Contact: mattyt-bugzilla → default-qa

Updated

11 years ago
Assignee: myk → create-and-change

Comment 11

7 years ago
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

7 years ago
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 hidden (spam)

Comment 15

2 years ago
(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

2 years ago
Oh, Sorry for wrong posting... My apology

Updated

2 years ago
Flags: needinfo?(andres.micheal77)

Updated

2 years ago
Flags: needinfo?(andres.micheal77)

Updated

2 years ago
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.