-
Notifications
You must be signed in to change notification settings - Fork 370
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
upcoming: [M3-7459] - Disable Contact / Billing Info for Restricted Users #10036
Conversation
}); | ||
|
||
// TODO: When we figure out issue with Vitest circular dependencies | ||
// vi.mock('src/queries/profile', async () => { |
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.
@jdamore-linode This is what we talked about earlier. This is not a critical test, so we'll revisit at Cafe. 👍
}; | ||
}); | ||
|
||
vi.mock('src/queries/profile', async () => { |
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.
@jdamore-linode To add to our investigation, oddly this causes no issues.
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.
Thanks again @jaalah-akamai! Still no explanation for why it doesn't hang here, but did confirm by upgrading Vitest that this Vitest PR fixed the issue.
Once this is merged I'll plan to open a PR that upgrades Vitest and re-enables the commented out test 👍
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.
I see the benefit of this approach to avoid dealing with loading states, but I don't think it's better than the MSW approach. Would like to discuss in cafe!
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.
I think your test steps have a typo in Observe the Edit and Add Payment Method buttons are disabled (by default we're in a parent state)
, which should be enabled.
I was able to confirm the following:
The disabled tooltips are read out via VO. See also the message I sent offline, but I may have not had the right key combination to be able to keyboard navigate away from the disabled Edit button - I can esc
out of the open tooltip, but trying to Tab
or Shift
+ Tab
keeps me on that button.
Pending that the above is not an issue to resolve, approving with a couple of small things to address. In addition to my comments, this PR will need a changeset.
Co-authored-by: Mariah Jacobs <[email protected]>
Ahh yes, it's a typo! 🔍 |
@mjac0bs This should be fixed now while still preventing disabled buttons from submitting forms as outlined here: #10028 (review) |
packages/manager/src/features/Billing/BillingPanels/ContactInfoPanel/ContactInformation.tsx
Show resolved
Hide resolved
const { data: user } = useAccountUser(profile?.username ?? ''); | ||
const isChildUser = | ||
flags.parentChildAccountAccess && user?.user_type === 'child'; |
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.
Do we have to use useAccountUser
? Is there no better way to get user_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.
@bnussman-akamai I don't think so, user_type
is a new field that's only returned from /account/users
or /account/users/:user
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.
I'll see if API could also return that field as part of /account
data.
}; | ||
}); | ||
|
||
vi.mock('src/queries/profile', async () => { |
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.
I see the benefit of this approach to avoid dealing with loading states, but I don't think it's better than the MSW approach. Would like to discuss in cafe!
Coverage Report: ❌ |
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.
Disabled states look and new logic look good!
Description 📝
Users with read-only access, should not have the ability to edit billing contacts or add payment methods. Currently, the "Edit" billing contact and "Add payment method" buttons are active for these types of users. While users receive denials via the API when trying to submit changes, this may creates confusion and frustration. To improve the user experience and align with intended permissions, it's necessary to disable these buttons.
Changes 🔄
Edit
andAdd Payment Method
will be disabled for "Indirect Customers" and those withread_only
account access.To edit this section, please contact your {administrator || business partner}.
Preview 📷
prod-contact-info.mp4
business partner
.How to test 🧪
Prerequisites
Reproduction steps
Verification steps
Edit
andAdd Payment Method
buttons are disabled.Edit
andAdd Payment Method
buttons are enabled (by default we're in aparent
state)parent
tochild
on this line: https://github.com/linode/manager/blob/develop/packages/manager/src/mocks/serverHandlers.ts#L1236Edit
andAdd Payment Method
buttons are disabled.child
toproxy
and observe theEdit
andAdd Payment Method
buttons are enabled.As an Author I have considered 🤔
Check all that apply