Enhancement: Allow admin to deactivate downvotes and disallow user to remove or move up song when voting is deactivated. about raveberry

[raveberry]

Sorry, I thought I already answered.
The different levels of interactivity are now part of Raveberry with 0.10.5, thanks for the suggestion.

Regarding the API: Currently it only contains the api/post-song url, because I needed that for shareberry. The Discord bot uses some more exposed endpoints that are not part of the "official" API (yet), like /ajax/musiq/vote. Maybe some of that might help you.

I agree that having a defined interface would be a good idea, though. I'll add it to my list.

[raveberry]

Hi, awesome that you like it!
I think that's a great idea. I would probably extend the current voting/no voting into multiple options of varying interactivity. I think these four would make sense:

• full public control. current "no voting", everybody can delete and reorder all songs
• up- and downvotes. current "voting"
• upvotes only. prevents people from downvoting all songs that are not theirs
• no control. songs can only be pushed, but their order can only be changed by mod/admin users.

I will put this into Raveberry with the next update. Do you have any comments / suggestions?
Also as a hint: there is the "IP checking" feature which checks votes on the server side and prevents the same device from voting for the same song twice. Maybe this could prevent some trolling in your case.

[Snorkell]

Hi, thanks for your feedback on this enhancement idea.
I have a suggestion, when looking at the code, I saw that you have implemented an api for posting songs to the backend.
I think having more endpoints that allows more control on the application would be nice. for exemple, a route to pause/play the music, an enpoint to skip music, and so on. This will allow developpers to implement their own custom interface without creating issues when they need something UI related