Add management command to send api move announcement email

[sarayourfriend]

Fixes

Part of #3742 by @sarayourfriend (does not fix because the issue also requires sending the email, i.e., running the command in production).

Description

Review the management command. The message text has already undergone review. The placeholder for the make post URL will be replaced before merging, after the post is available next week.

Testing Instructions

Review the code and confirm tests are adequate and pass.

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.
• [N/A] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[sarayourfriend]

Upgrading this to high priority so that we can send it out early next week along with the make post on Monday. #2037 for context.

@WordPress/openverse-api pinging y'all for expedited review to match the priority.

[dhruvkb]

I was under the impression that we've sent bulk emails before and there was an existing management command to send out emails. I think I was wrong about that.

I think it's worth generalising this command to send any email, and keep the message as a separate file that can be passed to the command via CLI args. This way we can send emails in the future, with the same command and different content.

However, I'm okay with taking up this idea^ as a future improvement. This PR LGTM and I'm unblocking these except for some ideas to improve the message text.

[dhruvkb]

This line should be wrapped like the others.

[stacimc]

LGTM, tests are great. +1 to @dhruvkb's suggestions for the message text but approving to unblock.

I like the suggestion to make the command more general but strongly agree that should be a future iteration 👍

[sarayourfriend]

The issue references the old management command that we sent an email with before: #3742

A general one is out of scope, as you've both said, but I want to share further context, as I don't believe we even need one. We've sent two emails in as many years, and the first was extremely specialised in the selection of who received it. It's hard to imagine it would be worth the time to write, test, and maintain a generalised management command when this one can be copy/pasted (and crucially in the meantime deleted, and not kept as unused code for who knows how long) and whatever modifications made as needed. Without knowing who the audience of a particular email is, you'd also need to work out how to specify that, and I'd really rather not have to dredge up memories of dealing with CSVs of SQL-exported email addresses in Django admin.

[dhruvkb]

Agree on both points: generalising is out of scope for this PR and this code can be deleted when unused (at 2 emails in ~3 years this is basically 100% of the time).

[sarayourfriend]

Because application emails are not unique, there is a chance of accidentally emailing people twice, if their multiple applications registered to a single email are pulled; that is, there is a chance of this if the distinct() call on the queryset is not filtering in each query set slicing inside the loop. I need to check this. I'll do so by adding a new unit test first to determine whether this is the case, and if so, fix the distinct call or modify the loop to prevent it. I'll do that before merging this, of course, as well as addressing the editorial remarks from @dhruvkb.

@dhruvkb and @stacimc Just an FYI that I did ask for editorial reviews from everyone in the maintainer group before marking this PR ready for review; ideally these editorial remarks would have been shared there, as some of them overlap with content in the Make post. Just giving context for where the text came from, and the process it's already been through. I appreciate the editorial feedback, but it would have been good to have it when the text was originally discussed, so that it could align with the Make post.

[sarayourfriend]

The emails are sent as of 2024-05-08T00:59:58.366Z.