feat(authz): create libraries team management view

[dcoa]

Add "Team Members" Tab to Library Team Management View

This PR introduces the main view for the libraries team management. The view displays a tab "Team Members" with a table of all the members in a library. This functionality enables members with appropriate permissions to review who has access to the library.

Note: The current development focus on embed AuthZ management features for scoped library. However, aims to be a base for future scope and functionality expansion.

Overview of Changes:

1. Create a helpers and components folder for utilities and components useful across the application. Those include a function for API url resolution and a LoadingPage.
2. Create the useValidateUserPermissions hook to connect with the AuthZ backend and validate user permissions for a given object. This is being used for permission-aware rendering.
3. Creation of the AuthZ module layout.
4. Creation of a libraries context and page.
5. Creation of the TeamTable that contains the following columns: Name, Email, Roles, and Actions.
6. The action in the table are only visible of the user has team management permissions.
7. Update the testing utilities.

Out of Scope:

1. Sorting and filtering functionality will be handled in a separate user story.
2. API integration is handled separately and is not part of this card. The current focus is solely on the UI content.
3. Error handling will be defined in separate shared cards, ensuring consistency across the platform.

Warning

The backend is not available at the moment, because of that can not be tested in a sandbox, should be tested locally with mock data available here openedx/openedx-authz#46 (comment).

Evidence

test.webm

Testing instructions

1. Create and setup a local environment (Tutor recommended)
2. Run LMS and CMS, then clone the repo in the current branch and run the dev server npm run dev
3. Add the URL to the CORS_WHITELIST in both LMS/CMS settings.py

# admin console MFE
CORS_ORIGIN_WHITELIST.append("http://apps.local.openedx.io:2025")
LOGIN_REDIRECT_WHITELIST.append("apps.local.openedx.io:2025")
CSRF_TRUSTED_ORIGINS.append("http://apps.local.openedx.io:2025")

5. Create a library
6. Navigate to http://apps.local.openedx.io:2025/admin-console/authz/libraries/:libraryId
7. Mock the API calls for /authz/* queries, you can use 2 options
   • Use Chrome override https://developer.chrome.com/docs/devtools/overrides
   • Use an API mock tool such as Postman and Mockoon, and replace the API baseUrl with your service and, change getAuthenticatedHttpClient to getHttpClient to avoid user checks from the backend.

Additional information

1. US: View library team members openedx-authz#46

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

---

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

❌ Patch coverage is 99.32886% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.82%. Comparing base (f742571) to head (7cb528b).
⚠️ Report is 17 commits behind head on master.

Files with missing lines	Patch %	Lines
src/index.tsx	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master       #2       +/-   ##
===========================================
+ Coverage        0   89.82%   +89.82%     
===========================================
  Files           0       18       +18     
  Lines           0      167      +167     
  Branches        0       19       +19     
===========================================
+ Hits            0      150      +150     
- Misses          0       17       +17     

☔ View full report in Codecov by Sentry.
📢 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.

[holaontiveros]

Looks like almost every fix from the previous PR is here also, it looks great, I left a comment

[holaontiveros]

Shouldn't this be intl.formatMessage(messages['.....'])

[dcoa]

The title yes, the body is just a template for now (same for permissions tab, because they have their own US), will be developed in a separate PR.

[arbrandes]

This is looking great! It's so refreshing to be able to actually understand the data flow from just reading the React Query and React Context code. 😃 Congrats!

I did have a few suggestions and nitpicks, though. None of them are blocking in principle, but I would like to hear a defense in case you disagree. (Even if it's "we can do that in a follow-up PR".)

[bradenmacdonald]

Is Studio header the right header for this MFE?

[dcoa]

Yes, we believe the Studio header is the right choice for the MVP, given that the current functionality is focused solely on Library team management, which fits well within the Studio context. However, we will revisit the header choice in Phase 2, when we start integrating broader scopes and modules within the console.

[bradenmacdonald]

I just want to warn that this LibraryAuthZContext could grow large and unwieldy over time if you're not careful. I've seen this pattern in the Authoring MFE when several different developers keep adding things to the context because it's convenient to do so, and you end up with a huge context that's hard to refactor.

If you are confident that most of the child components in the hierarchy will need to access most of these fields, then it makes sense to leave them in this kind of context. But for things like "library name" which appear in only a few places, there's not much advantage to putting it in the context; in fact, it just adds more code and complexity.

In other words, if you only access the library name in one or two places, I think it's better to write:

- const { libraryId, libraryName } = useLibraryAuthZ();
+ const { libraryId } = useLibraryAuthZ();
+ const { title: libraryName } = useLibrary(libraryid);

and leave the library name out of the context. But on the other hand if you use the library name in dozens of components, it is reasonable to put it in the context.

I don't think anything you have here is wrong, but I do see the warning signs of a context object that may grow very large if people just keep adding every single piece of loadable data to this context rather than loading it as needed. A very large context gives some of the same problems as Redux that we're trying to avoid here, so I recommend small, focused data loading hooks rather than shared context for most things. But obviously there are still some things worth putting in the context or necessary to put in the context.

(What about preloading? This would be a fine place to preload things, but you can do that without storing the result anywhere other than react-query's internal cache.)

[dcoa]

Thank you so much for your feedback, I appreciate it, and I completely agree with you. Part of my initial thoughts was avoiding to use a AuthZ module context because it will growth heavily and make a mess, instead up for a future specific context, that provides the basic information (that said the scoped library and the roles available) and validates the user permissions for the current view.

For the current MVP, we have two main views: a user list and a team member detail view (for editing/deleting roles). The context will support both views, primarily by providing permission-aware flag and role data. Based on your suggestion, I agree it makes sense to avoid including the library metadata (like the name) in the context. I’ll update the current PR to fetch it directly using a specific hook, as you recommended.

I’m also exploring options like using a route layout to hold the context, or preloading the data via @edx/frontend-platform and leveraging auth service caching (not sure if is good strategy). Still experimenting a bit with that, but open to ideas, for the future of the App.

[arbrandes]

Looks good to me!

[arbrandes]

This is great, thanks!

[dcoa]

sorry @arbrandes just a small change in this commit 7cb528b. Since display_name is optional on the platform, we've opted to use the username instead, at least for this first iteration.

[sarina]

@arbrandes - Diana isn't a CC on this repo. Are we awaiting another review here or can this merge?