feat: send email students course

[johnvente]

Description

This feature will allow sending emails to the expected email addresses of individuals in the course.

This pr depends on this one: openedx/edx-platform#33463

DEMO

Why are we doing this?

Sometimes, instructors would like to send emails to specific individuals in the course, rather than sending them to the options that are currently available. With this change, it would be easier to do so. The instructor would be able to select any option as well, including "Myself", "Staff/Administrators", "Learners in the verified certificate track" except for "All Learners"

---

How to test it

If you are using devstack

1. Go to workspace and clone this branch

cd ~/workspace && git clone -b jv/feat-send-email-students-course git@github.com:eduNEXT/frontend-app-communications.git

2. Go to the mfe repository, use node version in the repo and install dependencies

cd ~/workspace/frontend-app-communications && nvm use && npm install

3. inside frontend-app-communications run

npm run start

4. Go to http://localhost:1984/courses/course-v1:edX+DemoX+Demo_Course/bulk_email Or
http://localhost:1984/courses/{{id_course}}/bulk_email

[openedx-webhooks]

Thanks for the pull request, @johnvente! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[codecov]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (c0dc0cb) 83.06% compared to head (b6e74c8) 83.33%.

Files	Patch %	Lines
.../bulk-email-tool/bulk-email-form/BulkEmailForm.jsx	80.95%	4 Missing ⚠️
...l-form/bulk-email-recipient/BulkEmailRecipient.jsx	33.33%	2 Missing ⚠️
...ulk-email-recipient/components/EmailList/index.jsx	94.11%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #157      +/-   ##
==========================================
+ Coverage   83.06%   83.33%   +0.26%     
==========================================
  Files          46       48       +2     
  Lines         685      744      +59     
  Branches      132      144      +12     
==========================================
+ Hits          569      620      +51     
- Misses        116      124       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mphilbrick211]

Hi @openedx/2u-aperture! Would someone be able to please review/merge for us? Thanks!

[hurtstotouchfire]

@mphilbrick211 This repo should have a community maintainer. I defer to the maintainers on whether they have any agreements with the internal owners on the 2U side, but it should be going through the community maintainers first.

[arbrandes]

For the record, I think the PR to edx-platform should be reviewed/merged before we get to this one.

[felipemontoya]

@arbrandes one idea that I have been going around in my head would be to convert this PR to an extension mechanism like tue UISlot that braded proposed at the summit. We would create an extendable Slot where the checkboxes/filters are and we would do the email type box there.

Would you review/approve such architecture for this Adolfo? I would not like to go back from this and later not find anyone that could help us review the refactor. I'm asking you as the temp maintainer of this repo.

[arbrandes]

@felipemontoya, in principle, yes, I'd be happy to review the introduction of an extension mechanism here! I'm just unsure if this particular use case is a good candidate for a plugin: the backend changes that go with it are pretty tightly nit with the rest of the code.

If, however, the bulk email backend can be made pluggable - maybe via hooks? - then it would make more sense to make the frontend pluggable as well.

[felipemontoya]

Yes, that is exactly what we are thinking. We would move the platform PR to a plugin and the front end PR as well. But the extension mechanism needs to first exist in this repo.

[arbrandes]

@felipemontoya

the extension mechanism needs to first exist in this repo

Deal! 🤝

[mphilbrick211]

Hi @arbrandes and @johnvente! Just checking in on this one.

[arbrandes]

@mphilbrick211, I suspect this one will be refactored based on the outcome on the plugin slot implementation:

#184

[mphilbrick211]

@mphilbrick211, I suspect this one will be refactored based on the outcome on the plugin slot implementation:

#184

Any updates, @arbrandes?

[felipemontoya]

@johnvente can we close this as the actual feature is happening on #184? is there anything from this PR that needs salvaging?

[johnvente]

@felipemontoya We do not need this pr anymore with the UI slot implemented I will close this
cc: @mphilbrick211

[openedx-webhooks]

@johnvente Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.