71931 - Renaming usernames can cause problems while submitting bugs

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect, P4)

Description

[Matthew Tuck [:CodeMachine]]

The following sequence of events occurred:

(1) Andreas loaded a page with my address on it somewhere.
(2) Dawn renamed me from [e-mail] to [e-mail].
(3) Andreas submitted a comment on that bug.

He got told:

The name [e-mail] is not a valid username. Either you misspelled it, or
the person has not registered for a Bugzilla account.

This is a tricky problem, and it would probably also be a problem with all sorts
of renaming (keywords, products, components, etc.).

Possible solutions:

(1) Only send incremental changes.  However this would only work with Javascript
apparently.  Also, I doubt it would work with keywords because you might make an
alteration to one keyword and another already on the bug could be renamed.
(2) Keep old names on the server.  How long for?
(3) Make renames go through and mark the delta_ts of all relevant bugs so they
will midair.  But this could take a long while if there is a long list, and
there is always the chance it won't happen quick enough.  Bundling all this into
a transaction might work but I don't know whether it's supported by databases
and might lock up the database for too long.
(4) timeless suggested to send old and new versions of relevant data so the
server could see what had changed.
(5) hixie thinks the best solution is to keep hidden mappings of id->name on the
form so we can recognise the old names.  This seems to be the best solution,
although it makes me a little nervous about security.

Comment 1

[Matthew Tuck [:CodeMachine]]

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.

Comment 2

[Matthew Tuck [:CodeMachine]]

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.

Comment 3

[Matthew Tuck [:CodeMachine]]

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

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

I agree with Hixie here.  The best option really is to have the user ID number
in the <option value=""> attribute.  Of course we would have to change the
backend to update by user IDs as opposed to email addresses, but this would
easily fix this problem without having to do any javascript, or create any extra
tables.

If security is an issue with userids, then
http://bugzilla.mozilla.org/showvotes.cgi?bug_id=7710 and any other bug with
votes is a security issue as well because you can grab userids from there by
seeing where the links go.  Then you can just guess userids from there.  A
solution to this would be to use md5 hashes instead or something similar.

Comment 5

[Dave Miller [:justdave]]

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.

Comment 6

[Joel Peshkin]

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.

Comment 7

[timeless]

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.

Comment 8

[Max Kanat-Alexander]

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 [e-mail] 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.

Comment 9

[Frédéric Buclin]

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.