mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 15:51:43 +00:00
50471a67b1
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](https://www.figma.com/design/FMSdn1oKccJRHQPgf7053o/Cody-PLG-GA?node-id=4042-4927&t=Ob2UbemEkft4ofJZ-0) ### 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. <!-- 💡 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 --> ### Screenshots | Description | Screenshot | |--|--| | Failed to define user state OR invite status is not "sent" (thus can't be accepted) | <img width="1516" alt="Screenshot 2024-06-14 at 14 39 41" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/cf712239-6a8e-4a66-a4a2-c1932ba70ffd"> | | User is not on a Cody Pro team | <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="1516" alt="Screenshot 2024-06-14 at 14 34 40" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/617957cf-8259-4056-a117-8b806ece6efe">| |on the team they've been invited to|<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">| | User is the sole admin of another team |<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">| | User is on another team |<img width="1516" alt="Screenshot 2024-06-14 at 14 36 38" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/2bf20073-f49b-4fb1-9996-6143671c1727"><img width="1516" alt="Screenshot 2024-06-14 at 14 36 43" src="https://github.com/sourcegraph/sourcegraph/assets/25318659/349e9445-b2ec-402d-ac0a-6b2517abde9c">| ## 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) <!-- 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 5. Add bullet list items for each additional detail you want to cover (see example below) 6. You can edit this after the pull request was merged, as long as release shipping it hasn't been promoted to the public. 7. 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. --> |
||
|---|---|---|
| .. | ||
| branded | ||
| browser | ||
| build-config | ||
| client-api | ||
| codeintellify | ||
| cody-context-filters-test-dataset | ||
| cody-shared | ||
| cody-ui | ||
| common | ||
| eslint-plugin-wildcard | ||
| extension-api | ||
| extension-api-types | ||
| http-client | ||
| jetbrains | ||
| observability-client | ||
| observability-server | ||
| shared | ||
| storybook | ||
| template-parser | ||
| testing | ||
| vscode | ||
| web | ||
| web-sveltekit | ||
| wildcard | ||
| BUILD.bazel | ||
| README.md | ||
Frontend packages
List
- web: The web application deployed to http://sourcegraph.com/
- browser: The Sourcegraph browser extension adds tooltips to code on different code hosts.
- vscode: The Sourcegraph VS Code extension.
- extension-api: The Sourcegraph extension API types for the Sourcegraph extensions. Published as
sourcegraph. - extension-api-types: The Sourcegraph extension API types for client applications that embed Sourcegraph extensions and need to communicate with them. Published as
@sourcegraph/extension-api-types. - sandboxes: All demos-mvp (minimum viable product) for the Sourcegraph web application.
- shared: Contains common TypeScript/React/SCSS client code shared between the browser extension and the web app. Everything in this package is code-host agnostic.
- branded: Contains React components and implements the visual design language we use across our web app and e.g. in the options menu of the browser extension. Over time, components from
sharedandbrandedpackages should be moved into thewildcardpackage. - wildcard: Package that encapsulates storybook configuration and contains our Wildcard design system components. If we're using a component in two or more different areas (e.g.
web-appandbrowser-extension) then it should live in thewildcardpackage. Otherwise the components should be better colocated with the code where they're actually used. - search: Search-related code that may be shared between all clients, both branded (e.g. web, VS Code extension) and unbranded (e.g. browser extension)
- storybook: Storybook configuration.
Further migration plan
-
Fix circular dependency in TS project-references graph wildcard package should not rely on web and probably shared, branded too. Ideally it should be an independent self-contained package.
-
Decide on package naming and update existing package names. Especially it should be done for a shared package because we have multiple
sharedfolders inside of other packages. It's hard to understand from where dependency is coming from and it's not possible to refactor import paths using find-and-replace. -
Investigate if we can painlessly switch to
npmworkspaces. -
Content of packages shared and branded should be moved to wildcard and refactored using the latest FE rules and conventions. Having different packages clearly communicates the migration plan. Developers first should look for components in the wildcard package and then fall-back to legacy packages if wildcard doesn't have the solution to their problem yet.
-
shared contains utility functions, types, polyfills, etc which is not a part of the Wildcard component library. These modules should be moved into utils package and other new packages: e.g. api for GraphQL client and type generators, etc.
-
Packages should use package name (e.g.
@sourcegraph/wildcard) for imports instead of the relative paths (e.g.../../../../wildcard/src/components/Markdown) to avoid long relative-paths and make dependency graph between packages clear. (Typescript will warn if packages have circular dependencies). It's easy to refactor such isolated packages, extract functionality into new ones, or even into new repositories.