Summary: Renaming cause problems. → Renaming causes problems.
If we store all values on the server then we could also do something else - accept the old values in other situations as well, and present a warning to that user that the name has changed. The tricky bit is what if you want to rename something else to the original value, but I don't see anything else there that's too serious. Also, in BZ3 I'd like all renames to generate notifications for all affected bugs and to instead implement bulk change notification aggregation, so the delta_ts solution might be worth considering. One might make a point there should be no midair in this case, but I think it would be a decent way of letting the user know the user has been renamed.
Umm, above I didn't say it but I also meant that we should write something on bug_activity for all bugs when you rename a user. Back to the main issue, we could also rearchitect the page so the changes are incremental. As far as I can tell Add CC and Assignee are not problems - I think just QA and Remove CC are as they roundtrip values. Also let's not forget that whatever we do should work in a BZ3 world, for example with an email interface.
We could have a table called "renames" for use with all tables (users, keywords, etc.): table_id smallint not null, record_id mediumint not null, old_name mediumtext not null, expiry_date time(sp?) not null
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Summary: Renaming causes problems. → Renaming usernames can cause problems while submitting bugs
Version: Bugzilla 2.11 → 2.11
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
These unloved bugs have been sitting untouched since June 2002 or longer. If nobody does anything else to them, they certainly won't make 2.18 Retargetting to 2.20. If you really plan to push them right now, you might pull them back in.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
is this still a big problem? i know that if i rename my own account and then try to file a bug, bugzilla gets confused because my login has the old account name. but didn't switching from a long cc field to add/remove items make this problem mostly go away? in comment 0, was matty a CC or QA or assignee? i'm obviously presuming matty was a CC which is probably silly, since in all likelyhood matty was qa.
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 firstname.lastname@example.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 → ---
Comments 0 - 4 are a bit crazy and over complicated compared to what this bug is about. This is a very minor issue which is closer to wontfix than to all the complexity mentioned here. Bug 218917 isn't going to help in any way as you can still edit your username and fall into the same problem again.
No longer depends on: 218917
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.