Relationship table getting bloated with notifications que

Whenever I create any entity, in my relationship table, new entries related to notification methods are getting added.

Please see the notify:email relationship in the image below

I tried all permutations and combinations, mentioned in 

But I am unable to prevent this. Which hook should I listen to prevent this? On elgg 4.3.7

 

  • It's normal and Elgg core's standart action.

    You can unregister 'email' notification method globally via custom plugin:

    elgg_unregister_notification_method('email');

    Look at this plugin also. I believe you can update it for Elgg 4.

     

  • It's completely normal for this to happen.

    The system needs a way to keep track of which user is interested in which content. This is done by relationships.

    If you comment on a blog you're probably interested in what others comment on that blog (maybe even in reaction to your comment). So we keep track.

    Yes this can be a lot on larger communities, but do you experience problems with this? If so do you have a better system? We're always open to improving Elgg.

  • @NIkolai: the code, you suggested removes entire email notification system. Its like for treating a small ulcer in little toe, you are doing an amputation of the limb. ;)

    @Jerome: I understood the logic on creating subscription to some entities (provided these entities are useful / visible for the users) for receiving future updates on that entity.

    But imagine a case scenario where I am creating an entity for internal need only - this entity is never exposed to the end user - (no user will be able to edit / delete / view / comment / like on this entity). In such case what's the use of subscribing the user to this entity? In my special case, I need to create numerous such hidden entities, which is causing unwanted entries in the relationship table. Can we have an option as below, so that developer can easily disable user subscription to specific entities?

    • through the elgg-plugin.php file
    [
        'type' => 'object',
        'subtype' => 'tokens',
        'class' => 'SysTokens',
        'capabilities' => [
            'commentable' => false,
            'searchable' => false,
            'likable' => false,
            ........
            'subscribe' => false,
        ],
    ],  

     

    Thank you.

  • But imagine a case scenario where I am creating an entity for internal need only - this entity is never exposed to the end user - (no user will be able to edit / delete / view / comment / like on this entity). In such case what's the use of subscribing the user to this entity?

    Good point.

    I like your suggestion of a capability.

    For now you can always listen to the 'create', 'relationship' hook. You can than check if it's a notification relationship with your entity and return false.

  • Thanks for considering the feature request, and the clue Jerome :) 

  • @Jerome: I looked into the code where relationship is created between the two entities and I noticed that the event is triggered after a relationship is created. Currently it is like

    1. A relationship is created
    2. If there are some event listeners which doesn't want this to happen, then the relationship is deleted from the database.

    This logic seems to be wrong. Why do we need 3 unnecessary db queries - read (check existing relationship) + insert (insert new relationship) + delete (delete current relationship created as it matches our condition)? Cant we prevent the creation of relationship first place itself?

  • This logic seems to be wrong. Why do we need 3 unnecessary db queries - read (check existing relationship) + insert (insert new relationship) + delete (delete current relationship created as it matches our condition)? Cant we prevent the creation of relationship first place itself?

    Agreed, but legacy code can sometimes be a pain ;)