-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
User V2 Part II - Frontend changes #3866
Conversation
3def701
to
64bf932
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.
So again there are so many changes in this PR that it's impossible to fully verify everything without just testing everything :). However things seem to work! I found two things to remark on though (and 2 nits)
@paolodamico I pulled the code and ran through most of the analytics functionality + dashboards (that can be reasonably done in a demo env). Didn't notice any major issues. One thing I noticed is it looks like empty state behavior has slightly changed? See the two attached screenshots – left is localhost (running your branch), right is app.posthog – both in the demo project Noticed that 1) the events weren't expanded by default on the left 2) no chart/ empty state |
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 PR is dangerously large where there could be several missing variable changes that will cause errors. I think a different approach could've been taken where we create the new logic and then change all the references for that single logic as a concise PR that's focused. This one is proposing the changes for userlogic, billinglogic, and teamlogic which require a bunch more reference changes.
I did a run through of the code changes and did a QA clicking through most of the app and things look okay. Fairly overwhelming to go through closely. Will have to keep a close watch in prod
Thanks @mariusandra and @kpthatsme for the review, all feedback has been addressed! |
Agreed @EDsCODE! Ended up being a massive PR and a different approach would've been better, I failed to consider the extent of the changes required when first working on this (it kind of kept growing as more things were fixed). Will merge and be very attentive to any potential things breaking down. |
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.
I guess with so many changes, the change of some bug slipping in is always there. However things seem to work, so I think the best thing to do is to get this in cloud for a few days before it ends up in the next release.
100% agreed @mariusandra! I'm just making some final tweaks to the trends tests and merging. Matching cloud PR should already be live. |
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.
@@ -104,7 +104,7 @@ export const eventUsageLogic = kea< | |||
content_length: annotation.content.length, | |||
scope: annotation.scope, | |||
deleted: annotation.deleted, | |||
created_by_me: annotation.created_by && annotation.created_by?.id === userLogic.values.user?.id, | |||
created_by_me: annotation.created_by && annotation.created_by?.uuid === userLogic.values.user?.id, |
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 doesn't look right, right side should use user?.uuid
I think?
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.
Hmmm don't think so. The new /users/@me
endpoint sends the uuid
as id
.
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.
Okay, so as in the other comment, I think the spirit of this swap is good, but it's confusing as a PostHog developer
export interface UserType { | ||
anonymize_data: boolean | ||
distinct_id: string | ||
id: string |
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 needs uuid
too I think?
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.
Same as above, we actually send the uuid
as id
and no longer send the internal PK in the payload.
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.
UserBasicType
has both id
and uuid
though?
Generally I think if the DB fields are not renamed but in API they are, it's kind of confusing, though I agree with the sentiment of sending only uuid
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.
Makes sense, this could lead to confusion. As this requires a backend change too, will merge this and then update to have the attribute named uuid and avoid confusion.
…o 3765-cohort-by-trend * '3765-cohort-by-trend' of github.com:PostHog/posthog: (39 commits) 'string, parsable as datetime' (#3942) Update plugin server to 0.16.3 (#3944) Resizable table columns in Sessions (#3927) bump cryptography==3.4.7 and add macosx_arm64 install script (#3935) 🤖: Add jeduden as a contributor 🎉 (#3938) Fix feature flags default rollout (#3745) Less dancing in dashboards (#3824) Always show event stats and add warnings (#3908) Update plugin server to 0.16.2 (#3932) Minimum PostHog version in plugins (#3916) Renames Active users to Unique users (#3930) Fix action with same name (#3909) Fix navigation to insights from dashboards (#3928) User V2 Part II - Frontend changes (#3866) update autocapture label to be more descriptive (#3925) Log to sentry when migrations are out of date (#3924) Revert "Increase Element model varchar limits (#3912)" (#3923) Update plugin server to 0.16.1 (#3920) Are migrations safe to run on cloud? (#3917) Run Automerge as posthog-bot (#3919) ...
Changes
This PR builds up on #3855 & https://github.com/PostHog/posthog-cloud/pull/100, both requiring before merging this one.
/_preflight
&/api/users/@me/
for render-blocking components.teamLogic
ororganizationLogic
when updating attributes of the team/project or organization, respectively, instead of relying on user endpoint for everything./api/billing/
endpoint instead of relying on user.uuid
as identifier instead of relying on the integer primary key.Checklist