-
-
Notifications
You must be signed in to change notification settings - Fork 114
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
Allow SN users to edit special items forever #1204
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 would allow anons (id=27) to edit these I think.
Ah, yes, it looks confusing since To me, |
Ah, you're right. I wonder why I put that there. |
I removed anon from However, I am not sure if anon should be part of the trust seeds? Because of this line, anon votes are excluded in However, if I understand this line right, we cross join all users from But I ran following query on the prod database and saw that there is no arc from any user to anon or vice versa so clearly I am missing something: SELECT * from "Arc" WHERE "toId" = 27 OR "fromId" = 27 ORDER BY "zapTrust" DESC LIMIT 21; So I am confused if anon should be in I am also confused by the results of these queries: -- who trusts me?
SELECT * from "Arc" WHERE "toId" = 6030 ORDER BY "zapTrust" DESC LIMIT 21;
-- who trusts k00b?
SELECT * from "Arc" WHERE "toId" = 616 ORDER BY "zapTrust" DESC LIMIT 21; The first query seems to tell me that no one trusts me (id 6030) except @huumn (user id 616). I don't even trust myself. The second query seems to tell me that @huumn only trusts himself. What am I missing? |
anon shouldn't be given any special privileges or favor, so if they are, it's probably a mistake.
You're missing that we only store significant deviations from the global consensus in |
mhh, so they shouldn't be included in
Ahh, ok, makes sense I noticed #1212 while finishing up this PR. But this and the anon issue are not really related to this PR since these issues already existed before. As far as what this PR is concerned about, this PR is ready for review again. I also assume you're fine with less strict requirements on who can edit which special item? Before, it only gave the author infinite edits. Now, any user in |
Description
This allows any user in
SN_USER_IDS
(removed kr from that list in #1203) to edit any item inITEM_ALLOW_EDITS
.Checklist
Are your changes backwards compatible? Please answer below:
Yes
Did you QA this? Could we deploy this straight to production? Please answer below:
Yes
For frontend changes: Tested on mobile? Please answer below:
Did you introduce any new environment variables? If so, call them out explicitly here: