Bug 511022 - flags reverted back to ? after changing bug from ASSIGNED to MODIFIED
flags reverted back to ? after changing bug from ASSIGNED to MODIFIED
Status: CLOSED DUPLICATE of bug 475802
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
All Linux
high Severity high (vote)
: ---
: ---
Assigned To: Kevin Baker
Depends On:
  Show dependency treegraph
Reported: 2009-07-13 06:39 EDT by Dan Horák
Modified: 2014-12-01 18:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-08-24 16:48:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Horák 2009-07-13 06:39:39 EDT
I got flags reverted from + back to ? after changing bug #510032 from ASSIGNED to MODIFIED.

My view of events:
- view bug #510032
- asked lsmid for exception/pm_ack/rhel-5.4 flags on IRC
- notified about their changes to +
- refreshed bug #510032 in browser, could see comment #9 and all flags in "+"
- changed state from ASSIGNED to MODIFIED, commit changes
- no info about conflict, but flags back to ?
Comment 1 Ludek Smid 2009-07-29 10:56:41 EDT
This is more common situation. I got occasional request to restore flags that got accidentally "reverted".
Comment 2 David Kovalsky 2009-07-29 10:58:39 EDT
Raising the priority as this happened again with bug 471385. 

This can lead to schedule slips, since if the flags are reset very late in the process this can block commits / errata from respinning, thus QE from testing.
Comment 3 David Lawrence 2009-07-30 00:42:41 EDT
I apologize that you are encountering this issue as it has had me pulling out my hair for quite some time. It seems due to a quirk with firefox not properly refreshing certain form fields when reloading a page. Shift-reload works better but not everyone remembers to do that each time. 

There is a hidden form field called 'delta_ts' that contains the timestamp of the last time a bug was changed. When a user submits a change to a bug that has been changed since the last time the user loaded the bug, it will compare the delta_ts value to what is in the database. If they do not match then it throws the midair collision screen. If they match it allows the new changes to proceed.

It seems that under certain conditions, reloading the bug page, sets the delta_ts to the new value, but leaves the flag values alone. I have only reproduced this myself a few times but I cannot consistently reproduce it.

One thing I am going to try for a while to see if it helps is to set autocomplete=off in the HTML which will cause FF to not cache/prefill any form fields on reload. Hopefully this will not upset many people and will bring us closer to fixing this issue.

Comment 5 David Kovalsky 2009-08-03 09:28:11 EDT
Thanks for looking into this Dave!

I can confirm that this is not constantly reproducible. Though I deal with BZ and ACKing on a daily basis I've only been bitten by this 2 times so far. According to Murphy's Law it was always during a time were in a hurry :)
Comment 6 David Lawrence 2010-01-15 11:55:33 EST
Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and
therefore this bug will need to be re-verified against the new release. With
the updated code this bug may no longer be relevant or may have been fixed in
the new code. Updating bug version to 3.4.
Comment 7 David Kovalsky 2010-01-18 09:40:11 EST
Dave, this is not easily reproducible :-/ Has the change mentioned in comment #3 been ever tested out?
Comment 8 David Lawrence 2010-08-25 17:43:43 EDT
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Bugzilla Development Team
Comment 9 David Kovalsky 2010-08-26 09:05:46 EDT
I don't do any bug acking, so I'm not sure if this is still valid. 

Code review would be the way to figure this one out, but I'm not familiar with BZ code.
Comment 11 Ondrej Vasik 2011-08-24 16:48:10 EDT
Marking as duplicate ...

*** This bug has been marked as a duplicate of bug 475802 ***

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