Skip to content
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: add client-side RemoveMultipleOrgUsersMutation #10805

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

tianrunhe
Copy link
Contributor

@tianrunhe tianrunhe commented Feb 6, 2025

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

parabol-release-bot bot and others added 3 commits February 6, 2025 15:46
Co-authored-by: parabol-release-bot[bot] <150284312+parabol-release-bot[bot]@users.noreply.github.com>
@github-actions github-actions bot added the size/m label Feb 6, 2025
@tianrunhe tianrunhe marked this pull request as ready for review February 6, 2025 14:06
@tianrunhe tianrunhe requested a review from Dschoordsch February 6, 2025 14:06
Copy link
Contributor

@Dschoordsch Dschoordsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not test

Copy link
Contributor

@Dschoordsch Dschoordsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@tianrunhe
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Contributor

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

@github-actions github-actions bot added size/l and removed size/m labels Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants