New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSC: Teams and Invites: Create "Manage team" page #62453
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it is on the right track. And the screen shots you posted on Slack look great!
Most of my feedback can be summed up with:
"This is totally fine for a draft PR. Here is a suggestion for how to clean things up when this is ready for a proper review. (But is more than likely something you were probably already planning on doing anyways, since this is just a WIP Draft.)"
129e288
to
24e3b9d
Compare
try { | ||
const response = await fetchThroughSSCProxy('/subscription', 'GET') | ||
const responseJson = (await response.json()) as { endedAt: string | null; maxSeats: number } | null | ||
setIsProUser(responseJson && !!responseJson.endedAt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const remainingInviteCount = useMemo(() => { | ||
const memberCount = teamMembers?.length ?? 0 | ||
const invitesUsed = (teamInvites ?? []).filter(invite => invite.status === 'sent').length | ||
return Math.max(subscriptionSeatCount || 0 - (memberCount + invitesUsed), 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrsmith let me know if you have a better suggestion to calculate this based on the available data.
2b71b3e
to
3502d76
Compare
3502d76
to
1f5358d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot of good stuff in this PR, and it's super-exciting to see the Teams and Invites functionality come together! But I think this PR still needs a bit more work before it is checked-in.
As far as a next step, let's try to see if we can find a time to review this PR in a VC meeting so we can discuss tradeoffs more quickly. (I can come in a couple hours earlier any day of the week, just let me know with some notice.)
Overall, each of my PR comments probably boils down to one of the following:
-
A starting point for discussing how we want to build Cody Pro. e.g. not so much a concrete suggestion, but more double checking how we want to approach certain aspects of the design or UX.
-
Engineering rigor types of things that I (annoyingly) won't budge on. We are going to create a Cody Pro codebase that we will be proud of, and be constructed in such a way that anybody on the team will be able to easily and safely make changes to. This will require adding some layers of abstraction or formalizing things to a higher degree than immediately seems required. But alas, "sorry not sorry".
-
Engineering rigor types of things that I (perhaps reluctantly) will budge on. While I have suggestions for how to make the code easier to read or maintain, you don't need to accept every single one. (Nor should you?) Maybe I'm just factually wrong. Or it's a matter of opinion, and you just prefer it some other way. Or we both acknowledge that something is wrong, but it just doesn't make sense to deal with it at this time.
Unfortunately I cannot say for certain which things fall into camp 2 vs. camp 3. (In the extremes, some things are clearly "wrong", IMO and other things I could easily be convinced are A-OK.)
But it'll probably take some time for us to norm on where exactly we want to draw the line here. e.g. coming up with a standard for code quality that we want to shoot for on the Cody Prime team. Or the degree to which we rely on sophisticated data types or design patterns in order to make it easier to write correct code.
Anyways, if you could try to address the PR feedback that you agree we can figure out the best way to address some of these other issues next week. (e.g. I'll try to send out a PR with a TypeScript "API client library" for the SSC backend API, which will address some of the things I call out.)
The earliest we can do that is tomorrow (Tuesday). Let's do that tomorrow, then. Could you schedule something within my work hours that fits your schedule? However, as I've addressed each piece of feedback, I suggest you re-review this PR to unblock, and we can address any further concerns in follow-ups. |
30c6e19
to
8aa4a85
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving to not hold up the Teams and Invites stuff any more.
Though as we continue to flesh out this part of the codebase, let's try to pin down the specific patterns we do and do not want to follow in order to keep things simple and maintainable. (e.g. using the withAuthenticatedUser()
wrapper, and similar things.)
Contributes to https://github.com/sourcegraph/self-serve-cody/issues/725
4-min Loom for @rrhyne (and others) here.
/cody/team/manage
for dotcom only, behind theuseEmbeddedCodyProUi
flag./cody/subscription
fetchThroughSSCProxy
function (but not using it yet on the checkout page—left a TODO to do that later)TeamMembers
andInviteUsers
into separate components.Notes:
Test plan
This is WIP and behind a feature flag so low stakes for now. I've clicked around but my main goal was not to make it steadily functional but to check off as many of the items in https://github.com/sourcegraph/self-serve-cody/issues/725 as possible and build on this in future commits.