[Bug] Hide Authoring roles in the role assignment wizard when Authoring is disabled at platform, org, and course level

[gviedma-aulasneo]

Current

Currently, when a user opens the role assignment wizard and the Authoring waffle flag is off at the platform level, they can still see Authoring roles as available assignment options.

Currently, when a user opens the role assignment wizard and Authoring is disabled at platform, org, and course level, they can still see Authoring roles as available assignment options.

This allows users to view and select roles that belong to a disabled domain.

Expected

When the Authoring waffle flag is off at the platform level, Authoring roles must not be exposed in the role assignment wizard.
When Authoring is disabled at platform, org, and course level, Authoring roles must not be exposed in the role assignment wizard.

The roles available for assignment must be restricted according to the enabled domains and the current user's permissions:

• If the Authoring waffle flag is off at the platform level**, and course-level and org-level waffle are off,** Authoring roles must not be listed.
• If the Authoring waffle flag is off at the platform level, and course-level or org-level waffle are on Authoring roles can be shown according to the current user's scope and permissions.
• If the Authoring waffle flag is on at the platform level, Authoring roles can be shown according to the current user's scope and permissions.

There are no intermediate states for this behavior. The feature is either enabled or disabled at the platform level. Existing org-level and course-level waffle flags should return the same state as the platform-level on value and must not introduce additional role assignment behavior.

US

As a user assigning roles to others,

I want to see only the roles that belong to enabled domains,

So that I cannot assign Authoring-related roles when the Authoring waffle flag is off for all scope levels.

[MaferMazu]

I don't think this is the right behavior. Because at the design level, we have the intermediate-state behavior.

At the start of the development of the second part of RBAC, several decisions were made, including implementing the waffle flag at the platform, org, and course levels. The whole idea of having the granularity of the waffle flag is to allow large instances to test the new authoring system within a controlled scope, with bidirectional migration (allowing secure rollbacks), and to avoid testing difficulties and massive risks.

Docs about the decision:

• https://github.com/openedx/openedx-authz/blob/main/docs/decisions/0010-course-authoring-flag.rst
• https://openedx.atlassian.net/wiki/spaces/OEPM/pages/6331662350/RBAC+AuthZ+for+Course+Authoring+-+Operator+Release+Notes

If we implement what you are suggesting here, @gviedma-aulasneo, we won't be able to assign course roles to a course when the waffle flag is active only in a course/org scope, so the decision to have that granularity will be useless. We will be forcing people to turn on the flag by platform by default when it was decided that in Verawood, we will have the option to scope the impact to a course/org level.

I think it is a wrong idea to change that fundamental behavior of the waffle flag so close to the release.

cc @gviedma-aulasneo @rodmgwgu

[gviedma-aulasneo]

I don't think this is the right behavior. Because at the design level, we have the intermediate-state behavior.

At the start of the development of the second part of RBAC, several decisions were made, including implementing the waffle flag at the platform, org, and course levels. The whole idea of having the granularity of the waffle flag is to allow large instances to test the new authoring system within a controlled scope, with bidirectional migration (allowing secure rollbacks), and to avoid testing difficulties and massive risks.

Docs about the decision:

• https://github.com/openedx/openedx-authz/blob/main/docs/decisions/0010-course-authoring-flag.rst
• https://openedx.atlassian.net/wiki/spaces/OEPM/pages/6331662350/RBAC+AuthZ+for+Course+Authoring+-+Operator+Release+Notes

If we implement what you are suggesting here, @gviedma-aulasneo, we won't be able to assign course roles to a course when the waffle flag is active only in a course/org scope, so the decision to have that granularity will be useless. We will be forcing people to turn on the flag by platform by default when it was decided that in Verawood, we will have the option to scope the impact to a course/org level.

I think it is a wrong idea to change that fundamental behavior of the waffle flag so close to the release.

cc @gviedma-aulasneo @rodmgwgu

Thank you, @MaferMazu ! I reviewed the issue again, and you are right, the description does not accurately reflect what we agreed on in the meeting.

My intention was not to say that Authoring roles should be hidden when the platform-level flag is off but the org or course flag is on.

The expected behavior should be:

Platform flag off, org flag off, and course flag off: Authoring roles should be hidden.
Platform flag on, even if org and course flags are off: Authoring roles should be shown according to the current user's scope and permissions.
Platform flag off, but org or course flag on: Authoring roles should be shown according to the current user's scope and permissions.

I already changed the description. Please let me know if it's still ambiguous.

[maguilarUXUI]

@MaferMazu Do you know what is the update about this issue

[MaferMazu]

Yes, I'm starting working on it.

But just for information, this issue is related to openedx/frontend-app-admin-console#163, and that one can be solved with openedx/frontend-app-admin-console#172. I need to figure out if that PR also solves this one, or if there is a collaboration or something to no duplicate work.