1963773 - Allow login_name to be changed to any unique string and not be tied to the email address

Status: NEW

(Bugzilla :: User Accounts, enhancement)

Description

[Dave Miller [:justdave]]

Allow login names to not be tied to email addresses

This is bug 218917 except for Harmony.

See also https://docs.google.com/document/d/1nE-eeRn3oAk8_8DxwMGNhyNreA0Gmn_srqVBiXfEcJE/edit?usp=drivesdk

Comment 1

[Dave Miller [:justdave]]

Attachment: GitHub Pull Request

Comment 2

[topunix]

I am assigned to this and have PR #147 open against bugzilla/harmony (https://github.com/bugzilla/harmony/pull/147). The status should move from NEW to ASSIGNED to reflect that, but I do not have editbugs, so I am noting it here instead.

Comment 3

[topunix]

I am assigned to this and have PR #147 open against bugzilla/harmony (https://github.com/bugzilla/harmony/pull/147). The status should move from NEW to ASSIGNED to reflect that, but I do not have editbugs, so I am noting it here instead.

Comment 4

[Dave Miller [:justdave]]

(In reply to Dave Miller [:justdave] from comment #0)

See also https://docs.google.com/document/d/1nE-eeRn3oAk8_8DxwMGNhyNreA0Gmn_srqVBiXfEcJE/edit?usp=drivesdk

Here is the above document converted to Markdown to have in this bug so it doesn't depend on that Google Doc to continue to live:

Eliminating visible email addresses from Bugzilla

Feature Specification

References

• Partially implemented in Bugzilla 5.1 / 5.3 branch in bug 218917
• Incomplete portions outlined in bug 1372631
• Specification writeup for bug 1372631: BMO Editable Nicknames

Abstract for Bugzilla 6.0 port

One of the blockers for Bugzilla 6.0 is to be able to upgrade to it from older versions of Bugzilla. Bugzilla 6.0 (codenamed “Harmony”) is based on a fork of Bugzilla 4.2, which has had most of the newer features from mainline Bugzilla backported to it. One of the things which was never backported to it was the above-mentioned patches for Bug 218917, because Mozilla (owner of the 4.2 fork) did not like the way it was implemented. In truth, the current core developers don’t like it, either. However, we want people to be able to upgrade to Harmony-based releases from the 5.1 / 5.3 developer releases, which means we need to implement it the correct way and provide a migration path.

The implementation in the Bugzilla 5.1 / 5.3 branch (master) adds an email address column to the profiles table (in addition to the existing user_login field, which previously contained the email address, but now can contain any unique username), which allows a user to only have one email address, the main difference being that it’s no longer the same as your user login name. The decision of the core developers is that Bugzilla 6 should allow multiple email addresses on an account (just like similar services such as GitHub). This will require adding a table for email addresses and providing user preference tools for managing them, and migrating from the email address column if it exists, and from the user_login column if it doesn’t.

Feature Specification

• The user login name/username should no longer be required to be an email address. We should encourage it not to be.
  • Users should be able to change their username
  • We should probably have a cooldown timer before they can change it again, 60 days probably?
  • Perhaps keep track of whether their username was system-assigned during migration or user-chosen, and only let them change it if it was system-assigned, instead of allowing it forever with a cooldown.
• User profiles should have one or more email addresses, with the capability to have multiple.
  • Users should be able to add and remove email addresses from their account.
  • Each email address should have an option whether to send notifications to it or not (to allow the user to have multiple they can log in with, but only get notifications in one place, for example).
  • At least one email address is required. The user should not be allowed to remove the last-remaining address without adding a new one to replace it.
  • The existing feature to change your email address should be removed, in favor of adding a new address, then removing the old one.
  • Adding a new address should require verification via a token emailed to the address (the same mechanism currently used for creating an account or changing your email). The new address will not be usable until it is verified.
  • The email address should track its verification state, and the date it was last verified. (potentially we can require them to be reverified periodically, but that’s out of scope for the moment). Email addresses migrated from older versions should assume the addresses are already verified, and use an obviously fake verification date like January 1, 1950 or something along those lines. The UI can choose to interpret that specific date as a legacy verification in the way it gets displayed.
  • Removing an email address should also require verification via a token emailed to the address. This should provide both an accept and cancel mechanism. Rationale: Bugzilla is often used to store critical data. If someone does manage to gain access to the account, the original owner needs an opportunity to regain access prior to being locked out.
    • If the accept token is submitted, the address is removed immediately.
    • If the cancel token is submitted, the removal of the address is canceled.
    • If no token is submitted after 3 days, then the address is removed (this is the fallback for no longer having access to the account to approve it).
  • Requesting a password reset by email address should just send a confirmation token to that address. Requesting a password reset by username should send the confirmation token to all verified email addresses.
  • Completed password changes should send a notification that the password was changed to all verified email addresses.
• Places in Bugzilla that need to be updated to deal with the new mechanisms
  • BMO Editable Nicknames lists a bunch of these
• Migration from older versions
  • Bugzilla does not have a versioned schema. Instead, the migration scripts compare the existing state of the database to see whether a required change has been made or not. While this complicates things slightly, it also allows for clean upgrades from divergent schemas, which is exactly the situation here. Version 5.2 and prior will not have this feature implemented at all, and will need to migrate to it from scratch. Versions 5.1 & 5.3 have it partially implemented in an undesired way, and will need to be migrated from the old way to the new way.

Other notes

The line item "User profiles should have one or more email addresses, with the capability to have multiple." has been spun off into bug 2066984, and is not being landed as part of the PR on this bug.

Comment 5

[darkdragon]

What about fully removing the concept of a user login name/username in favor of a display name?

• user id: generated, this is used internally for all references
• user display name: this is how a user is presented to user users, can contain spaces, can't be used for login
• user emails: used only for login and notifications

The migration would become trivial:

1. Add entry in user emails table based on previous email (if exists email_address field in 5.x, otherwise user_login field in 4.x)
2. Rename user_login field to user_display (optional)

Everything else stays the same:

• If user_login was an email in 4.x, don't change anything. Optionally ask the user on login if display name contains an "@" character if they want to change it.
• If user_login was a username in 5.x, just use it as display name.

Comment 6

[Dave Miller [:justdave]]

(In reply to darkdragon from comment #5)

• user id: generated, this is used internally for all references

We already do this. It's not shown to users at all but everything internally uses it.

• user display name: this is how a user is presented to user users, can contain spaces, can't be used for login

We already do this also. But it also isn't guaranteed to be unique.

• user emails: used only for login and notifications

And this is the primary change this patch is making, to do it exactly like this, because currently this is shown in the UI as the human-readable unique identifier, and we want to stop exposing emails.

And nobody wants to be a number, which is what the internal auto generated ID is.

Comment 7

[darkdragon]

We already do this also. But it also isn't guaranteed to be unique.

Why do you need a unique username? Isn't a non-unique display name in combination with unique id and emails sufficient?