Resolve "Add functionality to change what email address online actions commit using"
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.
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 theusers.commit_email
column is ran. Thus, a bunch of errors aboutcommit_email
orcommit_email_changed?
not being defined get raised. I've contemplated coding those methods explicitly or putting in a bunch ofrespond_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
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added -
Tests added for this feature/bug - Conforms to the code review guidelines
-
Has been reviewed by a Backend maintainer -
Has been reviewed by a Database specialist
-
-
Conforms to the merge request performance guidelines -
Conforms to the style guides -
If you have multiple commits, please combine them into a few logically organized commits by squashing them -
Internationalization required/considered -
For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan? -
End-to-end tests pass ( package-and-qa
manual pipeline job)