Repository navigation
Make backend endpoints aware of the course authoring flag #363
Description
Activity
In a meeting with @gviedma-aulasneo, @rodmgwgu, and @mariajgrimaldi, the following was defined regarding the scope of this task:
Considering that the objective is to remove the waffle flag in two releases (Y):
-
We evaluated the proposal to create an Open edX filter to remove assignments from the response that should not be returned due to the waffle flag being disabled (full proposal here). It was determined that due to the temporary nature of this implementation, it is not viable to invest time in it.
-
However, as an alternative proposal, we suggest prioritizing only some endpoints, which are currently not being validated against the waffle flag from the backend:
POST(/validate/me/) > This endpoint validates whether a user X has a permission Y in a scope Z.PUTandDELETE(/roles/users/) > These endpoints add/remove user(s) X to/from a role Y in scope(s) Z.GET(/scopes/) > This endpoint lists the scopes that a user X can view/manage.
@gviedma-aulasneo, could you please validate this list? We are open to adding/removing any endpoint according to our needs.
-
The current solution implemented for the Willow release (waffle flag status endpoint + frontend validation and restrictions) will be maintained. This will later be removed with the deprecation and elimination of the waffle flag.
-
- linked a pull request that will close this issuedocs: define REST API ownership and visibility extension #390
on Sep 1, 2026 - linked a pull request that will close this issuerefactor: split REST API views by domain ownership and package layout #378
on Sep 1, 2026 - removed a link to a pull requestdocs: define REST API ownership and visibility extension #390
on Sep 2, 2026 - removed a link to a pull requestrefactor: split REST API views by domain ownership and package layout #378
on Sep 2, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNo status
Description
As part of the work in 567e9a0, we added a dedicated endpoint to expose the current state of the
authz.enable_course_authoringwaffle flag. That endpoint lets the admin-console MFE decide what to show for this release (verawood), but the backend endpoints themselves are still not aware of the flag state.This issue tracks the follow-up work needed to make the relevant backend endpoints aware of
authz.enable_course_authoring, instead of leaving all filtering logic to the MFE.Context
The current approach was chosen to avoid changing release-blocking endpoints late in the release cycle. The new endpoint is additive and lets the MFE apply the simpler release-time behavior. However, the ADR added in the commit notes that making the REST API endpoints themselves aware of the flag is still an open problem and should be addressed separately.
Expected behavior
Backend endpoints that expose or validate authoring-related roles, scopes, permissions, or assignments should take the
authz.enable_course_authoringflag state into account where appropriate.This should help avoid returning or validating authoring-related data in cases where the flag state means those items should not be considered available.
Notes
Related context: