Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research best practices on creating API call to get all users who are listed as managers on a project #1769

Closed
2 tasks done
Tracked by #1737
JackHaeg opened this issue Oct 2, 2024 · 3 comments
Closed
2 tasks done
Tracked by #1737
Assignees
Labels
p-feature: API p-feature: User Permissions Feature includes how user access levels / user permissions will be implemented in the product role: devops size: 2pt Can be done in 7-12 hours

Comments

@JackHaeg
Copy link
Member

JackHaeg commented Oct 2, 2024

Overview

Currently, there is no way for admins to see a list of users who are project managers and which projects they are associated with on VRMS. Given that, we need to research how to create an API that will return a list of users with each entry corresponding to a project they manage.

Action Items

  • Research best practices for populating list of users who manage Projects, and list of projects User manages via user, using one source of data.
project: {
managers: [user1, user2]
}

User {
projectsManaged: [project1, project2]
}

Resources/Instructions

@github-project-automation github-project-automation bot moved this to New Issue Approval in P: VRMS: Project Board Oct 2, 2024
@JackHaeg JackHaeg added role: devops p-feature: API p-feature: User Permissions Feature includes how user access levels / user permissions will be implemented in the product size: 2pt Can be done in 7-12 hours labels Oct 2, 2024
@JackHaeg JackHaeg changed the title Create API call to get all users who are listed as managers on a project Research best practices on creating API call to get all users who are listed as managers on a project Oct 2, 2024
@ntrehan ntrehan self-assigned this Oct 8, 2024
@ntrehan
Copy link
Member

ntrehan commented Oct 13, 2024

@trillium @jbubar @bkmorgan3
I have done some research on how we can address this

I observed that the projects collection has a key called "managedByUsers" which contains a list of users that manage that project.
We want the inverse of that in the users collection, a list of projects managed by a particular user

There are two ways to go about doing this

Approach 1. Pure Query with no schema change - In this approach I can design a query that will initialize a map, scan through all the projects, and whenever it encounters a project that has users populated in the "managedByUsers" list, it will add the project name to the User's key

var userProjectMap = {};

db.projects.find(
  { managedByUsers: { $exists: true, $ne: [] } },
  { _id: 1, name: 1, managedByUsers: 1 }
).forEach(function(project) {
  project.managedByUsers.forEach(function(user) {
    if (!userProjectMap[user]) {
      userProjectMap[user] = [];
    }
    userProjectMap[user].push(project.name); // Add the project name to the user's list
  });
});

Approach 2 - Storing the data in the DB after a schema change.
In this approach we will do the same scan as the first method, but rather than keeping the data in a primary map, we will add a new field in the users section called "managedProjects" and store that data in the user collection
This data will be saved permanently and can be fetched quickly and more efficiently

db.projects.find(
  { managedByUsers: { $exists: true, $ne: [] } }
).forEach(function(project) {
  project.managedByUsers.forEach(function(user) {
    // Update the user document to add the project to the 'managedProjects' field
    db.users.updateOne(
      { username: user },
      { $addToSet: { managedProjects: project.name } } 
    );
  });
});

Advantages of Approach 1 - Can be quickly implemented right away without any schema/UI changes.
Advantages of Approach 2 - It will be faster in performance if the data grows in the future, and is the more elegant and maintainable solution

Things to consider when doing approach 2 - As we are adding a new key called "managedProjects for a user", we should be adding a field in the users section in the UI of the same name
It will list down the projects that the user is managing and the ability for the user to add more projects
Another thing to consider is, that when we add a user in the "managedByUser" list in a project, we should also add the project in the "managedProjects" in the user, and vice versa

Please let me know which approach I should go forward with, and then I can proceed with #1771
@JackHaeg

@JackHaeg
Copy link
Member Author

Per Monday's all team discussion, we have elected to go with Approach 1

@JackHaeg
Copy link
Member Author

Closing issue as completed, as research from @ntrehan has been discussed with team and solution has been identified.

@github-project-automation github-project-automation bot moved this from In progress to Final QA (product) in P: VRMS: Project Board Oct 15, 2024
@JackHaeg JackHaeg moved this from Final QA (product) to Done in P: VRMS: Project Board Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p-feature: API p-feature: User Permissions Feature includes how user access levels / user permissions will be implemented in the product role: devops size: 2pt Can be done in 7-12 hours
Projects
Development

No branches or pull requests

2 participants