feat: reactive schedules nudge emails filter

[BryanttV]

Description

This PR adds a pipeline step to use the ScheduleQuerySetRequested filter. This step allows filtering the users in the Schedule QuerySet to keep only users with the allow_newsletter field set to True.

Related Issues

• https://github.com/fccn/nau-technical/issues/279
• https://github.com/eduNEXT/consulting-issues-mapping/issues/10

Testing Instructions

1. Create a Tutor environment in the Redwood version.

2. Install this plugin with the changes in this PR. ⚠️ Don't forget to run migrations.

3. Install openedx-filters with the changes in this PR.

4. Create a mount of edx-platform with the changes in this PR.

5. Create a new Schedule config for your site in {lms_domain}/admin/schedules/scheduleconfig/

   

6. Create some users and enroll them in a course.

7. Create an NAU user extended model for each user in {lms_domain}/admin/nau_openedx_extensions/nauuserextendedmodel/

8. Create a Tutor inline plugin with the filter configuration:

   name: filter-settings
   version: 0.1.0
   patches:
     openedx-common-settings: |
       OPEN_EDX_FILTERS_CONFIG = {
         "org.openedx.learning.schedule.queryset.requested.v1": {
           "fail_silently": False,
           "pipeline": [
             "nau_openedx_extensions.filters.pipeline.FilterUsersWithAllowedNewsletter",
           ],
         },
       }

9. Send a message of recurring nudge using the following command in the LMS container:

   python manage.py lms send_recurring_nudge {site} --date {enroll-date + 3 days}
   # Example
   python manage.py lms send_recurring_nudge local.edly.io:8000 --date 2024-12-07

10. Depending on the value of each user's allow_newsletter field, you should see the filtered QuerySet of Schedules in the console.

[MaferMazu]

Thanks for those PRs, @BryanttV.

I tested it, and it worked as expected ✨

About this PR, I have a few comments:

• We probably don't need the definition.py file; we will have that code in openedx-filters. We can update the openedx-filters package here, and to add more context, we can add a reference to the filter we are using in the pipeline doc. Or are we adding that for another reason?
• I am not sure which case we encountered the FieldError. If you have identified, I would like to know.

[BryanttV]

Hi @MaferMazu, thanks for the review!

We probably don't need the definition.py file; we will have that code in openedx-filters. We can update the openedx-filters package here, and to add more context, we can add a reference to the filter we are using in the pipeline doc. Or are we adding that for another reason?

That's right, the definition.py is only for testing. I deleted it from this branch. When the openedx-filter PR is merged, we should update the requirements here.

I am not sure which case we encountered the FieldError. If you have identified, I would like to know.

This validation is only in case the plugin migrations have not been executed, and the model does not exist. Do you think we don't need it?

[MaferMazu]

MF: I am not sure which case we encountered the FieldError. If you have identified, I would like to know.
Bryann: This validation is only in case the plugin migrations have not been executed, and the model does not exist. Do you think we don't need it?

I understand why you added it, but I think this part of the code shouldn't be responsible for the lack of migration; having the migrations is a pre-requisite.

If you want, we can add a small note to the filter docs, but I think it is not necessary.

[MaferMazu]

This looks good to me ✨

Thanks for these PRs

[MaferMazu]

@BryanttV, as I said, this looks good, but I think we should add some tests.

Example: https://github.com/fccn/nau-openedx-extensions/blob/nau/nutmeg.master/nau_openedx_extensions/tests/test_pipeline.py

[BryanttV]

Hi @MaferMazu, I added the unit tests.