Add Support for Switching Between User Teams with Cookie-Based Context

[marconneves]

This PR introduces a feature to allow users to switch between their associated teams dynamically, addressing the current limitation where the application supports only a single team context. The goal is to enhance flexibility for users who belong to multiple teams, enabling seamless transitions without requiring logout/login cycles.

Internally, I’ve successfully implemented this approach for my company to separate two projects that required distinct logs and operators. As an admin, I previously had to log out and log back in to switch contexts, which was inefficient. This proposal draws inspiration from that experience and aims to bring a similar capability to the platform.

Proposed Behavior

• Team Selection: When a user selects a team, a unsendTeamId cookie is set to persist the choice. This cookie is accessible server-side via tRPC middleware.
• Context Switch: The application context updates to reflect the selected team, ensuring all subsequent operations (queries, mutations, etc.) operate within the chosen team’s scope.
• Cache Management: After switching teams, the React Query cache is cleared to prevent stale data from the previous team context affecting the new one.

Implementation Details

• Frontend: The TeamProvider now persists the selected team in a cookie using js-cookie and updates the current team state. (See previous commits for the client-side changes.)
• Backend: The teamProcedure middleware in tRPC reads the unsendTeamId cookie via next/headers and filters the user’s teams to set the appropriate context. If the cookie is invalid or absent, it falls back to the user’s first team.
• Fallback Logic: If no valid team is found matching the cookie, the system defaults to the user’s first available team to ensure a smooth experience.

Why This Matters

This feature eliminates the need for repeated logins when managing multiple teams, which is particularly useful for admins or users with cross-team responsibilities. It aligns with real-world use cases (like my internal project separation) and could be a valuable addition for multi-team workflows.

Questions for Reviewers

• What do you think of this approach? Does it align with the platform’s direction?
• Could this be a feature worth expanding into an official multi-team support capability?
• Are there any edge cases or security concerns I should address (e.g., cookie tampering, team access validation)?

Next Steps

• Test the feature across different user roles (admin, member) and team configurations.
• Gather feedback on UX implications of team switching.
• Consider additional optimizations, like preserving some cache data selectively instead of a full clear.

Looking forward to your thoughts!

[marconneves]

@KMKoushik I create this propose, what do you think?

[KMKoushik]

this seems to be a good idea and db schema already supports this. need lot's of testing though and also needs some business pov as well. ie) i don't want people to create infinite free accounts etc.

[KMKoushik]

thx, going to close this for now.