107306 - Smart midair collision handling with line-item overrides

Status: NEW

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

Description

[Dave Miller [:justdave]]

When a midair collision happens, instead of the current "all or nothing"
override that allows you to either completely start over, or override all
changes with yours, you should be allow to make line-item overrides on only the
items that changed.

For example, the table showing the changes the other person made should be
displayed with an additional column showing the value you attempted to change it
to (or what you had left on the form if you hadn't changed it and the other
person did), and the old value, they changed to, and you changed to columns
should all have radio buttons on each line.

Then you could override changes on specific items without the all-or-nothing. 
This would also require detecting what you tried to change, so that it could
also present the same options for items you changed and the other person didn't,
so that if something the other person did negates the need for something you
did, you can back out that line item.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

I agree, this is how it should be done, and mid-air collision for attachment
creation and editing should work the same way.

Comment 2

[Matthew Tuck [:CodeMachine]]

Whoever does this is my hero.  The checkboxes will fit in nicely with mass
change midairs (bug #89822).

Comment 3

[Dave Miller [:justdave]]

*** Bug 109550 has been marked as a duplicate of this bug. ***

Comment 4

[Dave Miller [:justdave]]

Alec made a lot of good comments on the bug I just duped of this one about
issues faced by people that might be viewing Bugzilla content offline then
trying to submit changes later (thus having a higher likelihood of causing a
midair) that are worth looking at when we're brainstorming on this.

Comment 5

[Alec Flett]

I also described two ways of fixing this problem - one with JS and one
without... we also need a non-interactive mode so that collisions cause mail to
be sent to the user

Comment 6

[Matthew Tuck [:CodeMachine]]

I don't think you should just have checkboxes on the columns that clashed. 
Mid-airs are as much about columns that didn't clash - you still might want to
avoid what you're doing in light of the changes even if there were no changes. 
I don't see a particular reason not to do it this way.

In other words I think there should be a line-item for each change that you
made.  This would hopefully include an item for removing your comment, and
possibly allowing you to specify an alternative comment.

Comment 7

[Alec Flett]

it seems like we're arguing for principle over usefulness. 90% of the time I get
a mid-air collsion, its just the addition of a comment (i.e. I haven't changed
any fields) - if we know the user hasn't changed any fields (we can determine
this using one of the two methods I outlined in bug 109550) then what's the
issue? so what if I add a little comment but some fields have changed? just tell
me that on the "Submitting changes" page - if the changes are a big deal to me,
I can go back and add new comments..but 99% of the time they are not.

For avantgo, I need a non-interactive way of submitting a form - what I'd like
ideally would be to get a bugmail about the conflict, so I can sync my palm, and
then get e-mail saying "woah there!"

Comment 8

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 9

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 10

[Shane H. W. Travis]

*** Bug 148895 has been marked as a duplicate of this bug. ***

Comment 11

[Dave Miller [:justdave]]

This obviously doesn't block bugs that are already fixed...

Comment 12

[Dave Miller [:justdave]]

And this is still a thorn in a lot of people's sides and long overdue on a fix.  Anyone interested in working on it?

Comment 13

[Dave Miller [:justdave]]

< Christopher> justdave: That bug (107306) could be resolved pretty easily (or the UX improved at least) by using ajax to alert a user that a bug's fields have changed since they loaded the page.
< Christopher> You could then provide a "See what's changed" button where changed fields are highlighted and if there are conflicts, resolve them before the page is submitted.

Comment 14

[Gervase Markham [:gerv]]

Is the idea that the page does an Ajax check every, say, 5 minutes for last_change_time (only), and puts a warning next to the Submit button if it's changed (and then stops checking)?

That's a nice idea, although I'd be slightly concerned about server load... there are a lot of open tabs out there.

Gerv

Comment 15

[Matt McHenry]

You could start doing that periodic check only after some field on the page has been altered.  That should significantly cut down on the additional server load, as most of those open tabs probably have no modifications to the bug.

Comment 16

[(no longer active)]

Most of the time you don't wait 5 minutes after changing a field before submitting your changes, right?  :-)

Really, I think what I would like to see is for Bugzilla to *stop* warning me about changes to the fields that I have not changed, let my changes override the changes to the same fields made by others, and provides a way to "undo" the changes.  This desire comes from my own anecdotal experience in using Bugzilla over the years.  I'm pretty sure I could count the number of times that Bugzilla mid-air collision detection actually detected some change which would have caused me to not make my new changes had I seen it before on one hand.