Show team usage tab only for team owners #15350
Conversation
|
started the job as gitpod-build-gt-show-usage-tab-only-for-team-owners.2 because the annotations in the pull request description changed |
| if ( | ||
| currentUserInTeam?.role === "owner" && | ||
| (showUsageView || (teamBillingMode && teamBillingMode.mode === "usage-based")) | ||
| ) { |
There was a problem hiding this comment.
This would hide it from the UI, but leaves the APIs accessible. To actually restrict access, we need to change the APIs.
Would it make sense to continue showing it but show "You need to be a team Owner to access this view"? This helps with discovery, and action on what is needed to use it.
There was a problem hiding this comment.
This would hide it from the UI, but leaves the APIs accessible.
Oh, I didn't know that—thanks for the heads-up @easyCZ! 🏀
Would it make sense to continue showing it ...
We already show a message like this:
However, I see no benefit or much value for users to show this access wall, as there's not much (action) they can do to access, and it's causing more confusion than help.
Cross-posting from the issue description in #11588:
@gtsiolis: Promoting a feature by making the usage tab visible and making the feature inaccessible not because of the user's subscription, but because of their team role can be confusing as it will probably be impossible for a user to change their role as this contradicts the initial goal of having roles in teams. This issue will become more obvious for larger teams which usually require specific role access so that they can control data access, and more.
Cross-postng from the relevant discussion (internal):
@gtsiolis: Having this tab visible but not its content was a not-so-cool decision we took that we need to fix. I’ve also received negative feedback about this feature behavior in private conversations with other team members but we can fix this by either making this tab visible for all members or hiding the tab and improve usage attribution. ❗
I'd suggest to
There was a problem hiding this comment.
I understood that we are already returning an error on the API but still show the UI. So hiding the UI seems to be the right thing to do here. In anyway I'd say we should merge this PR and do additional follow up work separately.
There was a problem hiding this comment.
Thanks @svenefftinge, wasn't aware there's already a guard for this. Makes sense to proceed with this!
|
Thanks @svenefftinge! Opened #15361 to keep track of the discussion around API access, feel free to update or close if needed. 🏓 Cc @easyCZ |
roboquat
added
deployed: webapp
Description
Not sure if the code changes here will work, but this will attempt to fix #11588.
Any hints or help is appreciated. 🏀
See relevant discussion (internal). Cc @loujaybee
Related Issue(s)
Fixes #11588
How to test
Release Notes
Documentation
Werft options:
If enabled this will build
install/previewValid options are
all,workspace,webapp,ide,jetbrains,vscode,ssh