Skip to content

Resolve "Add functionality to change what email address online actions commit using"

Ghost User requested to merge (removed):23986-choose-commit-email into master

Solves #23986 (closed)

Allows the user to choose one of their linked emails to use as the "Commit email" on the User Settings / Profile page or to always use their primary email (the default setting). The "Commit email" is used for web-based commits made in GitLab on the user's behalf. Tested: new file, new directory, upload file, edit file, replace file, delete file, edits from the web IDE, and merging an MR. A "Commit email" badge is also displayed next to the chosen email on the User Settings / Emails page.

UserSettingsProfile UserSettingsEmails

Database migration output:

== 20180814153625 AddCommitEmailToUsers: migrating ============================
-- add_column(:users, :commit_email, :string)
   -> 0.0427s
== 20180814153625 AddCommitEmailToUsers: migrated (0.0428s) ===================

(EDIT: original issues I was having, have since been cleared up)

As I commented in the issue, I've been encountering NoMethodErrors that are breaking several specs and the pipeline. It seems like the updated User class (app/models/user.rb) with my changes is being used in some specs / migration tests before my new migration to add the users.commit_email column is ran. Thus, a bunch of errors about commit_email or commit_email_changed? not being defined get raised. I've contemplated coding those methods explicitly or putting in a bunch of respond_to? checks, but I'm sure there's a simple fix that I'm not seeing because of my outdated/insufficient knowledge of Rails.

/cc @nick.thomas

Database checklist

When adding migrations:

  • Updated db/schema.rb
  • Added a down method so the migration can be reverted
  • Added the output of the migration(s) to the MR body
  • Added tests for the migration in spec/migrations if necessary (e.g. when migrating data)

When adding or modifying queries to improve performance:

  • Included data that shows the performance improvement, preferably in the form of a benchmark
  • Included the output of EXPLAIN (ANALYZE, BUFFERS) of the relevant queries

When adding foreign keys to existing tables:

  • Included a migration to remove orphaned rows in the source table before adding the foreign key
  • Removed any instances of dependent: ... that may no longer be necessary

When adding tables:

  • Ordered columns based on the Ordering Table Columns guidelines
  • Added foreign keys to any columns pointing to data in other tables
  • Added indexes for fields that are used in statements such as WHERE, ORDER BY, GROUP BY, and JOINs

When removing columns, tables, indexes or other structures:

  • Removed these in a post-deployment migration
  • Made sure the application no longer uses (or ignores) these structures

General checklist

Edited by Nick Thomas

Merge request reports