Skip to content
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

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

Open
MiM-MiM opened this issue Aug 28, 2024 · 4 comments
Open

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

MiM-MiM opened this issue Aug 28, 2024 · 4 comments
Labels

Comments

@MiM-MiM
Copy link
Contributor

MiM-MiM commented Aug 28, 2024

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

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar
@MiM-MiM MiM-MiM added Fund https://polar.sh Request labels Aug 28, 2024
@Roardom
Copy link
Collaborator

Roardom commented Aug 28, 2024

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
Copy link
Contributor Author

MiM-MiM commented Aug 29, 2024

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
Copy link
Collaborator

Roardom commented Aug 29, 2024

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
Copy link

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.

@HDVinnie HDVinnie removed the Fund https://polar.sh label Dec 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants