Make backend endpoints aware of the course authoring flag

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

• 567e9a0
• [Bug] Authoring-related UI is visible in lists when the waffle flag is off #340
• [Bug] Hide Authoring roles in the role assignment wizard when Authoring is disabled at platform, org, and course level #341
• feat: add waffle flag states rest api and util #358
• feat: make PermissionValidationMeView aware of the course-authoring flag #361

[BryanttV]

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.