Red Hat Bugzilla – Bug 511022
flags reverted back to ? after changing bug from ASSIGNED to MODIFIED
Last modified: 2014-12-01 18:09:08 EST
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 ?
This is more common situation. I got occasional request to restore flags that got accidentally "reverted".
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.
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.
Some more background information:
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 :)
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.
Dave, this is not easily reproducible :-/ Has the change mentioned in comment #3 been ever tested out?
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
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.
Marking as duplicate ...
*** This bug has been marked as a duplicate of bug 475802 ***