Return db user instead of Auth User in me endpoint.

[Sujanadh]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Related Issue

user_role was not updated in me endpoint. The default mapper role was passed, irrespective of other roles.

Describe this PR

This PR updates me endpoint, which returns dbuser with respective roles instead of authuser, as authuser doesn't possess any roles.

Screenshots

N/A

Checklist before requesting a review

• 📖 Read the FMTM Contributing Guide: https://github.com/hotosm/fmtm/blob/main/CONTRIBUTING.md
• 📖 Read the FMTM Code of Conduct: https://github.com/hotosm/fmtm/blob/main/CODE_OF_CONDUCT.md
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[spwoodcock]

This was an intentional choice at the start to prevent the extra database call, if it's not needed.

I'm assuming the frontend needs to store the role from one of: READ_ONLY, MAPPER, or ADMIN for something?

I'm not that confident in enforcing roles via the frontend - this is easily manipulated. Each endpoint we call has associated auth/role requirements anyway. It depends what the role is needed for 👍

[Sujanadh]

This was an intentional choice at the start to prevent the extra database call, if it's not needed.

I'm assuming the frontend needs to store the role from one of: READ_ONLY, MAPPER, or ADMIN for something?

I'm not that confident in enforcing roles via the frontend - this is easily manipulated. Each endpoint we call has associated auth/role requirements anyway. It depends what the role is needed for 👍

Yes, the frontend needs to know the role of the user for the verification tag in the organization list, which looks like this:

[Sujanadh]

Only superusers are allowed to view these tags.

[spwoodcock]

The organisation page is low priority for now, but I wanted to get some feedback related to #1234 @NSUWAL123 @Sujanadh @manjitapandey

The idea here is that we can distinguish more easily between verified and unverified orgs - which sounds great on paper.
The thing is, it complicates the logic (this PR will require two database calls whenever login_required is used in any other endpoint, and it also adds admin specific component flags in the UI).

The admin for FMTM is generally only one user, maybe a handful at most. They will generally be technically proficient, with access to the database etc.

Do we think it's necessary to make UI components and endpoints specific for admin users, when they can just update things via the database?

[manjitapandey]

I understand that if its only about super admin role and we are sure that we wont be needing it on future, calling two databases won't probably a good idea.
Can you provide any suggestions regarding?
Or else we can go through viewing the list from database directly per now until we come up with some alternative solution.

[spwoodcock]

If the user is an admin then all orgs are returned.

We just need to tag the unapproved orgs to give better oversight of that for the admin.

To do that we don't need to check if the user is admin, we only need to check if the org has approved=false (note that regular users can't list unapproved orgs from the backend).

Then in the future we can convert the tag to a button, so the admin clicks and it calls the approve endpoint.

Would that work?

[spwoodcock]

Closing unless a good use case is determined.

[spwoodcock]

Apologies, I stupidly closed this as it doesn't actually impact anything.
I was thinking this was for login_required, but it's actually on the /auth/me endpoint, so is absolutely fine to call the db (as we already do this anyway).