Skip to content

feat: [M3-8335] - Link Account Limit ticket in more flows with error notice - #10684

Merged
mjac0bs merged 15 commits into
linode:developfrom
mjac0bs:M3-8335-add-account-limit-ticket-to-more-flows
Jul 19, 2024
Merged

feat: [M3-8335] - Link Account Limit ticket in more flows with error notice#10684
mjac0bs merged 15 commits into
linode:developfrom
mjac0bs:M3-8335-add-account-limit-ticket-to-more-flows

Conversation

@mjac0bs

@mjac0bs mjac0bs commented Jul 16, 2024

Copy link
Copy Markdown
Contributor

Description 📝

#10620 focused on the creation of the new account limit support ticket, linking to it from the Linode Create flow, and providing test coverage.

This ticket will link to the the account limit support ticket from the "contact Support" text on the Volumes, NodeBalancers, Firewall, Kubernetes (LKE create and Add a Node Pool), and Database create flows. Currently, the link in these flows takes users to a general support ticket.

Changes 🔄

  • Removes the global intercept on the text "contact Support" and "open a support ticket"
  • Links to an account limit ticket for Create flows listed above when the expected error text is present in the error message
  • Fixes a bug in a handleGeneralError Formik util that didn't account for the APIError reason being a string or JSX

Target release date 🗓️

8/5/24

Preview 📷

Videos 🎥
Flow Limit Error
Volumes
Screen.Recording.2024-07-16.at.2.04.16.PM.mov
NodeBalancers
Screen.Recording.2024-07-16.at.2.07.46.PM.mov
LKE Create - Thing Limit
Screen.Recording.2024-07-16.at.2.04.50.PM.mov
LKE Create - Rep Limit
Screen.Recording.2024-07-17.at.11.50.54.AM.mov
LKE Add Node Pool - Thing Limit
Screen.Recording.2024-07-16.at.2.06.47.PM.mov
LKE Add Node Pool - Rep Limit
Screen.Recording.2024-07-16.at.2.06.47.PM.mov
Firewalls
Screen.Recording.2024-07-16.at.2.08.42.PM.mov
Databases
Screen.Recording.2024-07-16.at.2.07.12.PM.mov

How to test 🧪

Prerequisites

(How to setup test environment)

  • Please test this on your dev account so we don't bother Customer Support with real tickets.
  • Check out this PR and switch your environment to dev.
  • Log into admin and be ready to change some things on your dev account.

Verification steps

(How to verify changes)

  • In admin, set your thing limit to 0.

  • For each of the above create flows (Volumes, NBs, LKE Create + Add a Node Pool, Firewalls, Databases):

  • Fill out the create form and try to create the entity.

  • Confirm that the UI displays an error notice when user has reached a limit on their account: You’ve reached a limit for the number of active services on your account. Please contact Support to request an increase and provide the total number of services you may need.

  • Click on the "contact Support" link and confirm that you are redirected to the Account Limit ticket and the expected fields show.

    • The Linode plan field should only show for Linode and LKE account limit tickets.
    • The correct entity should be shown in the "total entities" field, with the correct number of existing entities from your account as helper text.
  • For LKE only, setting your reputation to 0 should result in the error: A limit on your account is preventing the deployment of the selected service. To request access, please contact Support and provide the service name. You should also link to an account limit support ticket.

  • Verify that this test isn't flaking in CI:

yarn cy:run -s "cypress/e2e/core/helpAndSupport/open-support-ticket.spec.ts"

As an Author I have considered 🤔

Check all that apply

  • 👀 Doing a self review
  • ❔ Our contribution guidelines
  • 🤏 Splitting feature into small PRs
  • ➕ Adding a changeset
  • 🧪 Providing/Improving test coverage
  • 🔐 Removing all sensitive information from the code and PR description
  • 🚩 Using a feature flag to protect the release
  • 👣 Providing comprehensive reproduction steps
  • 📑 Providing or updating our documentation
  • 🕛 Scheduling a pair reviewing session
  • 📱 Providing mobile support
  • ♿ Providing accessibility support

@mjac0bs mjac0bs self-assigned this Jul 16, 2024
@mjac0bs
mjac0bs requested a review from a team as a code owner July 16, 2024 20:29
@mjac0bs
mjac0bs requested review from bnussman-akamai and hana-akamai and removed request for a team July 16, 2024 20:29
@github-actions

github-actions Bot commented Jul 16, 2024

Copy link
Copy Markdown

Coverage Report:
Base Coverage: 82.42%
Current Coverage: 82.5%

@mjac0bs
mjac0bs requested a review from a team as a code owner July 16, 2024 21:34
@mjac0bs
mjac0bs requested review from AzureLatte and removed request for a team July 16, 2024 21:34
Comment on lines +52 to +61
const generalError =
typeof _apiErrors[0].reason !== 'string'
? _apiErrors[0].reason
: _apiErrors
.reduce(
(result, { field, reason }) =>
field ? result : [...result, reason],
[]
)
.join(',');

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The misleading string type of _apiErrors was resulting in [Object object] being displayed to the user in any case where the error was already globally intercepted converted to JSX, as support errors were.

I'm proposing that we remove the global intercept for support tickets in this PR, but we still global intercept for verification and migrate errors, so I left the change in this util.

Comment on lines -106 to -115
{
condition: (e) => {
return (
(!!e.reason.match(/.*open a support ticket/i) ||
!!e.reason.match(/contact Support/i)) &&
!e.field
);
},
replacementText: <SupportError errors={errors} />,
},

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ultimately, I think we should remove this and handle support errors at the component level. As we begin to add more ticket types, it will depend on the context of the component which type of ticket we link to, so it is no longer useful to override at a global level to open a general support ticket. Additionally, our lack of type safety for a reason that is either string or JSX adds complexity and errors (see the [Object object] in Volume Create; another place this happens is the Configuration dialog when hitting a VLAN limit). We could mitigate these if we leave the construction of JSX to ErrorMessage.tsx and SupportTicketGeneralError.tsx.

If we do this here, in this PR, some API errors not covered in this PR will no longer link directly to a support ticket. If we're okay with that for now, we can proceed and create a follow up ticket to use ErrorMessage with general errors throughout the app - or at least where we think "contact support" API errors are likely.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm good with this! The interceptor solution was handy, but I'm much more sold on handling at the component level.

I remember @hkhalil-akamai saying we might even be able to remove the migration and verification interceptors as well because they might not be returned by the API nowadays, but I might be wrong. We can investigate that at a later point.

@AzureLatte AzureLatte left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Test passed

@bnussman-akamai bnussman-akamai left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks great! I like how we're handling errors at the component level now.

@hana-akamai hana-akamai left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

UI displays contact support error notice and expected fields show in the support modal ✅

Non-blocking: If it's not too complicated, what are your thoughts on replacing the word entity with the actual entity?
image

@hana-akamai hana-akamai added Approved Multiple approvals and ready to merge! and removed Ready for Review labels Jul 18, 2024
@mjac0bs

mjac0bs commented Jul 18, 2024

Copy link
Copy Markdown
Contributor Author

Non-blocking: If it's not too complicated, what are your thoughts on replacing the word entity with the actual entity?

@hana-linode That would be ideal, agreed. It felt like it would be more complicated than it's worth when I was first implementing, but I'll revisit now that this is a much smaller PR. 👀

@mjac0bs

mjac0bs commented Jul 19, 2024

Copy link
Copy Markdown
Contributor Author

Non-blocking: If it's not too complicated, what are your thoughts on replacing the word entity with the actual entity?

@hana-linode That would be ideal, agreed. It felt like it would be more complicated than it's worth when I was first implementing, but I'll revisit now that this is a much smaller PR. 👀

The way that we're converting special ticket type form fields into one description field makes this messier than I'd like. I'm going to hold off on it unless we get feedback from customers/Support that 'entities' is confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Approved Multiple approvals and ready to merge!

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants