[usage] Use workspaceClass displayName in Usage view

[laushinka]

Description

This uses the displayName instead of the id

Note: This shows `Default` because it's using the preview env config.

Related Issue(s)

Relates #13362

How to test

1. Join this team OR create your own team with the name "Gitpod" (uppercase 'G') and run some workspaces.
2. Check out the /usage page and see the workspace class name.

Release Notes

NONE

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide

[werft-gitpod-dev-com]

started the job as gitpod-build-lau-credits-info-13362.2 because the annotations in the pull request description changed
(with .werft/ from main)

[easyCZ]

This should show the workspaceClass as a fallback when the workspace class is no longer defined. The usage records go very far back in time so it's possible a class no longer exists when we're looking at usage history.

[laushinka]

Ah, good point!

[laushinka]

Fixed

[easyCZ]

/hold for Q

[easyCZ]

While this fixes the issue, it does result in reliance on the supportedClasses call. This is not a problem in itself, but if someone wanted to consume the API, and get all of the data, they wouldn't now have the display name populated.

It would be nice to also extend the UsageRecords response to include the supported class there. This would involve populating it when we read out the usage records from the DB, or even populating those in the DB at the time of usage record creation.

Is it possible to maybe show the ID as a tooltip of the workspace class? Or somehow show both the WorkspaceClassID and the WorkspaceClassName? We use the ID in other places so I expect it should remain accessible somehow. CC @gtsiolis

[laushinka]

Thanks for the 👍🏼 @easyCZ!

It would be nice to also extend the UsageRecords response to include the supported class there.
We use the ID in other places so I expect it should remain accessible somehow.

These are good nudges and also invites a bigger question for me: what consistency would we like to show the user? As you correctly linked the id being used in the gitpod.yml, we show the displayName instead in the account preferences for users to select. If I understand correctly, the preference view was why this issue was created, so that users can see that what they selected is correctly reflected in the usage list.
But it's good to rethink what we want to actually achieve here.
Also cc-ing @jldec in this thread.

Meanwhile I will unhold as this decision is not a blocker for the PR, and we can have follow-up issues from here.

/unhold

[gtsiolis]

Thanks for the ping @easyCZ! 🏓

Some thoughts:

1. From a UX perspective, I'd avoid the tooltip if possible for accessibility reasons, and more. This could be something to consider while improving the workspaces list, see Improve workspaces page #12033. Cc @jldec
2. I'd think that going with the ID is preferable and more scalable, but this will become clearer as the product matures and we add more workspace classes that we also need to surface in the dashboard, which could force us to move away from relying on the display name. 🌱
3. The PR linked above (Cc @Furisto @atduarte) is still pending and there's an ongoing discussion to skip adding this configuration in .gitpod.yml altogether, see Allow specification of workspace class in project settings #10963 (comment) (Cc @svenefftinge) and relevant discussion (internal) (Cc @atduarte).