How to send notifications from a plugin

I’d like to add new notifications in a plugin. They should be handled the same way as “official” notifications, respect the user settings, etc.

Is this possible and/or supported in any way? Any hint is greatly appreciated.

OK, I got it. But it was a really nice climb. :wink:

1 Like

Thoughts on notifications

After digging a while, I came to the conclusion that it isn’t possible, at least not properly. Some facts:

  • All existing notifications are bound to task events. What if my plugin should issue a “neutral” notification, not bound to any task?

  • All existing notifications, their events, and event builders are hard-coded in the classes NotificationModel and NotificationSubscriber.

But wait, this is OOP, we can derive. In my current solution. I’ve installed my own NotificationModel, derived from the original and using my event builder. Further, I’ve installed my own Mailtype handler, to react to my events. For the type “web” I could use the original one. Everything works fine so far.

But what if another plugin wants to do something similar? I’m quite certain that this will break my solution. Is there any way out, writing plugin notifications without blocking other peoples solutions? I desperately hope, someone can help me out. Maybe @fred?

Any feedback is appreciated.

I’ve been on that route as well, that’s why I mostly try to use hooks or alternate routes for my plugins.

That doesn’t work for all cases though

1 Like

Its been awhile, maybe not what you are looking for.

Create an event and push it the the task event job with params.

And then trigger the event…
$this->multiselectMemberModel->assigneeChanged($task, $values);

Thanks for your input. Indeed, that will emit a standard notification for that well-known event. All these events are routed to the standard Notification Model, and they are all task bound.

But I’m looking for a more general solution: My event and my job should end up in a notification to all registered handlers. (email, web), where my Event builder is responsible for generating the output. It’s a bit more, I know. :wink:

Whatever solution I try, it will disturb other plugin devs doing the same, or they disturb me. Replacing standard Kanboard models works like a charm, as long you’re alone, but it definitely opens a door to hell.

So just registering new events, and triggering them, doesnt integrate seemlessly? I havent played around much with these.

i.e.
$this->eventManager->register(...

Of course, this works, but it doesn’t create a customized notification that users can (un-)subscribe to.

I think im starting to understand.

Im just gonna mentally propose the following.

Add the subscriptions, via settings? True/False.

Build the arguments into the notifications.

From my memory/understanding, you have to trigger the event, and call the appropriate notifications, if the setting is false, you can just bypass it, right?

Yes, your profile settings -Notifications. Select there what you’re interested in.

Sorry, when i say settings, i meant configmodel.

But if its a user based, it would make more sense to use the usermetadatamodel.

Either way, im not seeing the issue yet. Again, im just problem solving this in my mind, so what am i missing thats causing the difficulty?

My goal: On some action in the plugin, I want to issue a Notification on any known channel, e-mail and web, containing my content. This should use the standard notification system in Kanboard where users can subscribe for notifications of interest.

I don’t want to add a completely separated additional notification system.

well you can always build a notification system yourself with the database

As I said above, this is not whet I aim. I’d prefer to integrate my notifications into the existing environment.

I cant fault you for that. I would see user metadata as the existing environment i have to work with. I did not however see any hooks on the notifications template, but im sure a pull request could fix that.

To send notifications to users?

No, for your user setting to determine if they do or do not want the notifications.