Skip to content

Make backend endpoints aware of the course authoring flag #363

Description

@mariajgrimaldi

Description

As part of the work in 567e9a0, we added a dedicated endpoint to expose the current state of the authz.enable_course_authoring waffle 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_authoring flag 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:

Activity

  1. moved this to In Grooming in RBAC AuthZ Boardon Jul 22, 2026
  2. moved this from In Grooming to Ready for Development in RBAC AuthZ Boardon Jul 30, 2026
  3. moved this from Ready for Development to Blocked in RBAC AuthZ Boardon Aug 5, 2026
  4. BryanttV commented on Aug 24, 2026

    @BryanttV
    Contributor

    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):

    1. 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.

    2. 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.
      • PUT and DELETE (/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.

    3. 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.

  5. moved this from Blocked to In Progress in RBAC AuthZ Boardon Sep 1, 2026
  6. moved this from In Progress to No status in RBAC AuthZ Boardon Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    willowReleased in Willow

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions