User permissions search

[vorleakyek]

Fixes #1801

What changes did you make and why did you make them ?

• Identified and removed all instances of dummy/placeholder data from the "User Permission Search" screen and filtered permissions data component.
• Updated MongoDB query to return a list of projectLead to match the frontend required data as suggested by Trillium
• Hook up the previously created APIs from
  • Added an API that fetches all the admins #1774 and 1771 - API for Fetching Project Managers  #1799
• Ensure the API responses are correctly mapped to the UI elements and behave as expected.
• Note: Unit test will be considered later once these changes are approved

Screenshots of Proposed Changes

Visuals after changes are applied

[vorleakyek]

@ntrehan, @jng34, and @trillium, please take a look at the changes when you have some time and let me know if there is anything I should change in the code. Thank you!
cc: @JackHaeg

[JackHaeg]

@trillium please prioritize this PR review if possible :)

[jng34]

The GET requests work as expected. The code and comments are detailed. Integration looks good!!

[trillium]

Looking good! Needs a change to the StyledButton nav element:

// client/src/components/Navbar.jsx
<StyledButton component={NavLink} to="/users/permission-search" />

Reasons referenced in comments within that code block

[trillium]

Hey hey, this added nav is resulting in an empty nav element.

Can we remove this line? Results in looking like this:

[vorleakyek]

Thanks for pointing that out @trillium!
I made the changes. Please take another look.

[JackHaeg]

@vorleakyek When using the "Project Leads" search, can a user also search for a project name and get a list of users who are linked to the project that has been searched?

[vorleakyek]

@JackHaeg, as discussed in the meeting, the current search for the project lead is based on the "name or project". So, searching for name or the project name would look like this. Thanks!

[trillium]

Chiming in here to note that there's still some issues with how this is all coming together. To be clear, @vorleakyek this isn't on you. I think there are some missing TODO items that we need to also reference. I'll add them to the epoch.

When a user is navigated from permissions search it isn't brining up the projects they're listed as leads on. That is only showing up when we navigate via User Search

file: client/src/components/user-admin/UserManagement.jsx

[vorleakyek]

Thanks for pointing that out, @trillium! So, this issue will be handled in a follow-up ticket. Is that correct?

[JackHaeg]

@vorleakyek I just spoke with @trillium and we'd prefer for this fix to be completed as part of the existing issue / PR. I have created an additional To-Do item on the original issue that follow's Trillium's feedback above.

Please let us know if you have additional questions or concerns! Also, great work on this so far - we are super excited to get this feature into the product :)

[vorleakyek]

@JackHaeg, okay. I'll take a look later this week. Thanks for the confirmation!

[trillium]

Hey @vorleakyek , it looks like you've passed setUserToUdit into UserPermissionsSearch already. I'm not sure why it isn't applying correctly yet, taking a look now.

[trillium]

Looking into this, I think I've found the problem:

The API is returning project names, not project IDs in UserPermissionSearch

But in the user window that renders projects it returns project IDs

UserToEdit expects an array of projectId and is getting an array of projectName so it isn't displaying any of the projects

[trillium]

File in backend/controllers/user.controller.js at UserController.projectLead_list needs to return both name and projectId

Frontend needs to adapt to manage an object that has { name: string, projectId: string } format.

[vorleakyek]

Thanks for finding the issue, @trillium!
I'll update the data returned from the API and adjust the frontend accordingly.

[vorleakyek]

@trillium, do you think we should include the isProjectLead and managedProjectNames properties in the API that fetches all the admin as well? Or it's okay to only return them in the project lead API? I was able to make it work on the frontend. But, I want to check if both APIs should return the same data structure by having all the same properties. Please take a look at the current changes. Thanks!

cc: @JackHaeg

[JackHaeg]

Per @trillium - Based on your recent Slack conversation, please reach out to Nikhil (@ntrehan) for additional information. Trillium stated that he trusts your decision to get the API working and moving forward.

[vorleakyek]

@ntrehan, @jng34, could you please take a look at the latest changes in the PR? Thanks!

[jng34]

Should you return (push) the projectId in addition to the name?

[vorleakyek]

@jng34, The projectId is already included as part of the admins data. So, I think we don't need to push it.

The API for the admins is returning this data object

The API for the project leads is returning this data object

So, I want to check if we should include the isProjectLead and managedProjectNames properties in the API that fetches all the admin as well?
Thanks for taking a look at the code.

[jng34]

@vorleakyek
I'm having trouble running the changes locally on my end.
However, the new code addressed the proposed changes as far as I can tell!