-
Notifications
You must be signed in to change notification settings - Fork 367
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
feat: [M3-7529] β Support VPC in Personal Access Token drawer #10024
feat: [M3-7529] β Support VPC in Personal Access Token drawer #10024
Conversation
|
||
return tooltipText ? ( | ||
<Tooltip placement="top" title={tooltipText}> | ||
<span>{radioBtn}</span> |
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.
By default, tooltips do not activate on disabled elements. The workaround for this is to add a wrapper such as a <span>
. More details here.
β¦ in CreateAPITokenDrawer & ViewAPITokenDrawer
packages/manager/src/features/Profile/APITokens/CreateAPITokenDrawer.tsx
Outdated
Show resolved
Hide resolved
Coverage Report: β
|
const [basePermNameMap, setBasePermNameMap] = React.useState( | ||
_basePermNameMap | ||
); |
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.
Rather than having state for this, could we derive the value?
Would it work if we had something like getPermsMap
that would take basePermNameMap
and omit values as needed?
const basePermNameMap = getPermsMap(flags.vpc ? [] : ['vpc']);
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.
It can be derived. Avoiding the edge case I referenced previously would require having useRef
in the mix, but I don't think that edge case is valid at this time: with open beta, API is returning VPCs
in the account.capabilities
array for all users. That actually makes all of the conditional logic for the PAT unnecessary, but having some conditional logic just to be on the safe side until VPC enters GA wouldn't be bad.
So we could do a simplified approach like
// @TODO VPC: once VPC enters GA, remove _basePermNameMap logic and references.
// Just use the basePermNameMap import directly w/o any manipulation.
const basePermNameMap = getPermsNameMap(_basePermNameMap, {
name: 'vpc',
shouldBeIncluded: showVPCs,
});
where the VPC perm would get removed if showVPCs
was false. This would be vulnerable to the edge case, but that edge case would only come into play now if open beta got rolled back and we were testing with our DevTool (or the LD feature flag was toggled at the exact moment a user was interacting with this flow).
return () => { | ||
setBasePermNameMap(basePermNameMap); | ||
}; | ||
}, [open, showVPCs]); |
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.
We actually took a slightly different approach which I'm interested in hearing your thoughts. We actually removed them from the list of perms until it no longer needs to be feature flagged: https://github.com/linode/manager/pull/10040/files
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 noticed that and gave that approach a try earlier in the week, commenting out 'vpc'
in basePerms
and vpc: 'VPCs'
in basePermNameMap
in utils.ts
and adding the below (+ commenting out the current approach) in CreateAPITokenDrawer.tsx
:
if (showVPCs) {
const vpcScopeIndex = allPermissions.findIndex(
([scope]) => scope === 'vpc'
);
if (vpcScopeIndex === -1) {
allPermissions.push(['vpc', 0]);
}
basePermNameMap.vpc = 'VPCs';
}
It resulted in some weird behavior though where the scope for VPC doesn't appear until another scope is clicked on:
Screen.Recording.2024-01-11.at.1.05.10.PM.mov
Since GA isn't far off and because API is returning VPCs
in account.capabilities
for all users, I'm leaning towards the simplified approach I described in my previous comment
Looking into the unit test failures for |
Spent some time looking into these and haven't reached a solution -- the failed assertions basically say the VPC line/element cannot be found, but based on the flags/mock data and logic in the underlying components, that shouldn't be the case. Could I get a double-check on those in case I happened to overlook something? @bnussman-akamai @jaalah-akamai |
if (basePermNameMap[perm.name] && !perm.shouldBeIncluded) { | ||
delete basePermNameMap[perm.name]; | ||
} | ||
|
||
return basePermNameMap; |
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.
This should fix the unit test failures:
if (basePermNameMap[perm.name] && !perm.shouldBeIncluded) { | |
delete basePermNameMap[perm.name]; | |
} | |
return basePermNameMap; | |
const modifiedBasePerms = {...basePermNameMap}; | |
if (modifiedBasePerms[perm.name] && !perm.shouldBeIncluded) { | |
delete modifiedBasePerms[perm.name]; | |
} | |
return modifiedBasePerms; |
When the ViewAPITokenDrawer
and CreateAPITokenDrawer
components call this function, they both pass a reference to the basePermNameMap
constant that's defined and exported at the top of this module.
Because the first several tests in CreateAPITokenDrawer.test.tsx
and ViewAPITokenDrawer.test.tsx
do not have VPC enabled, when getPermsNameMap
gets called it's mutating the basePermNameMap
object by deleting the vpc
property. When subsequent tests import basePermNameMap
, the vpc
property has already been removed and as a result is excluded from the getPermsNameMap
function's output and so the VPC permission is not rendered. You can test this by moving your tests to the top of their .test
file; as long as they run before other tests where the vpc
flag would be disabled, they'll pass.
I think you could fix this a couple ways but the suggestion above does it by ensuring that getPermsNameMap
returns a new perm map rather than mutating the given map.
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.
π That makes sense, thanks for taking a look and for the explanation!
Changes are looking good. Should we fix |
I'll create a ticket and update this separately π |
Description π
If VPCs should be displayed in the app (based on customer tags or feature flag), display a scope for VPCs in the Access Token drawers (
My Profile
>API Tokens
> theCreate
&View
drawers) also.To-Do
Changes π
AccessCell
to take an optionaltooltipText
prop so we can display tooltip for disabled "Read Only" cell for VPC scopeCreateAPITokenDrawer.tsx
andViewAPITokenDrawer.tsx
so there's a VPC line item only if VPCs should be displayed in the app based on customer tag or feature flagPreview π·
Screenshots
Add Personal Access Token drawer:
View Scopes drawer:
How to test π§ͺ
Prerequisites
Verification steps
These changes should be confirmed both with and without the proper VPC tag. In the latter case, we want to test by toggling the VPC feature flag in the DevTools on and off to ensure the expected behavior is observed.
Toggling the feature flag on and off in the middle of testing should result in immediately observing the expected behavior once the drawer is re-opened
As an Author I have considered π€