Versions Compared

Old Version 32

changes.mady.by.user Tim McCormack

Saved on

compared with

New Version 33

changes.mady.by.user Ghassan Maslamani

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Creation of User Tours (

    Jira Legacy
    serverSystem JIRA
    serverId13fd1930-5608-3aac-a5dd-21b934d3a4b4
    keyAA-1024
    - edx-platform #29301) - User Tours allow the platform to create Tours in our Microfrontends (MFE) to walk users through the platform (see examples in frontend-app-learning #750). In order for User Tours to properly work, the backpopulate user tours management command should be run. The default tours that exist are: New User Tour and Existing User Tour in the Course Home of the Learning MFE and a New User Tour in the Courseware of the Learning MFE.

  • The old course goals feature has been replaced with a new weekly learning goals feature. Users set a goal for how frequently they want to learn per course and get reminder emails about their goals. See https://edx.readthedocs.io/projects/edx-installing-configuring-and-running/en/latest/configuration/enable_weekly_learning_goals.html for instructions on how to configure this feature and more details on how the feature works. The new weekly learning goals feature is controlled with the same flag as the previous course goals feature.

  • Instructor Dashboard

    • Bulk Course Email Tool

      • Added the ability to filter recipients of bulk course emails based on the last_login date of Users enrolled in a course run. This feature can be enabled by setting a value for the BULK_COURSE_EMAIL_LAST_LOGIN_ELIGIBILITY_PERIOD setting. Its value should be an integer (representing months) that represents the eligibility period from the current date to receive a message. The new setting defaults to None which keeps this new feature disabled (and there will be no change in behavior in how recipients are filtered/selected for a message).

      • Added a simple bulk_email_disabledcourse table that allows for the bulk email tool to be disabled for specific course runs, even if the bulk email flag is on and the course is enabled in the bulk_email_courseauthorization table. A course team will not be able to see the bulk email tab on the instructor dashboard for whatever course runs are in this table.

      • the setting EMAIL_USE_DEFAULT_FROM_FOR_BULK was changed to EMAIL_USE_COURSE_ID_FROM_FOR_BULK. The behavior was also changed, such that those who wish to use their course id in the from address for bulk email must now enable the flag to true.These changes were made in order to avoid non existent from address to fail in email servers. (I Connor Haugh )

      • Bug fix: when using GMSTP (Gmail) for sendking bulk email. tasks.py didn’t catch retriable SMTP exception. This PR fixed it https://github.com/openedx/edx-platform/pull/29080. Also for context check the reporting of the bug https://discuss.openedx.org/t/bulk-emails-sending-too-fast-causing-gmail-to-block-account-is-there-a-way-to-rate-limit/5963

  • SafeSessionMiddleware rejects mismatching requests and sessions Tim McCormack

    • Background: This is an existing middleware that provides several protections against vulnerabilities that could result from cache misconfigurations or other bugs resulting in one user getting a different user's session.

    • Changed: Previously if a user mismatch was detected between request or session and response, the middleware would log warnings; now, it will invalidate the session and send an error response. The toggle ENFORCE_SAFE_SESSIONS is enabled by default, but can be disabled to return to just log warnings.

    • Before upgrade: Check that your logs do not contain warnings starting with "SafeCookieData user at request", or that these warnings are very rare. If they are common, there is likely a false positive caused by some custom login, masquerading, or registration code that needs to call mark_user_change_as_expected. Otherwise, valid requests may be rejected.

  • Core extensibility (Maria Grimaldi): add a new way of extending the core through Open edX Events & Filters (part of OEP-50: Hooks Extension Framework)

    • Open edX Events: this standardized version of Django Signals allows extension developers to extend functionality just by listening to the event that’s sent after a key process finishes, e.g after enrollment, login, register, etc.

    • Open edX Filters: through configuration only, extension developers can set a list of functions to be executed before a key process starts, e.g before enrollment, login, register, etc.

  • New config value that all deployments should set: CLOSEST_CLIENT_IP_FROM_HEADERS in edx-platform Tim McCormack

    • This is a security-impacting setting that tells your deployment how to determine the IP address of the client. See openedx.core.djangoapps.util.ip for documentation on how (and why) to configure this (as well as the related NUM_PROXIES setting for django-rest-framework).

    • Breaking change: Failing to set this can result in rate-limiting legitimate traffic or failing to block brute-force attacks, depending on your proxy setup.

...