-
Notifications
You must be signed in to change notification settings - Fork 66
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
Provide proactive feedback when trying to change team type to incompatible type #4378
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4378 +/- ##
==========================================
- Coverage 78.17% 78.12% -0.06%
==========================================
Files 295 295
Lines 13985 13994 +9
Branches 3159 3163 +4
==========================================
Hits 10933 10933
- Misses 3052 3061 +9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Have added basic coverage to verify the UI blocks changing to a 'lower' type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy with the code.
Do we have a team on prod that we can verify this after it is deployed?
@Steve-Mcl do we want to merge this and then I can test it? |
@hardillb - yes, fine by me Ben |
Verified on Staging where I had a Teams, team with more users and instances than allowed in starter. |
Closes #4377
This provides better feedback if a team upgrade is blocked due to the current usage exceeding any limits on the target team.
My first iteration was to add the check on the backend for the path where a team is setting up billing - it was already handled for the case of changing type when billing is already setup. This ensures any issue is reported before they are sent to stripe.
However, the feedback isn't great - and would be better to be more proactive in the UI. So the second iteration (3rd commit) copies the limit checks into the front end and lets us show a more helpful message to the user:
The specific errors shows above are based on how I happen to have my Starter team type setup locally; so don't get distracted by the specific numbers.
Also need to highlight the checks are based purely on Members/Device/Instance count limits. It doesn't check if they are using features (eg Team Library) that are unavailable at the target tier. We don't maintain flags on feature usage within a team, so that's out of scope (and not proposing it comes into scope any time soon).
There is currently limit test coverage for this. We're missing base coverage in a couple different areas here for the existing code.
I have added basic verification the UX blocks changing to a team that is not compatible with current usage - but it isn't exhaustive.