How to manually trigger notification events in 1.9?

In 1.9 you can subscribe users to entities, then use elgg_register_notification_event() to have Elgg send notifications when an event happens, like a comment creation.

But when a likes annotations is created, I'd like to walk up to the containing object (like might be on a comment) and trigger the notification on that. E.g. Someone likes a comment on a page => trigger a notification for those subscribed to the page.

Any ideas?

  • It looks like I'd have to create a custom object-based event like "commented_on" then figure out how to trigger that.

  • For each obejct subtype in the system, I have to call elgg_register_notification_event() and register the type/subtype with the action "commented_on".

    Then whenever the like is made, I have to manually trigger a "commented_on" event on the container object.

    This will result in _elgg_enqueue_notification_event() being called on that event and, since I pre-registered the event, it will enqueue a real event in the system and be handled in cron/minute.

  • It seems for the likes there's no notification event registered that would then get triggered in the action on adding a like. Instead the likes_notify_user() function is called directly in the action. If the notification event would be registered, you could unregister it, then register your own notification event with your custom callback function. Within the callback function you could check the type of the entity that was liked and in case of a comment entity you could implement an alternative notification with the comment's parent entity as notification entity.

  • @iionly That seems like it would work, but I'd prefer to send the notifications through Elgg's new cron system. Conveniently it would only handle non-owners of the content so no one would get duplicate emails.

    One issue with the approach I'm taking is that the context of the like is lost when writing the email body. Let's say 100 is a page, 101 is the comment on the page, and someone likes the comment. The subscription would know that 100 received a like (for notifications purposes), but notification event would no longer know that the like was more precisely on 101, not 100. I need to somehow have the queued notification event hold some arbitrary data.

  • I also have the need to get this working in 1.9.

    Group discussions get around the context issue by registering to the 'get', 'subscriptions' hook and returning the subscriptions of the container in case the passed notification object is a discussion_reply.

  • Question: is the likes plugin of ELgg 1.9dev currently even using the new Elgg 1.9 notification implementation? There's no notification event registered with elgg_register_notification_event() and no elgg_register_plugin_hook_handler('prepare', 'notification:...', ...) handler registered. Though this might be due to this way not working for annotations (if I got your issue posted on github correctly)and therefore notify_user() is used.

    It would be nice if the following would be working:

    elgg_register_notification_event('object', 'all', array('liked_on'));
    elgg_register_plugin_hook_handler('prepare', 'notification:liked_on:object:all', 'liked_notify_message');

    in the init function and the event trigger in the add action (elgg_trigger_event('liked_on', 'all', $entity);). Then you could unregister the plugin hook defined in the likes plugin and register your own that might handle likes on certain subtypes differently.

    Sadly, 'all' (= any kind of subtype) is not supported. Additionally, I made some tests with this approach registering the notification event specifically if a blog entity is likes. But for whatever reason this only worked once and failed on any subsequent tests. I couldn't even find out if it's possible to retrieve the actor (= the user who made the like) within the plugin hook callback function.

    I wonder, considering that the Elgg 1.9 notification system is not used within the likes plugin, wouldn't it be better to introduce a plugin hook nonetheless that gets triggered within the add action instead of calling likes_notify_user() directly? Then you would at least be able to modify the notifications via a 3rd party plugin which seems currently not possible. As Elgg 1.9 is not yet released it might be the right time now to decide on this.

  • @iionly It has already been decided that there's not enough time to make the new notifications system to support annotations and relationships in 1.9.

    Also the subscriptions system needs to be made a bit more sophisticated before we can extend the notifications system.

    wouldn't it be better to introduce a plugin hook nonetheless that gets triggered within the add action instead of calling likes_notify_user() 

    Elgg already triggers 'create', 'annotation' event when a like is added. This can be used like Steve explained (commented_on event).

  • @Juho: but Steve also mentioned that his "commented_on" event approach has some limitations like the context of the like getting lost. I also think that this additional event will only allow you to trigger sending of an additional notification but not prevent the original notification from getting sent. So, the users will receive 2 notifications on the same action.

    I've read about the decision to not support annotations in the new notification system for Elgg 1.9 anymore due to time. But would the introduction of a plugin hook be too much either? As I see it this change would only mean some minor modifications in the likes plugin itself.

  • But would the introduction of a plugin hook be too much either?

    It's not wise to add a new plugin hook that would become deprecated in the next version.

    So, the users will receive 2 notifications on the same action.

    Actually no, the notification system currently sends only the messages that are sent to mupltiple people.

    Two examples with different results:

    1. Someone adds a comment on your blog
      • Only you get a notification
      • The notification is NOT sent through the new notifications system but instead instantly using the old way
    2. You make a blog post
      • Notification is received by your friends who have subscriped to get notifications about your actions
      • The notifications are sent by the new system (triggered later by cron)

    If we add a event handler for 'create', 'annotation' that creates a new notification object when a like is added, similarly only the people in the 2. example receive the notification, not the owner of the liked content.