HDInnovations / UNIT3D-Community-Edition

Private Torrent Tracker Built With Laravel, Livewire and AlpineJS.
GNU Affero General Public License v3.0
1.94k stars 370 forks source link

[Request] Voting on requests sends notifications for claims/fills #4105

Open MiM-MiM opened 2 weeks ago

MiM-MiM commented 2 weeks ago

When someone votes on a request they should get the claim/fill. This is important so they don't have to create a dupe request to get the notifications. It also allows them to use the report feature in a timely manner to get staff to reject the fill or unfill the request if it did not meet the original voted on description. The other user may be fine with accepting something else, but other voters may not be and they should not be forced to accept that upload.

1) Claim, send notification to all voters 2) Unclaim, send new notification to all voters 3) Fill submission, send notification to creator 4) Fill submission, send PM to all other voters. This way there can be a longer message including the link and informing them to report the request if it did not meet the original requirements they agreed on. 5) Fill accepted, reply to the PM to voters updating that status. 6) Fill rejected, reply to the PM again with the reason it was rejected. 7) Unfill by staff, reply to that PM again with the reason the staff unfilled it. 8) Unfill by staff, message the creator with the update of it being unfilled by staff and informing them to create a support ticket if they need further assistance.

This should cover all the cases, the voters can have all of theirs done via a single PM thread if wanted too rather than mixing notifications and PM, but a PM will allow for updates to work nicer.

Upvote & Fund

Fund with Polar

Roardom commented 2 weeks ago

PM's aren't really designed for this. All users including those that voted anonymously would be in the participant list. Although keeping a system user within the conversation will prevent any messages from being sent. I also think the existence of an anon flag for a pm participant at all would be quite bad for privacy...

Are notifications fine?

MiM-MiM commented 2 weeks ago

PM's aren't really designed for this. All users including those that voted anonymously would be in the participant list. Although keeping a system user within the conversation will prevent any messages from being sent. I also think the existence of an anon flag for a pm participant at all would be quite bad for privacy...

I was not meaning add all to one at all, just putting them in one. Anon flag for PMs is good too, but would be under a different scope for the feature, as that would be under a way to use the "send uploader message" button on a torrent or even a request. That could have the option for keeping themselves anon as well if wanted, having the user getting the PM being anon based on if they made that torrent/request as anon.

Are notifications fine?

Notifications in their current state really do not work for things like this. They would end up getting several notifications for the same thing, if they are used it needs to be just a generic "A request you voted on received an updated status." with the name there and it linking to the request, but not sending a new one while you have it unread. PMs work better for this because you can both keep updating without sending multiple notifications and having the ability to further send advice. The message could have information about reporting it too, which in a notification does not really fit space wise.

A good example of why notifications wouldn't really work is forum topics that users watch, if you get 5 replies to a thread, you get 5 notifications rather than a single one with a counter or just the oldest taking you to the last read post. Threads are easily solved by people just unwatching it, a request would not really work for that.

Roardom commented 2 weeks ago

PMs are still not intended for this and would be an abuse of its threaded functionality. It'd be better for notifications to update their status.

As far as I'm concerned, all system generated PMs are already an abuse of functionality and should ideally be notifications instead.

Audionut commented 2 weeks ago

I would think that only the requester gets to determine is a request is filled or unfilled.

And personally I prefer notification, especially for something like being notified about request status for someone else's request, because it already has fine grained control over what is pinged.