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
BOB@as the same)
- Migrate the
usertable into the new
usertable, 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.