UI: Conditional access - Microsoft Entra#27982
Conversation
cdb7ce2 to
63f9239
Compare
|
@sgress454 setting as draft per updated decision to merge with feature flag, will mark ready for review when that's implemented |
e69ad02 to
ff8a55b
Compare
| export const createMockLocation = ( | ||
| overrides?: Partial<IRouterLocation> | ||
| ): IRouterLocation => { | ||
| // Default values for the location object | ||
| const defaultLocation: IRouterLocation = { | ||
| pathname: "/", | ||
| host: "localhost:8080", | ||
| hostname: "localhost", | ||
| port: "8080", | ||
| protocol: "http:", | ||
| }; | ||
|
|
||
| return { | ||
| ...defaultLocation, | ||
| ...overrides, | ||
| }; | ||
| }; | ||
|
|
There was a problem hiding this comment.
Did you end up using this or IRouterLocation?
There was a problem hiding this comment.
Did not, but figured it might be useful to leave there for the future
| // These fields will never actually be changed here. See comment above | ||
| // IGlobalIntegrations definition. | ||
| zendesk: teamConfig?.integrations.zendesk || [], | ||
| jira: teamConfig?.integrations.jira || [], |
There was a problem hiding this comment.
why not ...teamConfig.integrations like you have above for globalConfig?
There was a problem hiding this comment.
Not sure, will update
There was a problem hiding this comment.
Oh, perhaps related to patch semantics? This way there will always be an [] in each of these
fields, whereas above they can be null
There was a problem hiding this comment.
Yea...looks like if one of this is null but the other is set, this logic will wipe out the
null field even if it already exists on the db. Definitely room for improvement on that PATCH
endpoint but that seems to be why, same as above.
| }, | ||
| }; | ||
| await teamsAPI.update(payload, teamIdForApi); | ||
| refetchGlobalConfig(); |
There was a problem hiding this comment.
why refetching global config here, and team config above? seems backwards.
edit -- the one above looks like it's for no team, not all teams... so if we set this up for No Team then we add it to the global config?
There was a problem hiding this comment.
Yep thanks for the catch, switching...
so if we set this up for No Team then we add it to the global config
That's right! Not the clearest system...
sgress454
left a comment
There was a problem hiding this comment.
A couple of questions but overall code looks really good, nice job on the different phases of the setup flow. Testing now 👍
| if ( | ||
| (!isManagedCloud && section?.includes("conditional-access")) || | ||
| featureFlags.allowConditionalAccess !== "true" | ||
| ) { |
There was a problem hiding this comment.
| if ( | |
| (!isManagedCloud && section?.includes("conditional-access")) || | |
| featureFlags.allowConditionalAccess !== "true" | |
| ) { | |
| if ( | |
| section?.includes("conditional-access") && | |
| (!isManagedCloud || featureFlags.allowConditionalAccess !== "true") | |
| ) { |
This is currently blocking the Integrations page completely if the feature flag is off -- you want it just for the conditional access section.
There was a problem hiding this comment.
Err, nothing to see here...😅
| ); | ||
| setIsUpdating(false); | ||
| toggleDeleteConditionalAccessModal(); | ||
| setPhase(Phase.Form); |
There was a problem hiding this comment.
Nit, we probably should be re-fetching the config here via the API, rather than trusting that this worked (like we do with GitOps mode). It's pretty low risk here since we should be able to trust our own backend when it says "this action was successful", but always better to be visualizing real data from the backend when we can.
There was a problem hiding this comment.
Great call. The omission may have been to allow testing with the fake data before the backend
actually works, since if we refetch the backend when it's not actually doing anything it won't lead
to the right phase. Will include this in the "fake data" commit.
There was a problem hiding this comment.
The goal here is for the page state to be driven by the state of the backend as much as possible. I realize that for certain parts of the process (like when the user is doing something on another site) we can't easily reach that goal. But for this case, I think we can by removing the setPhase(Phase.Form) here and moving it to the onSuccess of the config fetcher (contingent on the new config having microsoft_entra_connection_configured be false). Does that make sense?
There was a problem hiding this comment.
Maybe move the isUpdating(false) to there too, just to avoid an edge case of "config load takes a moment and user can do weird things in the meantime"
There was a problem hiding this comment.
Yes this makes sense
Support for this property was removed in #28245, which merged just before #27982. It's now causing linting errors. I confirmed that the Save button looks the same without it. <img width="793" alt="image" src="https://github.com/user-attachments/assets/f3357cd2-1c4f-4c91-8c2e-e56797fb86e9" />
Note - currently feature flagged. Build frontend with
ALLOW_CONDITIONAL_ACCESS=true NODE_ENV=development yarn run webpack --progress --watchto enable this feature. Also, all of this functionality depends on the newconfig.license.managed_cloudbeing true, so you'll need to mock that data somehow. This branch has the appropriate fake data for testingFor #27043, #27864
Build front end for Fleet's integration with Microsoft Entra, allowing conditional prevention of single sign-on for hosts failing any policies on a team
Trigger the integration
Triggered, but configuration still not verified
Verified, short and long tenant ids:
Verified –> Deleted
Enable for policies of a team
Activities
Unavailable for self-hosted Fleet instances:
Premium only
changes/