Relocating Content Block Settings back to XBlocks

Feature Ideas
1

:backhand_index_pointing_right: For the full context of the overall project to migrate all Advanced Settings into more suitable locations, see https://openedx.atlassian.net/wiki/x/AwAjOAE

Overview

This project proposes migrating all Content Block–related settings from the Studio Advanced Settings page into their respective XBlocks. This will allow authors to configure blocks directly where they are used, aligning with the Visually Configure Course Blocks initiative.

Problem

Currently, Content Block settings are centralized in Advanced Settings, far from the blocks they control. This separation makes it hard for course authors to discover, understand, and correctly configure block behavior, leading to confusion and errors.

Use Cases

  • As a course author, I need to configure a block’s advanced options directly inside that block’s editor in order to avoid navigating to a separate page and reduce the risk of misconfiguration.

  • As an instructor, I need settings grouped with the block they belong to in order to save time and ensure accuracy when setting up course content.

Supporting Data

Schema’s analysis identified 11 Advanced Settings tied to Content Blocks.

  1. Video sharing options

  2. Show reset button for problems

  3. Show answer

  4. Randomization

  5. Maximum attempts

  6. Matlab api key

  7. Lti passports

  8. Force flexible grading for peer oras

  9. Enable video caching system

  10. Enable latex compiler

  11. Advanced Module List

Relocating them to their respective XBlocks will:

  • Align with the Visually Configure Course Blocks project that already aims to unify block-level authoring.

  • Eliminate redundant navigation, making configuration more intuitive.

  • Reduce support requests caused by hidden or misunderstood settings.

2

I’m delighted to see you folks tackling the monster that is Advanced Settings. :grin:

General question: From the technical perspective, does this proposal mean moving the UX for setting these fields to a new location, but keeping the implementation the same (i.e. inherited attributes on the root course block)?

Some notes on a couple specific fields:

Please just ignore this one and let it die. There’s a long standing DEPR for killing it, and the only reason it’s not gone already is because it’s being partially blocked by XQueue deprecation that is actively being worked on (the Matlab API tests also double as XQueue interface tests).

This should probably also die in the fires of DEPR. It’s not only obscure, it’s actively confusing. This was created around 2014, and was a mechanism to allow a site serving a Chinese audience to specify a specific CDN that would be used for users in a specific location w.r.t. their video data, if the course opts into it. It also only works if you have a video pipeline that you’ve loaded the appropriate data into edx-val for. Basically, unless you have three very specific pieces of configuration, a backend video pipeline that almost nobody uses in this way, and a user that is accessing your site from the country it is specifically configured for, this setting does absolutely nothing.

Even if we decided that this location-specific CDN were a thing we wanted to do, we shouldn’t be letting a course author toggle this switch.

I guess in general, it would be great in the assessing team can do an audit and determine which of these things can be killed altogether instead of being moved out of Advanced Settings.

1 Like