Add A/B testing for "From:" address

[totten]

Overview

Expands support for A/B testing.

ping @kurund

Before

• You may add an alternate "Subject" and/or "Design". This enables A/B testing. (By default, it copies your current subject/design.)

After

• You may add an alternate "From", "Subject", and/or "Design". This enables A/B testing. (By default, it copies your current subject/design.)

• The "New Mailing" screen starts with one "From" field:
  

• If you click "+", it adds another "From" field:
  

Comments

In my r-run, it does generate messages with the alternate "From" addresses. (This is expected, given that AbDemux anticipates variations on these fields. I added a bit more coverage in AbDemuxTest to show this.)

Here are a couple issues to review/consider before merging....

1. Select2 Widget:
   • The "From" widget was previously declared with select2 (crm-ui-select="{dropdownAutoWidth : true, allowClear: false}").
   • But I'm finding it hard to figure out markup which meets all these goals: (a) be simple/standard, (b) render with a reasonable width, (c) display the dropdown alongside the "+" button, and (d) use select2.
   • For the moment, I've got it using a standard <select>, which satisfies (a)+(b)+(c) but not (d).
   • Probably someone with more select2/css experience could make select2 work.
2. Reply-To Edge-Cases:
   • Each Mailing record has three related fields. Typical values look like this:

     {
      "from_name": "Albert Albertson",
      "from_email": "albert@example.org",
      "replyto_email": "\"Albert Albertson\" <albert@example.org>",
     }

   • This data-model is weird. The pre-existing web UI hides the weirdness in a couple ways. First, it simulates a single UI widget ("From") based on two API fields (from_name,from_email). Second, it may autofill replyto_email... but it depends on a configuration option (enableReplyTo aka replyTo):
     • If replyTo is enabled, then it displays "Reply-To" as a separate field (independent of "From").
     • If replyTo is disabled, then it quietly autofills replyto_email based on from_name/from_email.
   • This patch should preserve these behaviors, as long as the setting enableReplyTo remains static (which would be true in normal/day-to-day usage).
   • However, if you allow replyTo to get reconfigured, then existing data may get pulled into some funny edge-case. (Ex: Create a mailing; split the "From" values; save draft; change the setting; resume editing.) I have not tested these edges. Guess: Some would feel OK; others would feel wrong (esp when the variants defines 2x replyto_email values, but the UI wants to show one "Reply-To" widget);
   • I think there are a few options, but I'm not a big fan of any of them.
     • Leave be. It'll work in normal usage.
     • Add A/B support for the "Reply-To" field (for systems with enableReplyTo=true). More verbose code. Not a feature anyone particularly asked for. But probably the best functionality.
     • Move all responsibility for sync'ing replyto_email<=>from_name+from_email to a different layer. (Only sync when you submit.) Eventual code should still be concise. (But it feels a bit more risky -- I suspect there's some reason why it was put in its current spot.)
   • The lazy part of me likes the first option more. The maintainer part of me likes the second option more.

[totten]

• Well, I added support for A/B test of "Reply-To", which should make some of the edge-cases more agreeable. (Described in commit comment -- alas, a workflow with the opposite toggling would still have a quirk...)
• As with the "From:" field, it has the issue with <select> / select2 / width / wrapping. (This consideration is aggravated a bit more by the fact that... the default value of replyto_email on a new mailing doesn't actually appear in the list of email-address options. Presumably, we never noticed because select2 is more forgiving about that... Erg...)

[kurund]

@totten

Thanks, I will check and get back to you.

[totten]

Chatted a bit with Coleman about select2 widths and found an incantation for something workable. ✅

[kurund]

@totten

Tested the functionality and is working as expected. Thank you. Good to merge.