Open Bug 89822 Opened 20 years ago Updated 5 years ago
Changing multiple bugs fails to cause midair collisions
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 email@example.com 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).
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
You need to log in before you can comment on or make changes to this bug.