Not planned Notification System

kick

Well-known member
If you look like this, the notification system in XenForo is made crookedly, crutched and not quite as beautiful. For example, if I do not want to use this built-in push notification system and replace it with another which is supported on the iPhone and not only. But in XenForo, this is very limited with all systems. Something is sent by services and a push notification is sent there, something is in Notifier. Mail is also separate and somewhere it’s not entirely clear why all these restrictions and such crutches are necessary. Notifier is more like an attempt to create such a system, but all this is scarce and not only.
Let's go back to the limitations, in order to do something, you have to crutch to change the push or the ability with other services. After all, the same OneSignal is supported by iPhones and not only. Why can't I just use the trait to specifically alert? Do not set a specific type of alerts I need
There are a lot of features and services for push alerts, and if you select it for replacement, you may encounter problems in XenForo. Let's look at a simple example of push notification services:
  • OneSignal
  • Pushover
  • Pushbullet
  • Pusher push notifications
  • Web push -> current
  • Pushwoosh
  • VWO Engage
And these are just Push features, but if besides all this I want to send sms / voip to users? Or in modern instant messengers like telegram, discord, twitter and so on? You’ll have to expand everything with crutches to add support.
Therefore, it’s very good and convenient that the engine has the ability to create notification channels, in addition to notifications and a limited push notification service in the form of Web push.
In addition to all the alerts that are set static in classes with the ability to take phrases, they somehow don't look very nice. Why not use class building for alerts and just send a class that is implemented by a specific message?
At the moment, the notification system does not look very pretty and like one big crutch for the whole engine.
In addition, why can not I use this view to determine the message and data which should I send in this way? $this->notify (MyClassNotify());. Why do you always need to come up with crutches. In it, to define an already defined method for communicating an alert phrase and not only. Which can be further expanded without problems and redefined as a last resort. And right now there is a similar system in the form of Notifier, but it doesn’t look very
 
Upvote 3
This suggestion has been closed. Votes are no longer accepted.
It's possible to make a suggestion without implying that something is made "crookedly, crutched and not quite as beautiful". What I think you are asking for is a system whereby multiple providers of push services can be used.

We have absolutely zero intention, at this point, of implementing other push services, and we never have, hence why the system was built how it was.

We are going to continue waiting for Apple to implement the same web standards that every single other browser vendor has been capable of implementing. These are web standards that are free, open, widely supported without additional apps, and very easy to configure.

It is nothing but an absolute shear failure of Apple that those devices are currently excluded from supporting the same web standards as every other.

We will continue to support these progressive web standards and not surrender to other methods which may cost money, open our customers up to complex and far-reaching privacy policies and terms and conditions.

Suffice to say, there's nothing actionable in this suggestion so it won't be considered.
 
It talks about a normal notification system and not a mixture of all that is possible. And not the ability to establish their channels. Where with this system you can forget about everything since it has not been done humanly. It does not talk about suppliers of push, there are in addition to all this and sms / voip alerts. Alerts in modern messengers and in normal the whole alert system can not be done. Only crutches.
We will continue to support these progressive web standards and not surrender to other methods which may cost money, open our customers up to complex and far-reaching privacy policies and terms and conditions.
Good joke and so was Authy added? https://www.twilio.com/authy/pricing
If I want for example for SMS notifications from the forum to the user and if you inherit from the notification system, I could send SMS through the service without any problems.
E.g: https://www.nexmo.com
So at the moment I will need to expand not 1 class of the engine to get into the services of the engine, because there is no standard, and it's cool. Suppose I want to receive SMS alerts about new profile posts or comments? And I get into this whole system and expand the classes. Or another simple example. If I want for example for SMS notifications from the forum to the user and if you inherit from the notification system, I could send SMS through the service without any problems. So at the moment I will need to expand not 1 class of the engine to get into the services of the engine, because there is no standard, and it's cool. Suppose I want to receive SMS alerts about new profile posts or comments? And I get into this whole system and expand the classes. Or another simple example about creating correspondence, I have again where to climb? In the engine.
1575127396849.png
A smart site in the service is not it? And most importantly, how well and beautifully this is done. It seems to be working, but we cannot work with something else custom. The notification system seems to work, but expanding and making friends with other services and capabilities is very, very problematic. Again, what prevents me from calling a class that implements a certain interface, for example, and you can easily add and modify everything with extensions.
Besides all this, with this approach and without channels for the notification system, I cannot postpone the notification for a certain time.
To all this, I’m not saying that even attachments cannot be sent if you need to need it from the notification system. To all this, even there is no event for the sent notification, but if I want to catch it and pledge it somewhere? Also impossible.
Why should I send this kind of alert?
PHP:
$alertRepo->alert(
            $user,
            $this->author['user_id'], $this->author['username'],
            'user', $user->user_id,
            'from_admin', $alert
        );
Why can not I send an alert on the channel in which there would be a clear definition of the class and in addition to it I would determine where to send or why?
In addition, why can not I use this view to determine the message and data which should I send in this way? $this->notify (MyClassNotify());. Why do you always need to come up with crutches.
If I want to define this message for push, SMS and some sort of messenger I would redefine where and everything in the channel. I wouldn’t have climbed from the beginning of the class extension to ending in this class by redefining the functions.
I wrote my driver for the channel and defined it in the send method. And in the system I determined through the via method I determined or registered my channel. Yes, even through the same event handler that loaded the custom class of the notification service. And at the moment, this whole system is absolutely unfinished.
The essence of the normal notification system is that it would be possible to connect any service for alerts without problems, starting from instant messengers to SMS alerts.
 
So at the moment I will need to expand not 1 class of the engine to get into the services of the engine, because there is no standard, and it's cool.
All alerts go through \XF\Repository\UserAlert::insertAlert(), which is a fairly straight-forward extension point for pushing alerts through to 3rd-party services via an add-on. Conversations are a bit of a special case since they're not truly part of the alert system, but you can hook the conversation notifier for that as you've already deduced. Two class extensions isn't really that bad.
 
All alerts go through \XF\Repository\UserAlert::insertAlert(), which is a fairly straight-forward extension point for pushing alerts through to 3rd-party services via an add-on
You suggests reoverride this function fully? This is dumbest solution.
I use event listener for entity_post_save with hint XF\Entity\UserAlert with additional checks like $entity->isInsert().
 
You suggests reoverride this function fully? This is dumbest solution.
Of course not. Just extend it and call parent::insertAlert(...) like you would with any other method extension, tacking on whatever bonus handling you need to pipe the alert to other services.

I use event listener for entity_post_save with hint XF\Entity\UserAlert with additional checks like $entity->isInsert().
That works similarly I suppose, though you're still in the middle of the database transaction at post-save time so depending on how your code is structured I'm not sure it's a great place to be sending network requests to 3rd party services.
 
ust extend it and call parent::insertAlert(...) like you would with any other method extension, tacking on whatever bonus handling you need to pipe the alert to other services.
This is nice works only if you don't want created XF:UserAlert entity.

For example, i wrote small addon for own usage. Addon send notifications from forum to Telegram. For reusing existing templates for alerts, i call XF\Entity\UserAlert::render() method and push result HTML to Telegram API.
 
Oh okay, if you need the alert entity then that is a better extension point. In either case, it's still two extensions to hook all alerts and conversations which I really don't think is too painful.
 
Partly you're right @Jeremy P. But as always there is a but. In the future, we simply create crutches and no more. Which besides all this, it goes through memory every time and checks for extensions. The problem with the class extension system in XF is very strong. Also, the problem of many developers, they default to run priority 10, which also causes problems in the future or with a very high range of add-ons. Why do we need to expand and reinvent the wheel? When any popular framework uses a similarly similar channel system for notifications. Again, this will not cover 90% jumping from that class. But it will solve a lot, but again we will take into account the additions and if there are a lot of them, then you will have to write a system for this and your entire notification system that will allow it to be downloaded. But again, restarting this method with more than 1 add-on will hurt. With a normal notification system, it would be easier for everyone. Yes, of course, for yourself you come up with a bicycle, as they say from sticks and ... But this will not be normal anymore and this is a different story. For social publications on the same twitter, and not only can everyone catch _postSave at all, and this will also be a solution. The system works well, it’s not interesting for developers to better live with crutches again for several years, both with the first branch and changes in the second. True, a crutch with a database is not clear when there is a doctrine, it is also a different story. And hope for version 3 in 10 years, which will change this system and implement channels for notification system. And also with a change in the approach to the notification system
 
Back
Top Bottom