fix: remove team members from filter segment when removed from team

[cs7-shrey]

What does this PR do?

• Fixes Remove team members from filter segment when removed from team #24165
• Fixes CAL-6489

This PR removes team members from filter segments when they are removed from teams. Previously, if a user (say x) is removed from a team but still belongs to a filter segment, applying that filter segment throws an error. This PR addresses it by removing the user(x) from filter segments created by owners/admins of the team if the owners/admins can no longer access that particular user(x) i.e. in case of no alternate path of access.

Visual Demo (For contributors especially)

Video Demo (if applicable):

Will add shortly

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox. [N/A]
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

This can be tested by adding a user (say x) to a team, creating a filter segment with a filter on user x, removing the user x from the team and then viewing the filter segment again. Previously, this would throw an error.

[vercel]

@cs7-shrey is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

3 issues found across 4 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="packages/features/data-table/repositories/filterSegment.ts">

<violation number="1" location="packages/features/data-table/repositories/filterSegment.ts:144">
P2: Missing `select` clause - returns all columns instead of only needed fields. Other methods in this repository use explicit `select` clauses. Add a `select` to return only the fields needed for the use case (likely `id`, `userId`, and `activeFilters`).</violation>

<violation number="2" location="packages/features/data-table/repositories/filterSegment.ts:314">
P2: Missing `select` clause - returns all columns instead of only needed fields. The existing `update` method uses an explicit `select` clause. Add a `select` to return only necessary fields, or if the return value isn't used, consider returning `void`.</violation>
</file>

<file name="packages/features/ee/teams/services/teamService.integration-test.ts">

<violation number="1" location="packages/features/ee/teams/services/teamService.integration-test.ts:1382">
P2: Assertion order appears reversed. `toMatchObject` should be `expect(updatedSegment).toMatchObject(filterSegment)` to verify the updated segment matches the original.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[JagjeevanAK]

LGTM

[JagjeevanAK]

Code Review Summary

Code review for filter segment and team service changes. The PR looks good overall with some minor suggestions.

Overview

Type	Count
🚨 Critical	0
⚠️ Warning	0
💡 Suggestion	1
📝 Nitpick	1
✨ Praise	1

Files reviewed: 1

3 inline comment(s) below.

[github-actions]

This PR has been marked as stale due to inactivity. If you're still working on it or need any help, please let us know or update the PR to keep it active.

[cs7-shrey]

@dhairyashiil is anyone reviewing this?

[github-actions]

Devin AI is resolving merge conflicts

This PR has merge conflicts with the main branch. A Devin session has been created to automatically resolve them.

View Devin Session

Devin will:

1. Merge the latest main into this branch
2. Resolve any conflicts intelligently
3. Run lint/type checks to ensure validity
4. Push the resolved changes

If you prefer to resolve conflicts manually, you can close the Devin session and handle it yourself.

[eunjae-lee]

Thanks for the contribution. I will get back to this PR on Monday. I need to re-think about the approach here and give you my feedback.

[eunjae-lee]

Hi @cs7-shrey Thanks for your contribution. This will likely work for this situation but I don't think it's a good pattern to have. I've written the following feedback for you with the AI:

The PR directly modifies TeamService.removeMembers() to update filter segments when users are removed. This approach has fundamental issues:

1. Tight coupling: Team membership logic now knows about filter segment internals
2. Not scalable: Every data mutation that could affect filter values would need similar logic
3. Hardcoded field knowledge: The code specifically handles userId filters, but what about eventTypeId, teamId, etc.?
4. Scattered responsibility: Filter validation logic gets spread across unrelated services

---

I was going to give you a guide so that you could it, but I think I need to touch more core area regarding filter segments. So I'm going to close this PR and work on it in a new PR myself. I'll leave the PR link in case you're interested.

Thanks for your contribution and it has given me a good insight on how to improve this.

[devin-ai-integration]

A new PR has been created with an alternative approach to this problem: #27208

Instead of coupling filter segment updates with entity deletion logic, the new approach validates filters at the caller level when segments are applied. This provides a more scalable solution that:

1. Keeps validation logic in the feature that knows the context (bookings page)
2. Validates filters against already-fetched accessible resource IDs (no extra requests)
3. Filters invalid values in memory without persisting changes back to the backend
4. Can be easily extended to other pages that use filter segments