After some chat with the @team, we’re moving forward with this feature request cautiously together, and in phases.
Phase 1 won’t change anything but the architecture of how a user’s email address(es) are stored. No new features, just some well executed database migrations:
- Create a new
user_email table, with:
email column, unique with special handling to support case insensitivity (treating
BOB@ as the same)
- Migrate the
email column from the
user table into the new
email_id column to
user table, not null to enforce primary email as
The associations would therefore be:
belongs_to :email, class_name: 'UserEmail'
@sam this is a little different from what we discussed, but I think it makes migration even easier (keeping
user.email pointing to the primary email). Thoughts?
Phase 2 will involve adding server side handling of multiple email addresses. At this point this is less clearly defined, and still requires some discussion and planning. A feature almost certainly in this phase will be supporting email-in from alternative addresses.
Phase 3 is even less clearly defined than phase 2, and requires even more discussion and planning, but will focus on adding the UI and user flows to make all of the work done in phases 1&2 useful.
Coding will start on Monday, so I’ll update the topic then with the crucial parts of phase 1 I’ve forgotten to think through.