Description
The Advanced Settings API (/api/contentstore/v0/advanced_settings/{course_id}) returns only value, display_name, help, deprecated, and hide_on_enabled_publisher for each setting. It never says what type a setting is, nor what valid choices an enum-like setting accepts. Any client that wants to render type-appropriate controls has to hardcode that metadata itself, which duplicates knowledge the platform already has, drifts as settings change, and risks silent data loss when a dropdown omits a value a course actually has set.
This issue tracks moving that metadata into the API response so the backend is the single source of truth. CourseMetadata.fetch_all gains two fields per setting: type, the XBlock field class name (String, Boolean, Integer, Float, List, Dict, and so on), so clients pick an input without inferring it from the value's shape; and options, the field's values, which is a list of {display_name, value} choices for enum-like fields, a constraints dict such as {"min": 0} for some numeric fields, or null for free-form fields. The change is additive and backward compatible, since existing keys are untouched.
Several enum settings have no course-level values today and so would come back with empty options. showanswer, rerandomize, and show_correctness in xmodule/modulestore/inheritance.py, plus certificates_display_behavior in xmodule/course_block.py, get course-level values sourced from a new shared xmodule/course_settings_field_options.py holding the canonical option lists. Settings that already declare values, such as catalog_visibility, course_visibility, and video_sharing_options, are exposed automatically by the serializer change with no per-field edit.
The problem-level field definitions in xmodule/capa_block.py are intentionally left alone. Migrating them to reference the same shared option lists, so the problem and course levels share one definition, is a reasonable follow-up.
This is the backend counterpart to the Advanced Settings redesign in Studio, and it exists because of review feedback on the frontend work that field metadata should not be duplicated on the client.
Backend: #38784
Frontend (consumes type and options): openedx/frontend-app-authoring#3019
Frontend issue: openedx/frontend-app-authoring#3187
Roadmap issue: openedx/platform-roadmap#514
Discourse discussion: https://discuss.openedx.org/t/modernize-ui-options-for-advanced-settings/17269
Description
The Advanced Settings API (
/api/contentstore/v0/advanced_settings/{course_id}) returns onlyvalue,display_name,help,deprecated, andhide_on_enabled_publisherfor each setting. It never says what type a setting is, nor what valid choices an enum-like setting accepts. Any client that wants to render type-appropriate controls has to hardcode that metadata itself, which duplicates knowledge the platform already has, drifts as settings change, and risks silent data loss when a dropdown omits a value a course actually has set.This issue tracks moving that metadata into the API response so the backend is the single source of truth.
CourseMetadata.fetch_allgains two fields per setting:type, the XBlock field class name (String,Boolean,Integer,Float,List,Dict, and so on), so clients pick an input without inferring it from the value's shape; andoptions, the field'svalues, which is a list of{display_name, value}choices for enum-like fields, a constraints dict such as{"min": 0}for some numeric fields, ornullfor free-form fields. The change is additive and backward compatible, since existing keys are untouched.Several enum settings have no course-level
valuestoday and so would come back with empty options.showanswer,rerandomize, andshow_correctnessinxmodule/modulestore/inheritance.py, pluscertificates_display_behaviorinxmodule/course_block.py, get course-levelvaluessourced from a new sharedxmodule/course_settings_field_options.pyholding the canonical option lists. Settings that already declarevalues, such ascatalog_visibility,course_visibility, andvideo_sharing_options, are exposed automatically by the serializer change with no per-field edit.The problem-level field definitions in
xmodule/capa_block.pyare intentionally left alone. Migrating them to reference the same shared option lists, so the problem and course levels share one definition, is a reasonable follow-up.This is the backend counterpart to the Advanced Settings redesign in Studio, and it exists because of review feedback on the frontend work that field metadata should not be duplicated on the client.
Backend: #38784
Frontend (consumes
typeandoptions): openedx/frontend-app-authoring#3019Frontend issue: openedx/frontend-app-authoring#3187
Roadmap issue: openedx/platform-roadmap#514
Discourse discussion: https://discuss.openedx.org/t/modernize-ui-options-for-advanced-settings/17269