-
-
Notifications
You must be signed in to change notification settings - Fork 883
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
Move admin flag from person to local_user (fixes #3060) #3403
Conversation
The person table is for federated data, but admin flag can only apply to local users. Thats why it really belongs in the local_user table. This will also prevent the federation code from accidentally overwriting the admin flag
This is not a breaking change, the API is unchanged. |
let added = data.added; | ||
let added_person_id = data.person_id; | ||
let added_admin = Person::update( | ||
let target = LocalUserView::read_person(context.pool(), data.person_id).await?; |
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.
If its a breaking change anyway I might as well change these data.person_id to data.local_user_id to avoid unnecessary db reads.
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.
Yeah, might as well do this change across the board. Might mean fewer DB calls.
Resolved conflicts. For some reason api tests are failing with this error, no idea why:
|
I'll test it out now |
The admin column on the source table was in the wrong order. It needs to match the order in schema.rs. This was hard to find because they were both boolean columns. |
This test started failing all the sudden. I don't understand why its suddenly unable to resolve a banned person. |
a43be04
to
8554465
Compare
… of Lemmy See: LemmyNet/lemmy#3403 For now, I guess we can try parsing the flag if it's present, and fall back on assuming the associated user is *not* an admin.
… of Lemmy See: LemmyNet/lemmy#3403 For now, I guess we can try parsing the flag if it's present, and fall back on assuming the associated user is *not* an admin.
The person table is for federated data, but admin flag can only apply to local users. Thats why it really belongs in the local_user table. This will also prevent the federation code from accidentally overwriting the admin flag