feat: add client-side RemoveMultipleOrgUsersMutation

[tianrunhe]

Description

Following up #10675, this PR is the client-side mutation

Final checklist

• I checked the code review guidelines
• I have added Metrics Representative as reviewer(s) if my PR invovles metrics/data/analytics related changes
• I have performed a self-review of my code, the same way I'd do it for any other team member
• I have tested all cases I listed in the testing scenarios and I haven't found any issues or regressions
• Whenever I took a non-obvious choice I added a comment explaining why I did it this way
• I added the label Skip Maintainer Review Indicating the PR only requires reviewer review and can be merged right after it's approved if the PR introduces only minor changes, does not contain any architectural changes or does not introduce any new patterns and I think one review is sufficient'
• PR title is human readable and could be used in changelog

[Dschoordsch]

Did not test

[Dschoordsch]

Wow, that's quite convoluted. From reviewing this I get the impression that removeOrgUser should be half-broken currently.

[tianrunhe]

Hey @Dschoordsch , thanks so much for taking time to review this. I agree it's quite complicated and it also makes me wonder if removeOrgUser ever worked correctly. Here's my ongoing plan:

1. For this PR, I'd be focusing on making RemoveMultipleOrgUsersMutation work perfectly. I'll leave RemoveOrgUserMutation as-is.
2. When this PR is merged, I'd open a new PR to rename removeMultipleOrgUsers to removeOrgUsers
3. Finally, I'll remove removeOrgUser and replace all the client side call with the plural version removeOrgUsers

Sounds good?

[tianrunhe]

@Dschoordsch now with regards to this PR specifically, I have a doubt on this statement you made:

With the new auth token the kicked off users will need to update their subscriptions and then won't receive TEAM and ORGANIZATION updates for teams and orgs they're not a part of anymore

The unsubscribe operation comes with 1 second delay. In my test, the removed users would still get all the updates from the team/org they were removed from?

[Dschoordsch]

@Dschoordsch now with regards to this PR specifically, I have a doubt on this statement you made:

With the new auth token the kicked off users will need to update their subscriptions and then won't receive TEAM and ORGANIZATION updates for teams and orgs they're not a part of anymore

The unsubscribe operation comes with 1 second delay. In my test, the removed users would still get all the updates from the team/org they were removed from?

Yes, you're right. I wasn't aware of that delay. I also discussed this with Matt. The cleanest solution would be to make the remove object flat with just ids as I had described. While resolving the removed User in this scenario works, it would fail if some User fields were requested where we check additional permissions. The issue is that it's not clear for future developers in this context, that that might happen. So it's safer to make the switch.

[Dschoordsch]

Looks good. When testing though, I get the following warning for the removed Users (tested in Chrome and Firefox):

Warning: Cannot update a component (`TeamContainer`) while rendering a different component (`TeamDashMainRoot`). To locate the bad setState() call inside `TeamDashMainRoot`, follow the stack trace as described in https://reactjs.org/link/setstate-in-render
TeamDashMainRoot@webpack-internal:///./packages/client/modules/teamDashboard/components/TeamDashMainRoot.tsx:31:67
Route@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:448:29
Switch@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:650:29
Suspense
div
Styled(div)
Team@webpack-internal:///./packages/client/modules/teamDashboard/components/Team/Team.tsx:89:67
ErrorBoundary@webpack-internal:///./packages/client/components/ErrorBoundary.tsx:55:5
ErrorBoundaryFn@webpack-internal:///./packages/client/components/ErrorBoundary.tsx:131:86
TeamContainer@webpack-internal:///./packages/client/modules/teamDashboard/containers/Team/TeamContainer.tsx:40:7
Suspense
TeamRoot@webpack-internal:///./packages/client/modules/teamDashboard/components/TeamRoot.tsx:28:67
Route@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:448:29
Switch@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:650:29
main
Styled(main)
div
Styled(div)
div
Styled(div)
Dashboard@webpack-internal:///./packages/client/components/Dashboard.tsx:133:7
Suspense
DashboardRoot@webpack-internal:///./packages/client/components/DashboardRoot.tsx:35:69
C@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:705:31
Route@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:448:29
Switch@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:650:29
PrivateRoutes@webpack-internal:///./packages/client/components/PrivateRoutes.tsx:64:66
Route@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:448:29
Switch@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:650:29
div
Suspense
ErrorBoundary@webpack-internal:///./packages/client/components/ErrorBoundary.tsx:55:5
ErrorBoundaryFn@webpack-internal:///./packages/client/components/ErrorBoundary.tsx:131:86
_c21<@webpack-internal:///./packages/client/components/Action/Action.tsx:59:72
Provider@webpack-internal:///./node_modules/@radix-ui/react-context/dist/index.mjs:34:47
TooltipProvider@webpack-internal:///./packages/client/node_modules/@radix-ui/react-tooltip/dist/index.mjs:64:7
Router@webpack://parabol-action/./node_modules/react-router/esm/react-router.js?:79:30
BrowserRouter@webpack://parabol-action/./node_modules/react-router-dom/esm/react-router-dom.js?:57:35
RelayEnvironmentProvider@webpack://parabol-action/./node_modules/react-relay/lib/relay-hooks/RelayEnvironmentProvider.js?:7:18
AtmosphereProvider@webpack-internal:///./packages/client/components/AtmosphereProvider/AtmosphereProvider.tsx:21:5
Root

Can you take a look?