Provide organisational admins with ODK credentials if needed

[manjitapandey]

Is your feature request related to a problem? Please describe.
Followed by discussion on slack, Any organisation admins should be able to choose HOTOSM as an organisation to create a project.

Why would people do that
Sometimes an organisation may not have their own odk central server for storing submissions. In those cases, they can create an organisation but can choose HOTOSM as an organisation during project creation so that submission would be stored on HOTOSM odk server. Although, they should be admin of any organisation to be able to do so since only organisation admins should be able to create projects.

We may have further discussion in long term regarding this. May be they can still use their organisation details but use HOT's odk central.

[spwoodcock]

If the user is already an org admin, then instead of giving them access to the HOTOSM org, couldn't we just provide them their own creds for odk.hotosm.org?

In the org creation form, if the user provides their ODK server creds, we insert them in the db and use them.

But if the user provides no ODK creds, we can create them automatically on our server (after the org is approved).

The API for this is here https://docs.getodk.org/central-api-accounts-and-users/
(we probably need two endpoints, to create a user, then upgrade to admin permission - required for FMTM to work properly I believe).

[spwoodcock]

A follow up issue to this, users should be able to request to join organisations (we don't always want a new org).

[Sujanadh]

I don't think it's a good idea to provide credentials or create new credentials to odk of HOT, doing that will give them access to every project data that HOT has. Instead, we may just allow them to use existing credentials without letting them know it?

cc: @ramyaragupathy

[spwoodcock]

That is a good point, and is really an issue with a broken permission model in ODK (only two options: either admin or standard user 'mapper').

I guess this is a matter of trust and if we can accept:

• As @Sujanadh says, the credentials will be 'admin' level creds on odk.hotosm.org, meaning the user could in theory access to all projects there if they have the credentials / password.
• However, (1) only the org admin will have access to the credentials (can we trust the org admin? likely yes).
• (2) The org admin will not typically see the credentials (they can't access the password to directly login via odk.hotosm.org):
  • They are stored encrypted in our database, and only accessed during project creation.
  • When getting the org details via the API, we only include the URL and user in the response, no password.
  • Hopefully there is nowhere we have missed this and the ODK password is exposed in the API.

So with the above said, I personally think it's acceptable to provide admin level credentials to org admins in FMTM, as they shouldn't have access to the password themselves.

(it does open up other complications, such as how they can view the data in tools like PowerBI via the the OData endpoints, but we can address this later. Perhaps we need to relay the OData endpoints via the FMTM API).

[spwoodcock]

@Sujanadh can you think of anywhere else the ODK credentials may be exposed in FMTM?

I'm pretty certain we don't return any response with the ODK password.

I think the creds are only used for the ODK Central calls via the backend, meaning the user can't see those (they simply see the response from the API after).

[Sujanadh]

Yes, we don't expose the ODK password in any API response. It is all handled from the backend during ODK central calls.
Regarding odata to view data in PowerBI, we had discussion internally @manjitapandey and thought of providing odata endpoints via fmtm like you mentioned.

[spwoodcock]

Thanks for the sanity check!

Your message made me reflect a bit more on why we might want separate ODK users for each org.

Looking into the ODK Central database, it doesn't even seem like users are linked to projects internally. So it probably makes no different which user creates or modifies an ODK project, as long as they have admin permission (if we could filter projects by the user that created them, then perhaps it would be useful, but I can't see an easy way to do that).

With this said, perhaps we just duplicate the svcfmtm user creds for all FMTM usage, as it makes our lives a bit easier (instead of maintaining many different user credentials).

[spwoodcock]

Follow on from #1951

So to summarise what needs to be done:

• If user provides ODK creds at org creation, then insert them.
• If the user provides no ODK creds, then copy the HOTOSM org ODK creds from the db and insert them.