The related content ticket (#2196) noted that a separate dev ticket should be created for the org model. That doesn't seem necessary; confirm during refinement.

This one raises a yellow warning flag. We have imported stable dbs into other sandboxes, which includes domain management. If this was added now, changing anything on those domain infos would notify real humans. We need a ticket before this to update documentation with deleting user domain roles after importing from stable (we can't just choose not to import that one table unfortunetly), then probably want to edit the test banner to show if email sending is turned on.

Also is this meant to block the design review of just the graphics? Could this be it's own milestone?

Hey @Katherine-Osos can you confirm two things: 1.) this will be released for non-org model users as well and 2.) If an analyst or superuser changes something, it will not result in an email.

@abroddrick Correct on both things! 1) Will apply to non-org (i.e. this ticket can be released before org model is launched) and 2) we should not send emails when the update is initiated via the admin.

cc: @h-m-f-t # 2 relates to the discussion we had this morning, so just tagging you for visibility.

Per refinement meeting, @abroddrick will create a dev ticket that will be scoped to preparation for this ticket.

@Katherine-Osos @abroddrick Three questions:

1. How do we want to handle interactions between multi-recipient emails (emails to more than one person) and the email whitelist? Like, if we have several domain managers, should we block sending the email if any of them are not-whitelisted, or just filter the addresses and only send to the whitelisted ones?
2. Do we want any kind of indication to the user if email sending fails? Perhaps usng the messages API like we do for success/failure of updates?
3. Do we want to CC extra domain managers, or just put them all in the to: section? Both will create valid emails. If the former, how should we select which emails to set as the to: address and the CC: address?

Great questions:

1. Don't block, just only email the whitelisted ones
2. We do currently have success/failure messages for domain info changes so up to @Katherine-Osos on if their content should change with the addition of emails. I do think at the very least we should mention on the page that emails will be sent to other domain managers for any changes.
3. I believe the intent here was to have no "To" recipient and just have them all CC'd. To address shouldn't be a required field and just cc should work. Some reference

@Matt-Spence For your second question ... no need to display error messaging if the email fails. It's simply a receipt and not the primary action.

That being said, to Alysia's point, let's add a bit of messaging about this update to the Domain Managers page.
I DM'd you the new text for that page.

Moving this ticket from sprint 54 to the current sprint (sprint 55). cc: @abroddrick @lizpearl

Moving this ticket from sprint 55 to the current sprint (sprint 56). cc: @abroddrick @lizpearl