feat: send group membership invite and remove emails

[katrinan029]

Add tasks for group membership invites and removal. The reminder emails will be done in enterprise-access

Braze templates:

• Invite template: https://dashboard-06.braze.com/engagement/templates_and_media/email_templates/5f91cb46d21d703936aaeb15?id=66034c520fdc83004bdbe739&locale=en
• Remove template: https://dashboard-06.braze.com/engagement/templates_and_media/email_templates/5f91cb46d21d703936aaeb15?id=66103a3e4e9b59004a5af86b&locale=en

https://2u-internal.atlassian.net/browse/ENT-8504

Merge checklist:

• Any new requirements are in the right place (do not manually modify the requirements/*.txt files)
  • base.in if needed in production but edx-platform doesn't install it
  • test-master.in if edx-platform pins it, with a matching version
  • make upgrade && make requirements have been run to regenerate requirements
• make static has been run to update webpack bundling if any static content was updated
• ./manage.py makemigrations has been run
  • Checkout the Database Migration Confluence page for helpful tips on creating migrations.
  • Note: This must be run if you modified any models.
    • It may or may not make a migration depending on exactly what you modified, but it should still be run.
  • This should be run from either a venv with all the lms/edx-enterprise requirements installed or if you checked out edx-enterprise into the src directory used by lms, you can run this command through an lms shell.
    • It would be ./manage.py lms makemigrations in the shell.
• Version bumped
• Changelog record added
• Translations updated (see docs/internationalization.rst but also this isn't blocking for merge atm)

Post merge:

• Tag pushed and a new version released
  • Note: Assets will be added automatically. You just need to provide a tag (should match your version number) and title and description.
• After versioned build finishes in GitHub Actions, verify version has been pushed to PyPI
  • Each step in the release build has a condition flag that checks if the rest of the steps are done and if so will deploy to PyPi.
    (so basically once your build finishes, after maybe a minute you should see the new version in PyPi automatically (on refresh))
• PR created in edx-platform to upgrade dependencies (including edx-enterprise)
  • This must be done after the version is visible in PyPi as make upgrade in edx-platform will look for the latest version in PyPi.
  • Note: the edx-enterprise constraint in edx-platform must also be bumped to the latest version in PyPi.

[alex-sheehan-edx]

Generally, the right direction. I think we need to think about which membership records we're pulling from the DB and we can simplify down some of the resulting logic given we have access to the pending learner record

[alex-sheehan-edx]

Looks great so far- one comment on filtering for only pending learners in group and unit tests but otherwise on the right track 👍

[alex-sheehan-edx]

Some thoughts!

[kiram15]

Looks great!

[iloveagent57]

This is looking good, couple small suggestions for simplicity and performance improvements.

[kiram15]

This seems like a red flag to me based on all the problems Alex has with filtering and querying the User table and it taking so long. I would look into this PR and see what he's doing with the SQL string https://github.com/openedx/edx-enterprise/pull/2057/files#diff-d950991245f878f58adc157895d6431af4385d522ab994aa25726e9abc2b434dR4274

[kiram15]

Though he was doing email__icontains and not email__in which would be faster but maybe it should be something more like the _get_filtered_ecu_ids

[alex-sheehan-edx]

so I did a little poking around - grabbed the sql query from the queryset and ran it against prod

mysql> SELECT auth_user.id,
    ->        auth_user.password,
    ->        auth_user.last_login,
    ->        auth_user.is_superuser,
    ->        auth_user.username,
    ->        auth_user.first_name,
    ->        auth_user.last_name,
    ->        auth_user.email,
    ->        auth_user.is_staff,
    ->        auth_user.is_active,
    ->        auth_user.date_joined
    -> FROM   auth_user
    -> WHERE  auth_user.email IN ( "[email protected]", "[email protected]" );
+----------+--------------------------------------------------------------------------------+----------------------------+--------------+----------+------------+-----------+-------------------+----------+-----------+---------------------+
| id       | password                                                                       | last_login                 | is_superuser | username | first_name | last_name | email             | is_staff | is_active | date_joined         |
+----------+--------------------------------------------------------------------------------+----------------------------+--------------+----------+------------+-----------+-------------------+----------+-----------+---------------------+
| 40294834 | pbkdf2_sha256$150000$x6piOQTpY9TT$bgr29MbJEahwaqOEXfAoqpFPYndM4v29SSoQYZCVYPU= | 2021-03-11 06:05:35.793195 |            0 | ---2     |            |           | [email protected] |        0 |         0 | 2021-03-11 06:05:35 |
+----------+--------------------------------------------------------------------------------+----------------------------+--------------+----------+------------+-----------+-------------------+----------+-----------+---------------------+
1 row in set (0.00 sec)

I thiiink this shows it's running in a reasonable time but we should def test once it goes out

[alex-sheehan-edx]

Some thoughts - let me know if you want to discuss

[alex-sheehan-edx]

so I did a little poking around - grabbed the sql query from the queryset and ran it against prod

mysql> SELECT auth_user.id,
    ->        auth_user.password,
    ->        auth_user.last_login,
    ->        auth_user.is_superuser,
    ->        auth_user.username,
    ->        auth_user.first_name,
    ->        auth_user.last_name,
    ->        auth_user.email,
    ->        auth_user.is_staff,
    ->        auth_user.is_active,
    ->        auth_user.date_joined
    -> FROM   auth_user
    -> WHERE  auth_user.email IN ( "[email protected]", "[email protected]" );
+----------+--------------------------------------------------------------------------------+----------------------------+--------------+----------+------------+-----------+-------------------+----------+-----------+---------------------+
| id       | password                                                                       | last_login                 | is_superuser | username | first_name | last_name | email             | is_staff | is_active | date_joined         |
+----------+--------------------------------------------------------------------------------+----------------------------+--------------+----------+------------+-----------+-------------------+----------+-----------+---------------------+
| 40294834 | pbkdf2_sha256$150000$x6piOQTpY9TT$bgr29MbJEahwaqOEXfAoqpFPYndM4v29SSoQYZCVYPU= | 2021-03-11 06:05:35.793195 |            0 | ---2     |            |           | [email protected] |        0 |         0 | 2021-03-11 06:05:35 |
+----------+--------------------------------------------------------------------------------+----------------------------+--------------+----------+------------+-----------+-------------------+----------+-----------+---------------------+
1 row in set (0.00 sec)

I thiiink this shows it's running in a reasonable time but we should def test once it goes out

[alex-sheehan-edx]

Just a few small nits/changes but otherwise looks good to me!