Merge integrations and providers in user settings for the main providers

[gtsiolis]

Problem to solve

Currently, one user per instance can add a git integration.

User settings are split into two for provider and integration connections.

While, we could surface the user who added the integration when trying to add a new integration (see relevant comment), it could be useful to merge these two lists for users so that it's less confusing when they try to connect more providers.

Proposal

TBD (To be discussed)

In the meantime, we could consider merging Integrations and Providers in user settings for the main providers, as well as surface the user who added the integration, so that users can only see one unified list of providers. The list could surface also the user type for SaaS which is in our case an admin.

Benefits:

1. Users will see one list of providers they can connect
2. Users can still add more integrations (connections)

[jldec]

Git connections represent the list of git providers for which a user has been authorized to create workspaces.

Registered Git integrations are the hostnames configured to serve as git providers and should not be tied to one user.

The current design helps to get around the challenge of not having an "org-admin" role in Gitpod. It does not make sense to show all the configured git integrations to everyone, but it would be nice to show one or two custom integrations to everyone from the same organization. Unfortunately this is not straightforward without introducing another org layer.

Merging the two lists will not have the effect of revealing available providers to other users, because Gitpod does not currently track which users are allowed to connect to which custom providers.

[gtsiolis]

... and should not be tied to one user.

However, this is currently not the case.

It does not make sense to show all the configured git integrations to everyone ...

Agree. 💯

... but it would be nice to show one or two custom integrations to everyone from the same organization.

Could you clarify this a bit more?

Unfortunately this is not straightforward without introducing another org layer.

I think a simple approach to resolve this is to introduce integration management on a instance level as this could help apply on both SaaS and Self Hosted. In the case of Gitpod.io we would be surfacing the account used to generate the hard-coded tokens to set up the integrations for gitlab.com, github.com, and bitbucket.org.

For example, using the approach described above, on gitlab.com we could use our gitpod account or even our gitpod-io group to generate the tokens, and then surface the account or group in /integrations for everyone. I can create a design for this if it helps to clarify how this could look like.

... because Gitpod does not currently track which users are allowed to connect to which custom providers.

We could change that and bring visibility to this black box area of the product. Things we could try:

1. Surface relevant user information, see Only one user can have a custom git integration #5411 (comment)
2. Introduce connection visibility for instance admins
3. Introduce usage analytics for instance admins as well as control to revoke a stale connections (last used), if not automatically revoke after 1 year to follow our approach with garbage collection, etc.
4. ...

[AlexTugarev]

Some feedback we got internally.

While the original issue here is about improving UX and understanding the Git Integrations/Connections page. (Correct me if reduced it too much or wrong.)

We're getting feedback, that the Git Integrations (OAuth2 side of the medal) is expected to be on team level, because if would be the team owners who would manage them. Not being managed on a personal account is a wanted safety net.

Given that kind of feedback, we may want to leave OAuth2 integrations separate from the personal connections. W.r.t. improving the discoverability of possible connections, we would then be able to populate the list of providers by traversing the teams of a user.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gtsiolis]

This should be easier to resolve now with Gitpod Dedicated, as the Git integrations can live in the admin settings for each instance. Cc @jldec @lucasvaltl