-
-
Notifications
You must be signed in to change notification settings - Fork 126
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
Add alternate accounts to the user model #1171
Conversation
❌ Deploy Preview for pydis-static failed.
|
54ab4af
to
8b1c34e
Compare
74d2257
to
a67f5f2
Compare
a67f5f2
to
9311158
Compare
pydis_site/apps/api/serializers.py
Outdated
# This should be edited on a separate endpoint only | ||
frozen_fields = ('alts',) |
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.
Why are we making this design decision over allowing direct updates on the existing users endpoint?
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.
As a client the bot would need to fetch the user, edit the list of alts, then send back the updated list to site.
Since that's not an atomic change, we could lose data if two actions were preformed on the same user at the same time.
This approach means that each action is preformed atomically by site
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.
Can we not support a partial update? We only need to update the alts field, not the entire user.
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.
Strictly speaking this line doesn't do anything at all, because from my
testing DRF already doesn't allow editing the field over the regular
patch endpoint - it just ignores whatever you give it. The
frozen_fields
therefore serve more of a documentary purpose than
actually changing anything. I haven't found a way to enable this in
DRF...
7da4c7f
to
d97d08c
Compare
d97d08c
to
ebcd420
Compare
d296f8f
to
70f5e39
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.
All looks good, only thing I've noticed is we store user display name but it looks missing from a lot of this.
It looks like the missing serialisation here was already present but maybe it should be added in now?
Oh just noticed the PR age, the serialisation might be present in main then. |
Introduce a way to store alternate accounts on the user, and add the `PATCH /bot/users/<id:str>/alts` endpoint, which allows updating the user's alt accounts to the alt accounts in the request..
Migrations are merged, |
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 may misunderstand Django migrations and this may be a non-issue, but do we need to update the dependencies of the 0093_user_alts migration to instead depend on 0095_user_display_name (which should be the most recent migration)
We do not. The merged migration takes care of resolving conflicts. |
Introduce a way to store alternate accounts on the user, and add the
PATCH /bot/users/<id:str>/alts
endpoint, which allows updating the user's alt accounts to the alt accounts in the request..