Skip to content

upcoming: [M3-7898] - Support ticket severity - #10317

Merged
hkhalil-akamai merged 22 commits into
linode:developfrom
hkhalil-akamai:M3-7898-support-ticket-severity
Mar 29, 2024
Merged

hkhalil-akamai merged 22 commits into
linode:developfrom
hkhalil-akamai:M3-7898-support-ticket-severity

Conversation

@hkhalil-akamai

@hkhalil-akamai hkhalil-akamai commented Mar 26, 2024 •

Copy link
Copy Markdown
Contributor

Description 📝

Adds Cloud Manager support for the upcoming support ticket severity changes.

Changes 🔄

  • APIv4:
    • Updated SupportTicket and TicketRequest types with new severity field
    • New Support Ticket Severity account capability
  • Cloud Manager:
    • New "Severity" column in support ticket list
    • Display ticket severity in ticket details status bar
    • Add severity select input when creating a new support ticket

Target release date 🗓️

4/15

Preview 📷

Before After
Severity column
Screenshot 2024-03-26 at 3 26 44 PM Screenshot 2024-03-26 at 3 26 55 PM
Ticket details
Screenshot 2024-03-26 at 3 28 25 PM Screenshot 2024-03-26 at 3 28 30 PM
New Ticket Dialog
Screenshot 2024-03-26 at 3 28 58 PM Screenshot 2024-03-26 at 3 29 15 PM

How to test 🧪

Prerequisites

  • Enable 'Support Ticket Severity' feature flag
  • Enable MSW

Verification steps

  • Navigate to Support > Tickets and verify that the 'Severity' column appears, displays each ticket's severity and can be sorted
  • Click on a ticket and verify the ticket's severity appears in the status bar at the top of the page
  • Click "Open New Ticket" and verify a severity can be selected
  • Hover over tooltip and verify copy (from ticket)

Note

As of 3/26, ticket severity is not supported by the API. Submitting a ticket will ignore the specified severity.

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

@hkhalil-akamai hkhalil-akamai added UX/UI Changes for UI/UX to review @linode/api-v4 Changes are made to the @linode/api-v4 package labels Mar 26, 2024
@hkhalil-akamai hkhalil-akamai self-assigned this Mar 26, 2024
@hkhalil-akamai
hkhalil-akamai requested a review from a team as a code owner March 26, 2024 19:37
@hkhalil-akamai
hkhalil-akamai requested review from jaalah-akamai, jdamore-linode and mjac0bs and removed request for a team March 26, 2024 19:37
Comment on lines +63 to +67
export const severityLabelMap: Map<TicketSeverity, string> = new Map([
[1, '1-Major Impact'],
[2, '2-Moderate Impact'],
[3, '3-Low Impact'],
]);

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.

Choosing to use a map here since integer-keyed objects are not well supported. For example, calling Object.keys converts the integer keys to strings.

@github-actions

github-actions Bot commented Mar 26, 2024 •

Copy link
Copy Markdown

Coverage Report: ✅
Base Coverage: 81.72%
Current Coverage: 81.72%

@mjac0bs mjac0bs 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.

Great work -- here's some UI feedback I have and a note that open-support-ticket.spec.ts is a legit failure that seems related to the Select component replacement work.

}
textFieldProps={{
tooltipPosition: 'right',
tooltipText: TICKET_SEVERITY_TOOLTIP_TEXT,

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.

Can we increase the width of this tooltip to make it easier to read?
Screenshot 2024-03-26 at 1 43 11 PM

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.

I agree but I can't figure out how to do this without changing the setting in the global theme. I tried using the tooltipClasses prop in conjunction with makeStyles as well as the sx prop but neither seem to have any impact.

Any suggestions or help in accomplishing this would be appreciated!! 🙏🏽

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.

This tooltip also gets cut off with certain screen sizes (mobile devices in landscape orientation) :/

I don't typically mind accepting minor UX sacrifices for mobile flows since I really don't think a lot of people are spinning up infrastructure on the go, but in this case I can see how it'd be important for a customer to be able to urgently open/view/respond to Customer Support tickets without having access to a PC or larger screen.

(My two cents is that this is really way too much content for a tooltip -- if it's so important that we need to inform customers of what these severity levels mean, and it takes 3 paragraphs to do it, I think this should text should just live in the ticket form rather than being in a tooltip)

@mjac0bs mjac0bs Mar 29, 2024 •

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.

I agree but I can't figure out how to do this

I honestly don't know either. We use tooltipClasses in a few places and pass in classes.tooltip, where we define a custom width, but that doesn't work in this case. It does look like tooltipClasses are getting passed in here, but applied to the popper, so I'm not sure if they're being handled correctly within TooltipIcon.

Comment thread packages/manager/src/features/Support/SupportTicketDetail/TicketStatus.tsx Outdated
Comment thread packages/api-v4/.changeset/pr-10317-added-1711481937702.md Outdated
Comment on lines +64 to +66
[1, '1-Major Impact'],
[2, '2-Moderate Impact'],
[3, '3-Low Impact'],

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.

This may just be a personal annoyance, but I wish we had spacing between the number and the impact (e.g. "1 - Major Impact"). Does anyone else feel the same?

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.

Yes, I agree, but I feel strongly that there shouldn't even be a number in the first place.

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.

Me too, but that seems to be something Support specifically requested. 🙃

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.

Let me circle back with an update

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.

Unfortunately, the numbers will have to stay for the time being so that we have parity with the implementation from other teams, but we can add spacing.

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.

@jaalah-akamai can you double check the verdict on spacing? From Andrew: "I originally had spaces between characters for the severity and removed them for absolute consistency with Akamai convention"

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.

Let's keep what we have for now as to not hold this up. We can revisit later

return;
}
setEntityType(e.value as EntityType);
setEntityType(type);

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.

Nice cleanup here

@hkhalil-akamai
hkhalil-akamai requested a review from a team as a code owner March 27, 2024 15:47
@hkhalil-akamai
hkhalil-akamai removed the request for review from a team March 27, 2024 15:47
@mjac0bs
mjac0bs self-requested a review March 27, 2024 17:13
@jdamore-linode

Copy link
Copy Markdown
Contributor

@hkhalil-akamai This is great! Planning to follow up with some test additions soon, but I'm noticing some inconsistencies with the severity autocomplete field compared to some of the other autocompletes in the app:

  • The severity autocomplete allows the user to enter an invalid value. I can type "asdf", press enter, and proceed with the ticket creation, but the UI never indicates that I've entered an invalid severity. When the ticket gets submitted, the "severity" field is omitted from the outgoing API request and the user isn't made aware. (Other autocompletes, like the Region select, seem to clear the user's input when they enter something invalid and move focus to another element)
  • Similarly, if I type "1", "2", or "3" into the field and hit "enter", I would expect it to automatically select the relevant severity, but instead it just leaves the typed value as-is. Contrast to the Region select autocomplete, where I can type "us-e", hit enter, and "Newark, NJ (us-east)" gets selected. The crux of the issue seems to be that the top autocomplete result isn't getting focused automatically.

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.

Thanks for updating these tests!

@hkhalil-akamai

Copy link
Copy Markdown
Contributor Author

@hkhalil-akamai This is great! Planning to follow up with some test additions soon, but I'm noticing some inconsistencies with the severity autocomplete field compared to some of the other autocompletes in the app:

Great observations and I agree that these negatively affect usability. Both are easily solved by adding the autoHighlight and clearOnBlur props, but I wonder if we should be enabling these by default across all Autocompletes?

@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.

Things look solid, just have a few concerns with styling / components

Comment thread packages/manager/src/features/Support/SupportTicketDetail/TicketStatus.tsx Outdated
Comment thread packages/manager/src/features/Support/SupportTicketDetail/TicketStatus.tsx Outdated
Comment thread packages/manager/src/features/Support/SupportTicketDetail/SeverityChip.tsx Outdated

@jdamore-linode jdamore-linode 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.

Awesome work, thanks again @hkhalil-akamai!

@mjac0bs mjac0bs 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.

Not sure what can be done about that tooltip text (and to Joe's point, I wonder what that would look like in the form) in the future, but that's a minor improvement we could revisit. Everything else looks good. 🚢

@mjac0bs mjac0bs added Approved Multiple approvals and ready to merge! and removed Ready for Review labels Mar 29, 2024
@hkhalil-akamai
hkhalil-akamai merged commit e4672e7 into linode:develop Mar 29, 2024
@hkhalil-akamai
hkhalil-akamai deleted the M3-7898-support-ticket-severity branch March 29, 2024 21:54
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! @linode/api-v4 Changes are made to the @linode/api-v4 package UX/UI Changes for UI/UX to review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants