Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When starting a workspace but usage attribution is unclear, prompt for explicit user choice #11777

Merged
merged 1 commit into from
Aug 5, 2022

Conversation

jankeromnes
Copy link
Contributor

@jankeromnes jankeromnes commented Aug 1, 2022

Description

When starting a workspace but usage attribution is unclear, prompt for explicit user choice.

Possible unclear situations:

  • User is a member of multiple teams with usage-based billing enabled
  • User explicitly chose to attribute to a team, but they've since left this team (or the team was deleted, or its subscription was cancelled)

Related Issue(s)

Fixes #11579

How to test

  1. Start a workspace on any repo (should work)
  2. Create a team called "Gitpod" (or "Gitpod 1", "Gitpod 2"... whichever is available) to enable the Usage-Based Billing flag
  3. Start a new workspace on any repo (should work)
  4. Upgrade your team to Usage-Based Billing by adding a payment method (e.g. 4242 4242 4242 4242, 4/24, 424)
  5. Start a new workspace on any repo (should still work)
  6. Create a new team (called anything you want)
  7. Start a new workspace (should work)
  8. Upgrade your second team to usage-based billing
  9. Start a new workspace -- this time it should fail (unclear which team to bill) and ask you for an explicit choice
  10. Select your second team -- this should retry the workspace start, and succeed
  11. Delete your second team
  12. Start a new workspace -- this time it should fail again (explicit choice is no longer valid) and ask you for a new choice

Release Notes

NONE

Documentation

Werft options:

  • /werft with-preview
  • /werft with-payment

Copy link
Contributor

@andrew-farries andrew-farries left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR description doesn't seem to match the code 😄

AIUI this PR just removes the automatic attribution when a team signs up for Stripe.

components/server/src/user/user-service.ts Outdated Show resolved Hide resolved
@jankeromnes
Copy link
Contributor Author

jankeromnes commented Aug 1, 2022

Whoops, this was meant to be a Draft. 😅 Thanks for the quick review though @andrew-farries! 🙏

@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-jx-attribution-prompt.3 because the annotations in the pull request description changed
(with .werft/ from main)

@roboquat roboquat added size/L and removed size/M labels Aug 2, 2022
@jankeromnes jankeromnes force-pushed the jx/attribution-prompt branch 2 times, most recently from 270cfbb to 76098d7 Compare August 2, 2022 14:42
@roboquat roboquat added size/XL and removed size/L labels Aug 2, 2022
@jankeromnes jankeromnes marked this pull request as ready for review August 3, 2022 12:55
@jankeromnes
Copy link
Contributor Author

jankeromnes commented Aug 3, 2022

@gtsiolis If you have some time, could you please provide some advice on the UX? 🙂

I went with a very basic, non-dismissible Modal, but it's still quite rough:

When Starting a Workspace User Billing Settings
Screenshot 2022-08-03 at 15 05 47 Screenshot 2022-08-03 at 15 06 43
Screenshot 2022-08-03 at 15 06 09 Screenshot 2022-08-03 at 15 06 26

@jankeromnes jankeromnes requested a review from a team August 4, 2022 06:54
@jankeromnes jankeromnes changed the title [server] When starting a workspace but usage attribution is unclear, prompt for explicit user choice When starting a workspace but usage attribution is unclear, prompt for explicit user choice Aug 4, 2022
@gtsiolis
Copy link
Contributor

gtsiolis commented Aug 4, 2022

Looking at this now! 👀

UPDATE: Posted some thoughts in a relevant discussion (internal).

export function BillingAccountSelector(props: { onSelected?: () => void }) {
const { user, setUser } = useContext(UserContext);
const { teams } = useContext(TeamsContext);
const [teamsWithBillingEnabled, setTeamsWithBillingEnabled] = useState<Team[] | undefined>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jankeromnes, I bet this is not the single place, where we'd need this kind of info. have you considered promoting this flag to the result of getTeams? team.isBillingEnabled would be nice and it shave off the additional requests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AlexTugarev I think this would be premature, because:

  • I can't imagine other places that will need the same information currently (note: this billing account selector component is already reusable, and in fact it's already used in two places)
  • I don't think it's wise to make getTeams load all the team subscriptions on every call, even when most callers don't need that currently

export const PAYMENT_ERROR = 450;

// 455 Invalid cost center (custom status code)
export const INVALID_COST_CENTER = 455;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we agree on a common prefix for everything payment related, please?

also see https://github.com/gitpod-io/gitpod/pull/11576/files#diff-3bb6d890c14ac42bf9860578a9f6a85ffd0121dbf980055baa99f8b7731c46daR45

and feel free to comment on that BTW!

alternative way to approach this, we could use just PAYMENT_ERROR (in similar cases) and encode specific conditions into the payload. it feels like we'll have the needs to extends for more error modes. wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see much value in aligning every payment-related error around a single prefix or error code range (apart from readability of the error codes list -- which we arguably don't read that often).

Personally, I'd prefer to leave this as is (unless you have a strong opinion towards a different error name or code), and you can use whichever convention seems best in your PR. We can always align later if you think it's valuable, but I suspect that aligning these is not important in the grand scheme of things. 😇

@jankeromnes
Copy link
Contributor Author

jankeromnes commented Aug 5, 2022

Thanks for the reviews!

I guess this is now ready to be merged, unless you have any final requests. 🙂

@jankeromnes jankeromnes requested a review from a team August 5, 2022 08:42
}
}

protected async findSingleTeamWithUsageBasedBilling(user: User): Promise<Team | undefined> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: This can also come out of BillingMode: we already gather the data there, and only need to loop it through.

But that's improvement after both got merged.

@@ -231,12 +294,18 @@ export class UserService {
async getWorkspaceUsageAttributionId(user: User, projectId?: string): Promise<string | undefined> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, and out-of-scope here: It feels like this method (and it's descendants) do not necessarily belong into UserService, but more into usage/Attribution or so. But that's sth for later. 🙃

@geropl
Copy link
Member

geropl commented Aug 5, 2022

@jankeromnes testing this now...

@geropl
Copy link
Member

geropl commented Aug 5, 2022

On re-start, the chooser is not shown, but instead I see the plain error:
image

I think that's what we discussed earlier, and part of a follow-up PR.

Copy link
Member

@geropl geropl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM, tested and works 🛹

Error message is not nice, but does not harm prod, and can be a follow-up. 💯

@roboquat roboquat merged commit 1e909ba into main Aug 5, 2022
@roboquat roboquat deleted the jx/attribution-prompt branch August 5, 2022 11:12
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Aug 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production release-note-none size/XL team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adjust usage attribution to prompt users when attribution is ambiguous
6 participants