NoMongo: ADMIN OrgPeople Page

[rahulch07]

Is your feature request related to a problem? Please describe.
Refactoring orgpeople from MonoDb to Postgres endpoints

Describe the solution you'd like
admin should be able to to see organization people and Manage them.

Additional context

Potential internship candidates

Please read this if you are planning to apply for a Palisadoes Foundation internship

• Student Internship Programs talawa#359

[rahulch07]

please assign

[rahulch07]

@palisadoes I would like to clarify some concepts. Could you please provide your insights

1. We have:
   Admins - to manage organization (not specific to any org),
   Member - Person registered to that specific organizatioion( i.e present in organization_memberships table in postgres database)

User - Any person in users table is user irrespective of org he is member of? Also unable to find query that fetches records in users table

[palisadoes]

That is correct.

If there isn't a user query, then it'll need to be created. The query must have been missed by @xoldd

[rahulch07]

@palisadoes made a query on api which fetches all the users.

But had some doubts regarding frontend functionality. Please answer these questions so that i can make changes in query accordingly.

1. Currently this table displays all the user. Is this the intended functionality or should it have pagination?

2. Currently, entering a name in the search bar triggers a new query to the database.

Would this be the right approach, or would it be more efficient to handle filtering on the frontend, especially if organizations have only a few hundred users? In such cases, fetching the data once and applying client-side filtering could reduce server load and improve responsiveness.

I’m trying to think in terms of scalability and would like to hear your thoughts on this.

[palisadoes]

1. If you have hundreds or thousands of users then filtering in the client after search is a bad idea. This is part of the reason why the event calendar in develop takes so long to load.
2. Filtering should be done in the API as much as possible
3. We should have pagination
4. There is a lot of refactoring to do in Admin. Start with this issue.

[rahulch07]

1. If you have hundreds or thousands of users then filtering in the client after search is a bad idea. This is part of the reason why the event calendar in develop takes so long to load.
2. Filtering should be done in the API as much as possible
3. We should have pagination
4. There is a lot of refactoring to do in Admin. Start with this issue.

understood the approach...working on it. And I would work on events after this