[dashboard] fix onboarding modal show with workspaces exists

[mustard-mh]

Description

Go with origin proposal, onboarding Modal in /workspaces page will only show with

• User is onboarding user(not select IDE yet)
• No workspaces in /workspaces page

See also #9624 (comment)

Related Issue(s)

Fixes #

How to test

1. Go to /workspaces verify that the IDE selection modal is visible, do not interact with it, just close the browser tab
2. Launch a new workspace via /#<repo_url>
3. Go to /workspaces verify that the modal does not show
4. Delete your workspace created by step 2
5. Go back to /workspaces and verify that the modal is showing again

Release Notes

NONE

Documentation

[andreafalzetti]

Thanks for raising the PR 🙏

[mustard-mh]

@andreafalzetti Any idea what is workspaceModel?.searchTerm? Maybe it don't need to be a condition of <SelectIDEModal>

[andreafalzetti]

@andreafalzetti Any idea what is workspaceModel?.searchTerm? Maybe it don't need to be a condition of <SelectIDEModal>

I think it's the state for this search bar:

The search bar it's only visible when you have workspaces

[andreafalzetti]

/werft run

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.2
(with .werft/ from main)

[andreafalzetti]

/werft run with-vm=true

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.3
(with .werft/ from main)

[andreafalzetti]

/werft run without-vm=true

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.4
(with .werft/ from main)

[andreafalzetti]

LGTM

Tested, works as expected! 🚀

[laushinka]

Taking a look! @mustard-mh @andreafalzetti Should I run this without-vm?

[andreafalzetti]

Taking a look! @mustard-mh @andreafalzetti Should I run this without-vm?

I think for testing it works either way. The reason I've used without-vm is because with the changes to preview environment I was having issues connecting to the db with mysql-cli since the new approach required to SSH into the vm and I didn't know.

[mustard-mh]

FYI. Access VM preview environment k3s:

• Switch to correct branch i.e hw/fix-dashboard-onboarding-bug
• Exec ./dev/preview/install-k3s-kubeconfig.sh

Then, all steps (exec \ port-forward etc) like before

cc @andreafalzetti @laushinka

[mustard-mh]

/werft run

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.5
(with .werft/ from main)

[laushinka]

/werft run

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.6
(with .werft/ from main)

[laushinka]

/werft run with-vm=true

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.7
(with .werft/ from main)

[laushinka]

@mustard-mh I'm unable to access the preview env for some reason 🤔

[mustard-mh]

/werft run

👍 started the job as gitpod-build-hw-fix-dashboard-onboarding-bug.8
(with .werft/ from main)

[mustard-mh]

This PR has not committed for a long time, so platform team's job will delete this harvester(VM) preview environment every 30 mins 🥲 cc @laushinka @andreafalzetti

cron: "15 * * * *"

Every xx:15 https://github.com/gitpod-io/gitpod/blob/main/.werft/platform-delete-preview-environments-cron.yaml#L64

[mustard-mh]

I'll rebase it to origin/main to keep it fresh

[mustard-mh]

Werft job done 🎉 cc @laushinka

[laushinka]

Tested according to the steps. In step 5 I don't see a modal - is this the expectation?

[andreafalzetti]

Tested according to the steps. In step 5 I don't see a modal - is this the expectation?

Step 5 -> The modal should appear again, once you've deleted all workspaces. The concept is, if you've started a workspace, the modal should not be visible.

[laushinka]

Step 5 -> The modal should appear again, once you've deleted all workspaces.

@andreafalzetti I don't have any workspaces anymore and I don't see the modal reappear.

[gtsiolis]

The modal should appear again, once you've deleted all workspaces.

@andreafalzetti I could see the modal but is this intended or planned?

From UX perspective:

• If a user has seen or interacted with the modal once they should never be asked to select an editor again with the modal.
• Modals like these should be shown once either 🅰️ when entering any page in the dashboard or 🅱️ when starting a workspace (see [dashboard] increase IDE awareness for onboarding users when starting workspace #9663)

Sorry for hijacking this code review! 😇

[andreafalzetti]

Step 5 -> The modal should appear again, once you've deleted all workspaces.

@andreafalzetti I don't have any workspaces anymore and I don't see the modal reappear.

You have a defaultIde in your user preferences; (I've just checked in the DB), this means that you should not see the modal.

The defaultIde is also saved if you close the modal via the "X" -> in this case it defaults to code

EDIT: I've updated the PR desc "how to test" to make it clear what the expectations are

[andreafalzetti]

• If a user has seen or interacted with the modal once

@gtsiolis that'a the behaviour that this PR implements. Please check again the how-to-test section, it should be clearer 🙏

[gtsiolis]

@andreafalzetti

Ah, so this PR catches the edge case where a new user opens a repository via a gitpod.io/# URL but never visits the dashboard, the workspace gets garbaged collected, and when they visit the dashboard for the first time they see the modal, right?

However, this will no longer be necessary once we merge #9663, correct? I could be missing something but wondering why we are not merging #9663 instead. Maybe #9663 is far from being merged or the check we're adding in this PR needs to be in there anyway? 🤷

[laushinka]

You have a defaultIde in your user preferences; (I've just checked in the DB), this means that you should not see the modal.

Ah, I see. Would that defaultIde have to be removed from the DB for me to be able to test it again? 🙈

Update: I deleted my defaultIde from the DB, retook the steps and confirmed that I see the modal again.

[andreafalzetti]

However, this will no longer be necessary once we merge #9663, correct? I could be missing something but wondering why we are not merging #9663 instead. Maybe #9663 is far from being merged or the check we're adding in this PR needs to be in there anyway? 🤷

You have a good point @gtsiolis - For the long term, I cannot think of a current use-case where merging this - considering we'll soon merge #9663 - we add much value 🤔

In the shorter term, it could help prevent seeing the modal after you've already used a workspace once, which might have looked odd.

@mustard-mh what's your view on this? Shall we continue with this PR or abandon it?

[mustard-mh]

Initially, this PR was created as a quick fix for this bug, as it was simple to modify and would be much sooner than the PR #9663 for review.

In reality, both PRs have been in the review state for a long time.

if #9663 can be merged first, we can close this one.

Edge case (How to test section step 3) will cause this issue too, but it's really edge case, we can ignore it

cc @andreafalzetti @gtsiolis