When exercising the API:
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.
When exercising the API:
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_paceddoes 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_dateto 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_behaviorreset toEARLY_NO_INFOstill 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.