I’ve been tangling with that method for the Follow Plugin (Specifically see discourse-follow/plugin.rb at master · paviliondev/discourse-follow · GitHub) and have a few thoughts / questions which I’d be interested in others’ thoughts on.
Given the nature of the PostAlerter, I think this discussion goes beyond the Follow Plugin. I can see my suggestions below being relevant to the assign plugin and the polls plugin, amongst others.
My current thinking is along these lines (I’d be happy to make a PR for any of the below):
A hook or event trigger in the
after_save_postmethod to allow for plugins to add users to send notifications to (or not) within the context of the checks and counters of that method would be great. When sending a notification, three key considerations are:
- Should I send a notification to a user about a post
- Have I already sent a notification to a user about a post
- How should I notify a user about post (i.e. to respect their settings)
Each would be easier to assess within the context of the after_save_post method.
A tweaked use of notification types. Currently there are a few notification type constants used in the PostAlerter which are iterated or filtered in specific checks and counters, e.g.
There is currently a generic
:customnotification type, however it is not particularly useful in the after_save_post context, as adding
customto the type constants would mean that all use of the
customnotification type would be affected.
Note that the assign plugin currently uses the :custom notification type, however it is only using it for notifications on small actions (not regular posts), and does not use it for any queries (as any plugin or service can use it; it uses the message field to lookup assign notifications instead).