/
Verawood - Operator Release Notes

Verawood - Operator Release Notes

Please do not edit this document any further - the notes have been transcribed at https://github.com/openedx/docs.openedx.org/pull/1486

 

The 22nd Open edX community release will be named Verawood. Consult the Open edX Release Schedule for details around when the release master branch will be cut and the actual release will occur.

Put stuff here that we have to remember when we start packaging up Verawood.  Especially important is information that system installers or operators will need to know. Please include your name when you add an item, so that we can get back to you with questions.

Operational

  • The HELP_TOKENS_BOOKS setting has been updated to reference the official Open edX documentation. Similarly, the help_tokens.ini file, which is specified in the HELP_TOKENS_INI_FILE setting, was updated in both the LMS and CMS configurations to ensure the paths align with the official Open edX documentation.

  • Possible failed migration during upgrade: Due to a bug that was present in the last several releases, it was possible for users to create multiple courses with similar course IDs that differed only in capitalization; however such courses would only appear as a single course in most parts of the system, and may not work properly at all. That bug has been fixed, and a new database constraint will prevent that from happening going forward. However, if you have any of these “case duplicate” courses, the split_modulestore_django migration “0004_courseid_unique_ci" will fail with an IntegrityError. If you encounter this, follow these instructions to delete the invalid course record(s), and then you should be able to apply the migration and continue. (Contact: @Braden MacDonald )

  • edx-search Typesense Server Requirement Update

    • The typesense-python client library was upgraded from 1.x to 2.0.0. This version is only compatible with Typesense Server >= v30.0.

    • Action required if you use the Typesense search backend (SEARCH_ENGINE = "search.typesense.TypesenseEngine"): upgrade your Typesense server to v30.0 or later before deploying this Open edX release. No action is needed if you use the default Elasticsearch backend.

    • See https://github.com/openedx/edx-search/pull/254 and the https://github.com/typesense/typesense-python#compatibility for details.

  • [Aamir Ayub] The Learning MFE right sidebar now uses a configurable widget registry. The upgrade/upsell widget was renamed internally from “Notifications” to “Upgrade.”

    • The Upgrade widget remains enabled by default in Verawood; operators do not need to add it to SIDEBAR_WIDGETS. To disable it, configure SIDEBAR_WIDGETS: [{ id: 'UPGRADE', enabled: false }].

    • Plugin developers should migrate the old notification-tray slot to the Upgrade Panel slot, and the old discussions-sidebar slots to the Right Sidebar and Right Sidebar Trigger slots. Deprecated aliases remain compatible for now.

    • Upgrade widget localStorage keys were renamed and are not migrated, so stored widget state may reset after upgrading.

    • See the Upgrade Widget migration notes for configuration examples and the complete identifier mapping.

  • Postgresql is now supported as a backend (for fresh installs only). For more detail see Use PostgreSQL as the Relational Database Backend — Latest documentation

  • [Aamir Ayub] Notification preference defaults can now be managed at the instance level.
    Operators can override defaults for existing notification applications and
    notification types without code changes. See how to override default notification preferences.

    • NOTIFICATION_APPS_OVERRIDE

      • Default value: {}

      • Overrides default preferences for existing notification applications.
        Supported override keys are web, email, push,
        non_editable, and email_cadence.

      • Source.

    • NOTIFICATION_TYPES_OVERRIDE

      • Default value: {}

      • Overrides default preferences for existing notification types. Supported
        override keys are web, email, push, non_editable, and
        email_cadence.

      • Source.

  • [Aamir Ayub] Immediate email notifications now use a configurable buffer window. The
    first notification is sent immediately. Additional immediate-cadence
    notifications created inside the window are combined into one buffered
    digest.

    • NOTIFICATION_IMMEDIATE_EMAIL_BUFFER_MINUTES

      • Default value: 15

      • Number of minutes to buffer additional immediate-cadence email
        notifications after the first immediate email is sent.

      • Source.

  • [Aamir Ayub] ORA reminder notifications are now available. Learners who submit an Open
    Response Assessment but still need to complete required peer or self-review
    steps can receive ora_reminder web and email notifications. The Verawood
    introduces an ora_reminder notification type, see Configure ORA Reminder Notifications.

    • ENABLE_ORA_REMINDERS

      • Default value: True

      • Enables scheduled ORA reminder notifications for learners who need to
        complete peer or self reviews.

      • Source.

    • ORA_REMINDER_MAX_COUNT

      • Default value: 3

      • Maximum number of reminders sent per learner per ORA submission.

      • Source.

    • ORA_REMINDER_INTERVAL_HOURS

      • Default value: 48

      • Hours between consecutive ORA reminder notifications.

      • Source.

    • ORA_REMINDER_INITIAL_DELAY_HOURS

      • Default value: 0

      • Hours after submission before the first ORA reminder is sent.

      • Source.

    • ORA_REMINDER_SWEEP_INTERVAL_SECONDS

      • Default value: 1800

      • How often the ORA reminder sweeper Celery task reschedules itself.

      • Source.

    • ORA_REMINDER_SWEEP_BATCH_SIZE

      • Default value: 1000

      • Maximum number of ORA reminder rows processed per sweep cycle.

      • Source.

    • ORA_REMINDER_CHECK_AGAIN_HOURS

      • Default value: 12

      • Hours to wait before checking again when no peer submissions are
        available.

      • Source.

Deprecations and Removals

  • Custom edx-val storage settings deprecated in favor of Django STORAGES

    • Contributor: Muhammad Arslan Abdul Rauf

    • The edx-val application previously relied on a custom setting (VIDEO_IMAGE_SETTINGS, VIDEO_TRANSCRIPTS_SETTINGS, etc.) to determine storage backends. This behavior is now deprecated in favor of the standard Django 5.2+ STORAGES configuration. The key within the STORAGES config for a custom video transcript location is video_transcripts.

    • See https://github.com/openedx/edx-val/pull/593/files for the code change.

    • As of Verawood:

      • edx-val now correctly respects Django’s STORAGES dict, giving it precedence over legacy per-feature storage settings.

      • Custom edx-val storage settings will continue to function during the Verawood cycle but are officially deprecated and will be removed in a future release.

      • Operators should migrate their storage configuration to Django’s STORAGES format to ensure forward compatibility.

    • Required Action for Operators:

      • Update your environment configuration:

        • 1. Define the required edx-val storages inside Django’s STORAGES dictionary (e.g., for transcripts, videos, and images).

        • 2. Remove or stop relying on deprecated edx-val specific storage configuration variables.

        • 3. Review any existing custom overrides in lms/envs/common.py or deployment-specific files to ensure compatibility.

    • NOTE: Failure to migrate before the legacy settings are removed may result in incorrect storage backends being used

    • Example minimal migration:

      STORAGES: video_transcripts: BACKEND: storages.backends.s3boto3.S3Boto3Storage OPTIONS: bucket_name: your-transcript-bucket video_image: BACKEND: storages.backends.s3boto3.S3Boto3Storage OPTIONS: bucket_name: your-image-bucket

  • The SERVICE_VARIANT setting is no longer set from the environment

    1. The setting will be set to 'cms' in cms/envs/common.py and to 'lms' in lms/envs/common.py regardless of any environment variable set (DEPR).

  • CMS settings ID_VERIFICATION_SUPPORT_LINK, PASSWORD_RESET_SUPPORT_LINK, ACTIVATION_EMAIL_SUPPORT_LINK, and LOGIN_ISSUE_SUPPORT_LINK are now set to the value of the SUPPORT_SITE_LINK setting.

    • Previously they defaulted to '' (PR).

  • The setting USE_L10N was removed since it was removed in Django 5.0 (PR).

  • REGISTRATION_EXTENSION_FORM Replaced

    • The REGISTRATION_EXTENSION_FORM setting will stop working starting with the next release. It has been replaced with the PROFILE_EXTENSION_FORM setting.

    • Previously, data was only stored as JSON in the UserProfile meta field. Moving forward, this information will also be stored in the custom model that extends the fields.

    • Action for Operators

      • To prevent extended user fields from appearing empty or outdated after the update, you may need to:

        • Write and run a custom data migration script to move existing information from the meta field to your custom model.

        • Perform this migration before activating the new PROFILE_EXTENSION_FORM setting.

    • See https://github.com/openedx/openedx-platform/pull/37119 for more details.

    • Contact: @Bryann Valderrama

  • [Aamir Ayub] Course-level notification preferences have been removed. Integrations that
    read CourseNotificationPreference records should migrate to account-level notification preferences and the V3 preferences API. See the model deletion migration.

  • [Aamir Ayub] Notification preference configuration no longer uses the is_core flag or
    the core_web, core_email, and core_push fields. Clients that consume notification preference configuration data should use use_app_defaults and the plain channel fields exposed by the V3
    preferences API. See the notification type schema and v3 preferences view.

  • [Aamir Ayub] The notification preferences V2 configuration API and its related manager classes have been removed. Integrations that called /api/notifications/v2/configurations/ should use /api/notifications/v3/configurations/ instead. See the v3 route and v3 preferences view.

  • [Aamir Ayub] The send_email_digest management command is deprecated. The command still exists, but it is now a no-op that emits a deprecation warning. Daily and weekly notification digests are scheduled automatically with Celery when qualifying notifications are created. Operators who previously scheduled send_email_digest with cron should remove those cron jobs after upgrading. By default, daily digests are delivered at 17:00 UTC, and weekly digests are delivered on Monday at 17:00 UTC. See the deprecation change and Configure Notification Email Delivery.

    • NOTIFICATION_DAILY_DIGEST_DELIVERY_HOUR

      • Default value: 17

      • Hour of day, in UTC, to send daily digest emails.

      • Source.

    • NOTIFICATION_DAILY_DIGEST_DELIVERY_MINUTE

      • Default value: 0

      • Minute of the hour to send daily digest emails.

      • Source.

    • NOTIFICATION_WEEKLY_DIGEST_DELIVERY_DAY

      • Default value: 0

      • Day of the week to send weekly digest emails, where 0 is Monday and
        6 is Sunday.

      • Source.

    • NOTIFICATION_WEEKLY_DIGEST_DELIVERY_HOUR

      • Default value: 17

      • Hour of day, in UTC, to send weekly digest emails.

      • Source.

    • NOTIFICATION_WEEKLY_DIGEST_DELIVERY_MINUTE

      • Default value: 0

      • Minute of the hour to send weekly digest emails.

      • Source.

Default Changes for Verawood

  • The pdf XBlock is now built into the platform core and installed by default. If you previously installed a third-party pdf implementation such to open-craft’s xblock-pdf , then the built-in implementation will likely work as a drop-in replacement, so you can uninstall the third-party implementation. However, if you’d rather continue using a third-party pdf implementation, then follow the steps to replace a preinstalled XBlock with a custom implementation. In either case, the third-party implementation must be removed from the xblock.v1 entrypoint, otherwise you will see an AmbiguousPluginError. Additionally, you will want to enable the legacy_studio.pdf_editor to allow the third party pdf implementation to render its editor. Implemented by @Fox Piacenti (Unlicensed) with support from @Kyle McCormick .

  • Built-In blocks code has been extracted out to xblock-contrib

    • Aximprovements team has extracted several previously built-in XBlocks from openedx-platform into the shared xblock-contrib repository.

    • In Verawood, the extracted implementations are used by default in openedx-platform, and the legacy “built-in” block code is considered deprecated.

    • If you encounter problems with the extracted blocks, you can temporarily revert to the built-in implementations using the feature flags in openedx/envs/common.py, following the pattern USE_EXTRACTED_*_BLOCK (for example, USE_EXTRACTED_VIDEO_BLOCK).

    • Starting in Willow, the deprecated built-in implementations are planned to be removed from openedx-platform, leaving only the extracted variants in xblocks-contrib

    • The following blocks have been extracted and now live in xblock-contrib:

      • HTML Block

      • Video Block

      • Problem Block

      • Word Cloud Block

      • Annotatable Block

      • LTI Block

      • Poll Block

  • The new instructor dashboard frontend app will be the default experience, there will be a setting to allow it to be reverted to the legacy instructor dashboard.
    instructor.legacy_instructor_dashboard waffle flag will disable the redirection that makes the new frontend app as the default experience.

    • If you were using org.openedx.learning.instructor.dashboard.render.started.v1 filter to modify the instructor dashboard tabs you can achieve a similar outcome by using org.openedx.learning.instructor.dashboard.tabs.generated.v1 which will give you access to the API endpoint that it’s currently consumed to render the tabs on the frontend-app you’ll also need to add a widget to the proper slot to render the content. More details on this README file.

    • Contact @Diana Villalvazo Salas

  • [Aamir Ayub] Notifications and notification emails are now enabled by default. The previous opt-in waffle flags, notifications.enable_notifications and notifications.enable_email_notifications, have been replaced by opt-out flags. Operators who need to keep notifications disabled after upgrading must enable notifications.disable_notifications or notifications.disable_email_notifications.

    • Added: notifications.disable_notifications

      • Default value: False

      • When enabled, disables the Notifications feature. When unset, notifications are enabled by default.

      • Source.

    • Added: notifications.disable_email_notifications

      • Default value: False

      • When enabled, disables notification emails. When unset, notification emails are enabled by default.

      • Source.

    • Removed: notifications.enable_notifications

      • Replaced by notifications.disable_notifications.

    • Removed: notifications.enable_email_notifications

      • Replaced by notifications.disable_email_notifications.

Other

Frontend-base

Verawood is the first release that supports the new frontend-base architecture. It enables frontend apps to be loaded as direct plugins within a unified “shell”, rather than as separate, independently deployed MFEs. There are several advantages to this paradigm, including improved learner UX, reduced page load time, faster builds, and a broader-scoped plugin API. For more information on what motivated this change, please refer to OEP-65: Frontend Composability — Open edX Proposals 1.0 documentation.

In practice, frontend apps are NPM packages that plug into a single frontend-base site. Verawood ships with four of these:

  • @openedx/frontend-app-authn: replaces the Authn MFE; disabled by default

  • @openedx/frontend-app-learner-dashboard: replaces the Learner Dashboard MFE; disabled by default

  • @openedx/frontend-app-instructor-dashboard: replaces the legacy instructor dashboard; enabled by default

  • @openedx/frontend-app-notifications: ports @edx/frontend-plugin-notificationsto the frontend-base ecosystem; enabled by default

The tutor-mfe implementation allows each of these to be easily enabled or disabled without requiring a rebuild of the Tutor image, as documented here. When an app that replaces an existing MFE is enabled (such as Authn or Learner Dashboard), its MFE counterpart is automatically disabled.

It is expected that by Xylon (the Open edX release following Willow), all Open edX MFEs will have been converted to frontend-base apps. Operators are therefore encouraged to enable the Authn and Learner Dashboard apps to test pre-existing customizations on their instances. It is likely that any branding, plugins, and forks of MFEs will need to be ported accordingly. Documentation on how to do so is provided at:

As a migration aid for unconverted legacy plugins, a frontend-base-compat shim that lets legacy env.config.jsx configuration run on top frontend-base sites is provided. It is also implemented by tutor-mfe: refer to the corresponding section of its documentation for information on how to use it.

Finally, note that tutor-mfe’s frontend-base implementation automatically makes use of the new/api/frontend_site_config/v1/ runtime configuration endpoint, which converts existing MFE_CONFIG and MFE_CONFIG_OVERRIDES to frontend-base's SiteConfig structure. You can find out more here.

What if I don’t use Tutor?

If you deploy Open edX using something other than Tutor, start by looking at frontend-template-site. This is the canonical representation of how a frontend-base site should be configured. Operators are meant to fork and modify it as required for their own instances. Everything in it is considered user-configuration: including index.html!

Loading External Scripts

It is now possible to configure either MFEs or frontend apps to load arbitrary external scripts, such as ones used to configure hosted analytics services. Where before only Google Analytics was supported, now operators are free to load whatever external service they need. See the corresponding tutor-mfe documentation.

For an example implementation, refer to a sample Tutor plugin that loads Google Analytics dynamically on both MFEs and frontend apps: https://github.com/openedx/openedx-tutor-plugins/tree/main/plugins/tutor-contrib-google-analytics

Aspects Analytics

Upgrading to Aspects v4.0.0 will give you the latest Aspects functionality including Superset 6.0! See the upgrade instructions here: Upgrade Aspects.

This is a BREAKING CHANGE upgrade. Aspects will now use Python v3.12 which was introduced in the Tutor Verawood release.

Removal of Temporary SAML Toggle

Consolidation of several XBlock packages into xblocks-extra

Notes for Release Manager (not for release notes)

Comments