[dcoa]

Description

The Roles filter of the team members table and the user audit page now lists the roles from the AuthZ catalog (GET /api/authz/v1/roles/) instead of a hardcoded list. This is the first screen moved to the catalog introduced in #262

Stacked PR: based on # (dcoa/catalog-1-feature). Review only the last commit.

What changes

• RolesFilter reads useAuthzCatalog() and builds one group per scope type (course-v1 → Courses, lib → Libraries), with the role ids and display names sent by the backend.
• The catalog only holds the scope types the user can view, so RolesFilter no longer calls useViewTeamPermissions. Course roles still also require the course-authoring flag.
• Roles are listed from most to fewest permissions, the order getScopeCatalog gives.
• Removed the hardcoded getRolesFiltersOptions and its Global group message as non of the tables return global scopes today (Django roles).

User-facing impact

• Role names in the filter come from the backend, so new or renamed roles show up without a frontend change.
• A role the backend doesn't return no longer appears as a filter option.

At the moment this screenshot is taken the Course Editor and Auditor roles are hidden therefore not returned by the API.

Testing instructions

1. Open Team members and a user's audit page, then open the Roles filter.
2. As a user who can view both course and library teams, check that both Courses and Libraries groups appear, each listing the roles the backend returns, ordered from most to fewest permissions.
3. As a user who can only view library teams, check that only the Libraries group appears.
4. With the course-authoring flag disabled, check that the Courses group is hidden.
5. Select a role and check that the table filters by it.

Tests

• RolesFilter.test.tsx mocks the catalog (mockAuthzCatalog) and covers: library-only and both-scope users, ordering by permission count, no viewable scope types, catalog loading, and the course-authoring flag (disabled and loading).
• TableControlBar.test.tsx mocks the catalog for its wiring tests.

AI disclosure

Assisted by Claude

[openedx-webhooks]

Thanks for the pull request, @dcoa!

This repository is currently maintained by @openedx/committers-frontend.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.60%. Comparing base (8cb1f97) to head (0a89360).

Additional details and impacted files

@@                   Coverage Diff                   @@
##           dcoa/catalog-1-feature     #263   +/-   ##
=======================================================
  Coverage                   98.60%   98.60%           
=======================================================
  Files                          84       84           
  Lines                        1430     1432    +2     
  Branches                      476      475    -1     
=======================================================
+ Hits                         1410     1412    +2     
  Misses                         19       19           
  Partials                        1        1           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.