Feature Request: Ability to use @Here, etc. Alerting in Discord Notifications

[dyecast568]

• Problem : I'd like to submit this as a Feature Request. We are getting SeAT notifications in Discord, but urgent notifications (station attacked, fuel, etc.) are very easy to miss given that the notifications only highlight the channel as containing unread messages. I'd like to be able to use the @here, @ALL or even @'specific-person' for certain notifications.

• Version Info:

Docker SeAT v.4.x

SeAT API Installed: v4.9.0
SeAT Console Installed: v4.8.0
SeAT Eve API Installed: v4.20.4
SeAT Notifications Installed: v4.3.3
SeAT Services Installed: v4.3.0
SeAT Web Installed: v4.20.0

[recursivetree]

I'm in favor of implementing this, it seems like a nice addition. seat-alliance-industry can already do it: https://github.com/recursivetree/seat-alliance-industry/blob/master/src/Notifications/OrderNotificationSlack.php#L29-L41

The most difficult question is how to implement it: We don't have one place to inject it, instead we'd have to modify every slack notification. Of course we could also finally improve how notifications work, but I think it's too late for seat 5, and it would contain a lot of breaking changes.

[tehraven]

I'm in favor of implementing this, it seems like a nice addition. seat-alliance-industry can already do it: https://github.com/recursivetree/seat-alliance-industry/blob/master/src/Notifications/OrderNotificationSlack.php#L29-L41

The most difficult question is how to implement it: We don't have one place to inject it, instead we'd have to modify every slack notification. Of course we could also finally improve how notifications work, but I think it's too late for seat 5, and it would contain a lot of breaking changes.

Could we implement a boolean at the AbstractNotification level and a checkbox (default false) on the UI so that people creating Notification groups could opt into their webhook pushes being prefixed with @here or something?

[recursivetree]

Yes, that's probably the best approach, but the thing is, AbstractNotification doesn't have any hook to inject the ping into the SlackMessage. This means we'd have to modify every single notification, since the SlackMessage is only accessible in the toSlack method of the actual notification implementation. For the core, this isn't a huge issue, it's just some boring work. What I worry about is plugins: They need to be changed too.

[recursivetree]

Maybe what we could do is to implement a toSlack()method in seat 5's AbstractSlackNotification and require an abstract populateMessage method that the individual messages implement. That way, toSlack() in AbstractSlackNotification could create the SlackMessage, add pings and pass it to populateMessage. That's probably the cleanest design, but it breaks compatibility, meaning we'd have to get it in seat 5. @warlof Is that still an option, or how close are we to release?

I'd implement it if it's wanted.

[recursivetree]

I decided to go the route of updating eveseat/notifications#60 to seat 5 and then implementing notifications on top of it: eveseat/notifications#81