You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PUT course_details updates inconsistently (possibly requires start_date?) #39094
PUT /api/contentstore/v1/course_details/<key>
(cms/djangoapps/contentstore/rest_api/v1/views/course_details.py / openedx.core.djangoapps.models.course_details.CourseDetails.update_from_json)
The view documents partial bodies ("multiple details can be updated in a single request"), and every other field measured seems to honor one. self_paced does not: {"self_paced": true} (or "true", the string the MFE sends) answers HTTP 200 with the unchanged pacing echoed back, and a subsequent GET agrees.
Adding the course's own current start_date to the same body - {"self_paced": true, "start_date": "2040-01-01T00:00:00Z"} - makes the same request take effect.
Side effect: with the pacing change dropped, the accompanying certificates_display_behavior reset to EARLY_NO_INFO still happens, leaving an instructor-paced course with the self-paced display behavior.
Note: that this doesn't impact the MFE, which always sends the whole form, but is confusing behavior for any API consumer.
Note: a body carrying self_paced: true together with a start date in the past also leaves pacing unchanged with HTTP 200.
I'd like to work on this. My first step is reproducing it locally with the request bodies in the issue and pinning down where self_paced gets dropped; I'll post what I find here within about a week.
From reading the code (not run yet, so treat this as a guess): in CourseDetails.update_from_json, a body without start_date sets block.start to None before the self_paced branch runs, and can_toggle_course_pacing returns False when there is no start date, so the pacing change is skipped while the request still answers 200.
One question before I build anything: for the case in the issue's last note, a course whose start date is already in the past, can_toggle_course_pacing refuses the change by design. Should the fix keep that refusal and answer 400 with a message, rather than 200 with the old value? For the partial-body case I'd keep the existing start date when start_date is absent, so self_paced is honored there, unless you'd prefer a different approach.
Disclosure per the Open edX AI policy: I'm using Claude to help me read the code and draft this comment. I checked the lines above myself, and I'll make sure I understand everything I submit.
Activity
newairforces commentedon Oct 24, 2026
I'd like to work on this. My first step is reproducing it locally with the request bodies in the issue and pinning down where
self_pacedgets dropped; I'll post what I find here within about a week.From reading the code (not run yet, so treat this as a guess): in
CourseDetails.update_from_json, a body withoutstart_datesetsblock.starttoNonebefore theself_pacedbranch runs, andcan_toggle_course_pacingreturnsFalsewhen there is no start date, so the pacing change is skipped while the request still answers 200.One question before I build anything: for the case in the issue's last note, a course whose start date is already in the past,
can_toggle_course_pacingrefuses the change by design. Should the fix keep that refusal and answer 400 with a message, rather than 200 with the old value? For the partial-body case I'd keep the existing start date whenstart_dateis absent, soself_pacedis honored there, unless you'd prefer a different approach.Disclosure per the Open edX AI policy: I'm using Claude to help me read the code and draft this comment. I checked the lines above myself, and I'll make sure I understand everything I submit.
bmtcril commentedon Oct 26, 2026
Hi @newairforces, it looks like you aren't a member of the Open edX organization yet so before you could get a PR approved (or even tests run) you would need to complete the steps listed here: https://docs.openedx.org/en/latest/developers/quickstarts/so_you_want_to_contribute.html
Let me know if you go through the process and sign the CLA then we'd be happy to help you get up to speed with this.