Skip to content
This repository was archived by the owner on Sep 30, 2024. It is now read-only.

PLG: Allow users who are already on a team accept invites#63231

Merged
taras-yemets merged 19 commits intomainfrom
ty/invites-to-users-with-a-team
Jun 14, 2024
Merged

PLG: Allow users who are already on a team accept invites#63231
taras-yemets merged 19 commits intomainfrom
ty/invites-to-users-with-a-team

Conversation

@taras-yemets
Copy link
Contributor

@taras-yemets taras-yemets commented Jun 12, 2024

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

  1. Moved the accept invite UI to the "/cody/manage" page.
  2. Handled cases where the invited user is already a Cody Pro user.
  3. Fixed styles in the CodyAlert component to ensure images are visible.

Implementation Details

  1. Added the useInviteState hook, which returns initialInviteStatus and initialUserStatus.

    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 the AcceptInviteBannerContent.

  2. 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 useSSCQuery hook. 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

Description Screenshot
Failed to define user state OR invite status is not "sent" (thus can't be accepted) Screenshot 2024-06-14 at 14 39 41
User is not on a Cody Pro team Screenshot 2024-06-14 at 14 34 30Screenshot 2024-06-14 at 14 34 40
on the team they've been invited to Screenshot 2024-06-14 at 14 35 41
User is the sole admin of another team Screenshot 2024-06-14 at 14 38 42
User is on another team Screenshot 2024-06-14 at 14 36 38Screenshot 2024-06-14 at 14 36 43

Test plan

  • Checkout the branch from https://github.com/sourcegraph/self-serve-cody/pull/858 and run SSC locally
  • Run Sourcegraph in dotcom mode
  • As a Cody Pro team admin send invites to users that have different statuses (are not on a team, are members of the team they were invited to, are members of another team, are sole admins of their teams)
  • As the invited user:
    • click the invite link from the email
    • modify the hostname in the URL so that it points to the local Sourcegraph instance
    • ensure the correct banner is displayed
    • ensure user can accept/decline the invite (if applicable for the banner type)

Changelog

@cla-bot cla-bot bot added the cla-signed label Jun 12, 2024
@taras-yemets taras-yemets changed the title Allow users who are already on a team accept invites PLG: Allow users who are already on a team accept invites Jun 14, 2024
@taras-yemets taras-yemets requested a review from a team June 14, 2024 13:06
@taras-yemets taras-yemets marked this pull request as ready for review June 14, 2024 13:09
Copy link
Contributor

@vdavid vdavid left a comment

Choose a reason for hiding this comment

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

Wow, nice, well-organized so it was easy to follow and review. Great job!

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I assumed this page would be deleted altogether. Why do we still need this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Invite link in the email points to this page. Do you know how we can change that?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you! Will address in a follow-up PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

This hook is so nice and clean 👌

Copy link
Contributor

Choose a reason for hiding this comment

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

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}`
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, good catch

Copy link
Contributor Author

Choose a reason for hiding this comment

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

PreviewResult,
PreviewCreateTeamRequest,
} from '../types'
} from '../teamSubscriptions'
Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

@vdavid
Copy link
Contributor

vdavid commented Jun 14, 2024

Two small change requests:

  1. In the PR description, I think the screenshot you have next to "User is on the team they've been invited to" is the wrong one. You might've accidentally merged two rows. It might help @rrhyne's work if you fix this.
  2. In my understanding, PR titles in the monorepo now must follow the "feat(plg): Change description" format. I think following this helps with automated changelog building.

@taras-yemets
Copy link
Contributor Author

taras-yemets commented Jun 14, 2024

Thanks for your review, @vdavid!

In the PR description, I think the screenshot you have next to "User is on the team they've been invited to" is the wrong one.

Nice catch! Thank you!

PR titles in the monorepo now must follow the "feat(plg): Change description" format.

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.

@taras-yemets taras-yemets enabled auto-merge (squash) June 14, 2024 16:45
@taras-yemets taras-yemets requested a review from rrhyne June 14, 2024 16:46
@taras-yemets taras-yemets disabled auto-merge June 14, 2024 16:52
@taras-yemets taras-yemets enabled auto-merge (squash) June 14, 2024 16:52
@taras-yemets taras-yemets merged commit 50471a6 into main Jun 14, 2024
@taras-yemets taras-yemets deleted the ty/invites-to-users-with-a-team branch June 14, 2024 16:56
taras-yemets referenced this pull request Jun 14, 2024
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.
-->
@vdavid
Copy link
Contributor

vdavid commented Jun 14, 2024

PR titles in the monorepo now must follow the "feat(plg): Change description" format.

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.

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

@taras-yemets
Copy link
Contributor Author

It's in the template for new PR descriptions in the monorepo.

TIL! Thanks a lot, @vdavid! I completely missed that update 🤦🏻‍♂️

@rrhyne
Copy link
Contributor

rrhyne commented Jun 14, 2024

taras-yemets referenced this pull request Jun 17, 2024
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.
-->
taras-yemets referenced this pull request Jun 18, 2024
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.
-->
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Accept invites on /cody/manage rather than on a separate page

4 participants