PLG: Allow users who are already on a team accept invites#63231
PLG: Allow users who are already on a team accept invites#63231taras-yemets merged 19 commits intomainfrom
Conversation
…aph/sourcegraph into ty/invites-to-users-with-a-team
vdavid
left a comment
There was a problem hiding this comment.
Wow, nice, well-organized so it was easy to follow and review. Great job!
There was a problem hiding this comment.
Oh, I assumed this page would be deleted altogether. Why do we still need this?
There was a problem hiding this comment.
Invite link in the email points to this page. Do you know how we can change that?
There was a problem hiding this comment.
Yup, it's easy, its only reference is here: https://sourcegraph.sourcegraph.com/github.com/sourcegraph/self-serve-cody@main/-/blob/cody/backend/internal/api/team_invites.go?L23
There was a problem hiding this comment.
Thank you! Will address in a follow-up PR.
There was a problem hiding this comment.
This hook is so nice and clean 👌
There was a problem hiding this comment.
This is very nice, too. I spent quite a while understanding it, and it makes sense, I think this is a helpful encapsulation of this logic. 👍
| const response = await fetch('/-/sign-out', buildRequestInit({ method: 'GET' })) | ||
| if (response.ok) { | ||
| window.location.href = `/sign-in?returnTo=${window.location.pathname}` | ||
| window.location.href = `/sign-in?returnTo=${window.location.pathname + window.location.search}` |
There was a problem hiding this comment.
@vdavid, here's an even better catch https://github.com/sourcegraph/sourcegraph/pull/63275 😅
| PreviewResult, | ||
| PreviewCreateTeamRequest, | ||
| } from '../types' | ||
| } from '../teamSubscriptions' |
There was a problem hiding this comment.
Nit: I think the idea is that we don't directly reference those files, and only use types.ts as an abstraction. It doesn't matter all that much, @chrsmith's reasoning in types.ts says
// Export all API types, so consumers we can organize the type definitions
// into smaller files, without consumers needing to care about that organization.
and it makes sense, although it's pretty easy to replace any direct references with types.ts references if we want to reorganize stuff.
There was a problem hiding this comment.
I don't have any opinions here, and I imagine that there is some marginal efficiency gain by only needing to read from the teamSubscriptions.ts file instead of needing the TypeScript compiler to crawl all of the types.ts (and what it brings in).
The main point was to just make it so we that we don't have to spend time figuring out which particular types are defined in which particular file. And so just import type * as types would "just work". (And, IMHO, needing to prefix API type names with types. also makes them stand out in the code which has some minor benefits too.)
But anyways, I don't think we should try to standardize on only referencing the data types from that particular module or anything.
|
Two small change requests:
|
|
Thanks for your review, @vdavid!
Nice catch! Thank you!
I may have missed it. Do you know if there's a related doc? I can see different PR naming approaches in the monorepo including all or some of the following: change type (feat/fix/etc), scope/feature (api/plg/cody-web) and arbitrary description. |
Fixes bug intorduced in https://github.com/sourcegraph/sourcegraph/pull/63231 Encode the URL search params added to `returnTo` search param value. Previously the search param value hasn't been encoded resulting in URLs with broken search params , e.g. *"/sign-in?returnTo=/cody/manage?teamID=1&inviteID=2"* (note the second "?" making the search params invalid). <!-- 💡 To write a useful PR description, make sure that your description covers: - WHAT this PR is changing: - How was it PREVIOUSLY. - How it will be from NOW on. - WHY this PR is needed. - CONTEXT, i.e. to which initiative, project or RFC it belongs. The structure of the description doesn't matter as much as covering these points, so use your best judgement based on your context. Learn how to write good pull request description: https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e?pvs=4 --> ## Test plan - CI - Tested manually: - Make `signOutAndRedirectToSignIn` available in the window object, e.g. `window.signOutAndRedirectToSignIn = signOutAndRedirectToSignIn` in the *client/web/src/cody/management/api/react-query/callCodyProApi.ts* - On "/cody/manage" page (any page works actually) ensure that a few search params are added to the URL - call `signOutAndRedirectToSignIn` in the browser console - ensure you have been sign out, signed back in and the search params are still in the URL <!-- All pull requests REQUIRE a test plan: https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> ## Changelog <!-- 1. Ensure your pull request title is formatted as: $type($domain): $what 2. Add bullet list items for each additional detail you want to cover (see example below) 3. You can edit this after the pull request was merged, as long as release shipping it hasn't been promoted to the public. 4. For more information, please see this how-to https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c? Audience: TS/CSE > Customers > Teammates (in that order). Cheat sheet: $type = chore|fix|feat $domain: source|search|ci|release|plg|cody|local|... --> <!-- Example: Title: fix(search): parse quotes with the appropriate context Changelog section: ## Changelog - When a quote is used with regexp pattern type, then ... - Refactored underlying code. -->
@taras-yemets It's in the template for new PR descriptions in the monorepo. Read the ## Changelog section. I think it's only been there for two weeks or so. |
TIL! Thanks a lot, @vdavid! I completely missed that update 🤦🏻♂️ |
|
@taras-yemets sorry I missed this. Some QA here: |
Adresses [UI feedback](https://www.figma.com/design/FMSdn1oKccJRHQPgf7053o/Cody-PLG-GA?node-id=5472-12492&t=ndgEZFI57dVTIBpo-4) on https://github.com/sourcegraph/sourcegraph/pull/63231 |Description|Before|After| |--|--|--| | Change dismiss button variant from "secondary" to "link" |<img width="1516" alt="Screenshot 2024-06-14 at 14 34 30" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/d6b53dc4-c7df-45eb-a743-9baddfdd8aa3">|<img width="1170" alt="Screenshot 2024-06-17 at 12 35 53" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/6778a4bf-9a03-4c3b-a83c-57777859b7f1">| | Fix banner content alignment |<img width="1516" alt="Screenshot 2024-06-14 at 14 35 41" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/eaa871ce-acd3-4a7e-a25c-74011a42af58"><img width="1516" alt="Screenshot 2024-06-14 at 14 38 42" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/1382e5a0-4375-4002-93a4-ec25d354317f">|<img width="1165" alt="Screenshot 2024-06-17 at 12 31 14" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/532930ff-8471-46d8-83c0-f2bbeb1a8bcd">| <!-- 💡 To write a useful PR description, make sure that your description covers: - WHAT this PR is changing: - How was it PREVIOUSLY. - How it will be from NOW on. - WHY this PR is needed. - CONTEXT, i.e. to which initiative, project or RFC it belongs. The structure of the description doesn't matter as much as covering these points, so use your best judgement based on your context. Learn how to write good pull request description: https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e?pvs=4 --> ## Test plan - Tested manually (screenshots attached) <!-- All pull requests REQUIRE a test plan: https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> ## Changelog <!-- 1. Ensure your pull request title is formatted as: $type($domain): $what 2. Add bullet list items for each additional detail you want to cover (see example below) 3. You can edit this after the pull request was merged, as long as release shipping it hasn't been promoted to the public. 4. For more information, please see this how-to https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c? Audience: TS/CSE > Customers > Teammates (in that order). Cheat sheet: $type = chore|fix|feat $domain: source|search|ci|release|plg|cody|local|... --> <!-- Example: Title: fix(search): parse quotes with the appropriate context Changelog section: ## Changelog - When a quote is used with regexp pattern type, then ... - Refactored underlying code. -->
Removes "/cody/invites/accept" page. Invite processing is handled on the "/cody/manage" page and "/cody/invites/accept" is used only to redirect to the former. Backend counterpart: sourcegraph/self-serve-cody#886 <!-- 💡 To write a useful PR description, make sure that your description covers: - WHAT this PR is changing: - How was it PREVIOUSLY. - How it will be from NOW on. - WHY this PR is needed. - CONTEXT, i.e. to which initiative, project or RFC it belongs. The structure of the description doesn't matter as much as covering these points, so use your best judgement based on your context. Learn how to write good pull request description: https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e?pvs=4 --> ## Test plan - Tested manually - checkout branch fromhttps://github.com/sourcegraph/self-serve-cody/pull/886 and run SSC backend locally - run Sourcegraoh instance in dotcom mode locally - log in as a Cody Pro team admin and send an invite to another user - log in as an invited user and follow the link from the email - ensure link navigates to the "/cody/manage/" page and is hanled as expected (see test plan from https://github.com/sourcegraph/sourcegraph/pull/63231) <!-- All pull requests REQUIRE a test plan: https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> ## Changelog <!-- 1. Ensure your pull request title is formatted as: $type($domain): $what 2. Add bullet list items for each additional detail you want to cover (see example below) 3. You can edit this after the pull request was merged, as long as release shipping it hasn't been promoted to the public. 4. For more information, please see this how-to https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c? Audience: TS/CSE > Customers > Teammates (in that order). Cheat sheet: $type = chore|fix|feat $domain: source|search|ci|release|plg|cody|local|... --> <!-- Example: Title: fix(search): parse quotes with the appropriate context Changelog section: ## Changelog - When a quote is used with regexp pattern type, then ... - Refactored underlying code. -->
Closes https://github.com/sourcegraph/sourcegraph/issues/63078
Part of https://github.com/sourcegraph/self-serve-cody/issues/804 (see also its backend counterpart https://github.com/sourcegraph/self-serve-cody/pull/858)
Figma
Summary
Implementation Details
Added the
useInviteStatehook, which returnsinitialInviteStatusandinitialUserStatus.We track the initial statuses to determine the appropriate UI variant to display. For example, if the initial invite status is "sent" (indicating the invite can be accepted) and the initial user status is
UserInviteStatus.NoCurrentTeam(indicating the user is not a member of any team), a confirmation banner is shown for the user to accept or decline the invite. After the user responds, the invite query is invalidated, updating the status to "accepted", "canceled", or "errored" based on their action. Depending on the result, a success or error banner is displayed, or the banner is hidden if the invite is canceled. More configuration examples can be found in the Screenshots section. All possible states are detailed in theAcceptInviteBannerContent.For users who are the sole admin of their current team, the banner is shown on the "/cody/manage" page.
The design requires showing a banner on the "/cody/team/manage" page to suggest transferring the admin role to another team member. However, this page is not yet ready. To sync the banner state with user role changes or deletion actions, the members list query must be invalidated after each action. The current implementation of the "cody/manage/team" page does not support refetching with the
useSSCQueryhook. To resolve this, we need to migrate the "cody/manage/team" page to use React Query to allow query invalidation after each action. For now, users who are sole admins see a banner on the "cody/manage" page suggesting transferring the admin role, with a link to the "/cody/manage/team" page.Screenshots
Test plan
Changelog