Show helpful explanation when opening a workspace and the git provider integration is missing

[shaal]

@jldec Dec 1, 2021
I changed the title of this issue so that we can track the work on fixing the error popup
we are tracking the change to the login page in #6826

Bug description

When an anonymous user starts a Gitpod workspace of a project that is hosted on Github, they would get this generic login page (which is misleading)

They have 3 choices, but in reality they should only click on "Continue with Github" (because the repo is hosted on Github). Otherwise, the user would end up getting this error screen -

Steps to reproduce

1. Go to https://gitpod.io/integrations, make sure Github is NOT connected.
2. Sign out of Gitpod.
3. Open a repo that is hosted in Github (ie. https://gitpod.io/#https://github.com/shaal/DrupalPod)
4. When the login page shows up - click on "Continue with Gitlab"
5. Confirm you see the error page, that tells you to authorize with Github

Expected behavior

When the user open a Gitpod workspace link, and need to authorize Gitpod, only the relevant option should be displayed, the other options are misleading.
(Gitpod workspace project hosted on Github - should only display "Continue with Github" when the login screen shows up)

Example repository

(any repo)

Anything else?

No response

[AlexTugarev]

Thanks for reporting @shaal!

@gtsiolis, I think we discussed a possible solution for this situation when designing the login page. If the auth host can be inferred from the current context, we should emphasize the related provider in the list. AFAIK the only problem we didn't tackle at the time was to remember "known providers" in local storage on client side, just so that we can do better suggestions and avoid guiding users to create new accounts. Are the design docs still available?

[gtsiolis]

... they would get this generic login page (which is misleading)

@shaal I agree there is room to improve this page. For example, we could a) add some information about the context your are trying to open or b) highlight the previously used provider. See some early designs drafts below. 🎨

They have 3 choices, but in reality they should only click on "Continue with Github" (because the repo is hosted on Github).

@shaal In fact, they should use the one already associated with their account. Authrozing with another provider is a different step.

suggestion: Another improvement we could make here is to change the authrorization page so that it does not look like an error page. 💡

---

Are the design docs still available?

@AlexTugarev The designs can be found in the relevant discussion in #2629 (comment). Also, attaching here the same design.

issue: Inferring the provider from the context could lead to people running into the duplicate account issues, right? See #3950. Do you think could be ok here?

Login Context	Login Provider

[AlexTugarev]

issue: Inferring the provider from the context could lead to people running into the duplicate account issues, right? See #3950. Do you think could be ok here?

@gtsiolis this is a very good question!

well, we cannot completely avoid duplicate accounts if email addresses are different. also, it would help a bit to remember known accounts in local storage of the browser agent.

I believe we need to have compromise on that. the bad UX of signing up with the wrong provider in order to hit the UNAUTHORIZED wall again might be worse than dealing with a secondary account afterwards. especially if we can optimize and reduce the cases of the secondary account it would be a good trade.

[shaal]

I was thinking about this again, and I realized there could be a much better solution:

Once a user is logged in to Gitpod, it should not matter how they logged in (using Github / GitLab / BitBucket / etc).

A user should not be limited to any specific repo login, and can still open any repo (Just like I get run git clone of any public repo, from within a running Gitpod workspace).

[shaal]

Any update on this issue? It would help the adoption and reduce friction of DrupalPod.

My suggestion -
We should let people log into GitPod using Github, GitLab, or BitBucket, regardless of where the repository is hosted.

[jldec]

@AlexTugarev - Do we know enough after the user has logged in with the wrong provider, to make the error message more helpful, and let the user know that they need to create an integration with the 2nd git provider (matching the repo which they are trying to open a workspace on)?

[jldec]

We plan to limit the choice of buttons to the one matching the repo in #6826

But we also need to handle the case where you don't have an integration yet for the requested git provider (matching the repo being opened in a workspace) so we should try to tell the user to do that via the error message (see comment above)

[AlexTugarev]

first of, @jldec please be aware of the issue from #4696 (comment), where we might end up pushing logged out users to create a new account with a different provider.

on the #6826, which looks like a great improvement, I believe this must include a feature to remember existing provider connections on the frontend (e.g. in browser's local storage) to be considered before pushing to a login page with a not yet connected provider, just in order to avoid situations like the one mentioned above. otherwise we will see more cases with duplicate accounts, which isn't a bad UX after all.

said that, on your question, yes, once we let a user log in, we can tell which connection is missing. in addition to the connections, we also may check if it'd be helpful to create a new integration with a unknown provider.

[jldec]

@AlexTugarev i understand the extra new account problem but in this case new signups are also getting led into this error condition because we don't tell them that they probably should not signup using provider A to open a workspace on provider B, because if they do that they also need to add an integration for B.

I would like to use this issue to make the current error page (shown above) more informative, and less scary.

Instead of Oh No! Something went wrong!
We should say:

Could not open a Gitpod Workspace for <repo XXX>
The integration with <git provider> is missing.
Continue, to authorize a new integration for <git provider>
             [Continue]

[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.

[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.

[shaal]

There's still an issue, when opening a repo on self-hosted GitLab repo.
https://gitpod.io/#https://git.drupalcode.org/project/drupalpod

I'm getting options of login with Github, GitLab, BitBucket. And it can be very confusing for users.

[gtsiolis]

Thanks, @shaal! Some minimal viable changes that could land here in the provider authorization page:

1. Make the page look less than an error page
2. Provide a visual cue that the user has logged in

BEFORE	AFTER

Further improvements could include making the login page aware of the repository to be opened and informing users the users of the potential authorization access request after logging in with their Gitpod account. 💭

[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 is no longer relevant as users now go through the new new workspace flow which surfaces the missing Git connection added in #17159. Cc @svenefftinge @bhadreshdesai

Cc @shaal