[Canned reports][User management] Create Metabase users

[mahalakshme]

Need:

For self-service engineer persona: They can themselves setup users as well without needing Avni.
For implementation engineer persona: Reduced work for them.

AC:

• When toggle on is done on Reports -> 'Self-service reports', create 'Metabase users' group.
• When a user is added to this group, call Metabase api to create user(API link), and that user should receive the mail to set password
  - Add the user to the created group when the user is added to the Avni 'Metabase Users' group. If the group is not present then don't add the user to any group.
• When a user is removed from this group, disable the user - API link

Analysis notes:

• SSO is supported only in the Enterprise and Pro editions.
• Google sign-in - allows only one domain to be mentioned - but our users have n different domains
• we can do static embedding - but we can do this later when someone asks/pay us(we can switch to pro version) - to make sure it is really useful
• for now - we can just have a way to create users from Avni, and let them login into Metabase to check the reports

Questions:

How to manage when multiple groups created in Metabase? - I think we should not get into this groove.

Out of scope:

• UX improvements and error handling in old organisations - will be handled in separate card.
• Providing a Metabase link for them to login - comes under UX improvements - separate card

Old: Ignore

Technical suggestion:

• OAuth2 is inbuilt supported by Metabase only in the Enterprise and Pro editions. So the below can be done:
• Whenever a user is created in Cognito in a Metabase usergroup, using AWS lambda create a Metabase user with same credentials for that user
  • Configure a reverse proxy for Metabase, so all traffic to it is routed via the proxy
  • Use an OAuth Proxy tool like oauth2-proxy to handle the OAuth flow with AWS Cognito and login into Metabase.
• Static embedding of Metabase dashboards using Metabase secret key
• If the above is complex, find some technical approach to achieve the above.

•       - When 400 is returned, show error message 'Metabase user with this email address already exist.'
  

Useful links:

metabase/metabase#7662 (comment)

Inputs:

• superset
• create embedded dashboard - org-dashboard mapping - we want to a way for users to be able to go to Metabase and explore the data by themselves as well - so rejected -
  - go via the server - for URL authentication
• common login
• Login into Metabase should work with the credentials used in Avni
• Add the working code(no need to be integration) for the below in a branch
• Identify the risks and flows that might not work

---

• 2 sources of truths - what is disabled/enabled
• UX part - control over each part
• manage at one place at a time - Metabase - source of truth
• old organisation - make sure
• never pull data from Metabase and show in Avni
• something already exist - fail - handle - not proceed, error messager

[vinayvenu]

1. How do we rollout this functionality to existing users and organisations?
2. Eventually would we do this for Superset? If yes, would there be a difference in the way this functions?
3. For users who are reporting alone, are we still maintaining a userid for Avni?
4. What happens if someone removes the "Metabase users" group? Can it be removed?
5. Refresh tables is a long operation. How does creating reporting users work at this time?

[mahalakshme]

@vinayvenu
1.

Option 1:

Only Metabase users created via Avni will be here. Even in new organisations it is possible, someone might directly create users in Metabase, such users will not show up here. So email address conflict can happen for users who are already created in Metabase and when tried to again create in Avni - we can handle this.

Option 2:

Fetch metabase users and show up here. Can become complex when a user in Avni belongs to Metabase and other groups. More cases to solve

Will discuss the above options with the team.

2. Idea is to provide a way for self-service users to manage by themselves. So no plans for superset.
3. Yeah actually we can handle it differently by fetching users from Metabase. So we need not maintain really. But this might lead to complex edge cases. Will discuss in the meeting.
4. Currently Everyone and Administrators cant be removed. Similarly we can disable this
5. We will just create the group alone. Not users.

[mahalakshme]

@ombhardwajj Was doing some testing for this card, and found the below issue:

env: staging, org: JNPCT
When tried to add some@jnpct-test to Metabase users group, facing the below error:

[mahalakshme]

2 issues: @ombhardwajj

1. not getting added to Metabase group when added from Users page
2. In email showing as avni-prerelease-api-user

[himeshr]

@ombhardwajj Was doing some testing for this card, and found the below issue:

env: staging, org: JNPCT When tried to add some@jnpct-test to Metabase users group, facing the below error:

Resolved this by adding intermittent sleep between each step of Metabase setup, as this same request goes through successfully a few seconds later.

[himeshr]

In email showing as avni-prerelease-api-user

This is due to the fact that, we have configured the API Key with the name "avni-prerelease-api-user" in reporting-green environment. And the mail states that "avni-prerelease-api-user" has sent an invite to a user, requesting him to join Metabase.

The name of API Key can be modified as per need:

[1t5j0y]

1. DatabaseRepository.getDatabaseByName - Better to also match the dbUser for the org rather than just the org names
2. MetabaseService.getGlobalCollection - Fix exception message
3. AVNI_SELF_SERVICE_ENABLED flag name is misleading. It should reflect that this controls canned analytics / integration with metabase.
4. Not touched in the latest set of changes but not clear on the difference between /setup and /setup-toggle. Didn't find usages of /setup in the webapp
5. Add privilege check for /setup-toggle endpoint and other endpoints as required
6. webapp is passing an enabled query param to /setup-toggle which is ignored on the server
7. POST /userGroup - Not clear why we need to rely on order of request json and pick the first element here
8. UserController / UserGroupController / MetabaseController - check env var in addition to org setting to check if metabase calls should be made

[himeshr]

@1t5j0y Absorbed the review comments..

[1t5j0y]

Looks good. Pending comment 5 to add privilege checks for the end points.