-
-
Notifications
You must be signed in to change notification settings - Fork 967
Add community vote settings (fixes #5360) #6603
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
base: main
Are you sure you want to change the base?
Changes from all commits
9103619
4ea31ea
d44b734
8fc334a
840a0df
283c331
9420541
ec90119
f58038f
be65f59
ab23371
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All the logical changes in here, especially removing the item type, and vote type, need to be reverted. The original reason for this functionality, was that some sites might want to disable all voting entirely, or only disable votes for posts (or comments), or only allow them under certain federation modes. This removes the ability for instances to do that. There's also good reasons why a site (or community) might only want to allow upvotes to a certain mode (IE local). I think the best way forward might just be to dupe the existing site vote settings over to community, and on making new communities, copy the existing site vote settings over initially, but let communities tweak them. And maybe rename the site settings
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As these settings dont need to be federated, they can actually be implemented as a plugin which is very much preferable. A plugin is much more flexible, for example it can be configured to allow downvotes only from a specific set of instances, or reject votes from users that havent posted before. Additionally plugins are much easier to change and its not necessary to make a new Lemmy release each time. Have a look at the example plugin here: https://github.com/LemmyNet/lemmy-plugins/blob/master/plugins/rust_allowed_voters/src/lib.rs
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like the idea of moving what should be core functionality (whether to allow upvotes and downvotes on certain items), to plugins. There are some pretty large existing lemmy sites who like the ability to disable downvotes, and I'd rather not try to move that to a plugin people have to add and configure. We should of course keep those plugin abilities, but it shouldn't replace these settings IMO. If we did my suggestion above : copy the local site vote settings for any new communities created, it would solve the federation issue.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is by no means a core feature because it can be implemented very easily in a plugin. Core features are things that cant be implemented as plugins, for example things that federate or new API endpoints. I have updated the existing Whether the functionality is implemented as a plugin or directly in Lemmy, it always needs to be configured. For now the plugin config may be a bit difficult because its done in the config file, but it will be much easier when #6487 is implemented. And then we can easily have a page in lemmy-ui to add plugins and set parameters. That way not every little thing has to become a core feature, plus it will be much more flexible. For example you could easily implement a downvote allowlist, so that only users from specific instances can downvote posts. And then deploy it immediately, without waiting for a new Lemmy release.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should always prefer integrating things into lemmy's core over plugins. Plugins might be more configurable, but they're a power user feature. Admins are just going to want to click a button to set their voting modes, whether ppl can upvote or downvote, and on what items. This should be a core part of lemmy, as I already did the work for this already. Your plugin should account for the 4 settings: post upvote, post downvote, comment upvote, comment downvote.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Another thing I realized: these vote settings must come back with
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay I restored the LocalSite settings in order to avoid breaking changes. Still, if people ask for more vote settings in the future (or settings for post/comment permissions), these should be implemented in plugins. Not everything related to votes or posts can be a core feature, and we cant support hundreds of LocalSite settings. It is absolutely possible to return plugin settings from LocalSite by adding a plugin hook there, and changing the frontend behaviour based on that. Doing that will require some extra work, but also result in more flexibility. |
Uh oh!
There was an error while loading. Please reload this page.
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 don't see where these are being copied over from the local site vote settings, which is critical. See here
Uh oh!
There was an error while loading. Please reload this page.
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.
Fixed. Also renamed to
community.post_downvote_modeto clarify it, and potentially add other settings later.