Custom subscription role, description and UI clarification

Take a look at the function that builds custom subscriptions and adds rows to the notification_fields table:

function notifications_custom_build_subscription($type) {
  if ($subs = notifications_custom_load($type)) {
    $subs->type = $type;

    $fields = $subs->fields; // parse each field as a type and value combination
    $subs->fields = array(); // reset the fields property of the subs variable
    foreach ($fields as $field) {
      $subs->fields[$field['type']] = $field['value']; //*** this line will write over any existing fields of the same type ***
    }
    return $subs;
  }
}

Note the line I commented with ***. This is where the subscription type is extracted from the fields column in the notifications_custom. Here is an example of a custom subscription where two content types have been defined in the same custom subscription. This is the contents of the fields column:

a:2:{i:0;a:2:{s:4:"type";s:4:"type";s:5:"value";s:11:"node_type_1";}i:1;a:2:{s:4:"type";s:4:"type";s:5:"value";s:11:"node_type_2";}}

The first time through the foreach loop the node_type_1 will be assigned to the subscription but the second time through the loop this value will be replaced by the node_type_2.

This at least explains that it isn't a boolean issue at all. I don't have a solution though I agree this limitation should be clearly pointed out to custom subscription administrators via the UI.

This is explained in the documentation but it's something that tripped me up too when I first started using the module. I agree that it should be made more clear, and ideally other options given as well. There is at least one or two more issues that mention this floating around, for instance #521974: The future of custom subscriptions. Jose expressed interest there in having another module that provides the kind of "bundling" functionality that you describe, rather than try to incorporate it into custom subscriptions.

Why does there need to be yet another module? Does scope of custom subscriptions module preclude its modification to include this type of functionality?

Yes, there are some limitations to what you can do with notifications_fields atm. However, there are enough hooks around so a module could fill in the 'notificaitons_queue' with additional rows, that's the option if you want to implement some complex php logic.

About taxonomy terms, yes, current modules only allow subscriptions to specific terms. It is possible though to build another subscription type that throws in different conditions to the query.

The main question that we need to balance if building more complex conditions is whether it will perform for a huge site with thousands of users/subscriptions, that's why php logic doesn't seem an option here, though as said before it can be implemented by a plug-in module.

However we could extend the queries to make them more flexible, like using 'conditions >= x' instead of 'conditions == x' (that would allow some limited 'OR' conditions. Also some 'fuzzy logic' could be considered here, like adding a weight to each field condition, then checking if the conditions weights are bigger than some value.

So all this would be considered if someone comes up with some proof of concept that makes sense for using more flexible conditions. Not really interested in just extending the API without a proven idea of how to use it.

Jose,

Maybe you could elaborate on the performance issue. Is it the impact when the notifications_queue is being populated due to a node creation/update trigger or impact on the notifications table when creating custom subscriptions.

The original question raised by the OP and faced by me and others is the lack of clarity and flexibility around the creation of custom subscriptions. Once I figured out how the module logic and knew that I had to create a separate custom subscription for each content type it was a laborious process creating custom subscriptions for five content types for 120 users. It would have been five times faster if the boolean logic worked as I had hoped.

In the immediate term the lack of clarity could be addressed with a little extra documentation in the UI. In the short term, if the boolean logic could be implemented it would make administration a lot easier without impacting performance. In the longer term the more complex logic of mixing and matching trigger types and other factors could be considered.

In summary, it would seem to me the documentation and boolean logic would be relatively quick wins that would improve the utility of this module significantly.

Well this has become a pretty stale issue... I don't think Jose is even the maintainer of this package any more, and custom subscriptions has been moved to Notifications in the latest release- I don't know if these issues have been addressed there, but I doubt that more development is going to happen on 2.x. So it might be best to close this, and if there are unresolved issues, consolidate them in a new issue in the appropriate queue.