Hi, do you thing, it is possible to do rules integration of this module? :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

salvis’s picture

Sure. Do you want to work on it?

What actions do you have in mind?

thadwheeler’s picture

I am interested in this as well.

I have a site where I need to send periodic reminders and updates to users that are subscribed to specific "statuses" of content ( i.e. This content has not been updated for 10 days and is in the "Draft" workflow state)
I think rules integration is what I am looking for to trigger the sending of my notifications.

My thought was to set a taxon field on each node to one of my statuses wiith a rule. So if node is published, in pre-draft workflow state, 4 days since creation set Notification Level to "Item not yet promoted to Draft - 4 days"
Users subscribe to specific taxonomy terms like this based on what they need to see.

Then I am hoping subscriptions will take care of sending..

salvis’s picture

Assigned: jasom » Unassigned

@thadwheeler:

Yes, using an on-update taxonomy subscription should work. Nice idea! And it doesn't even need any Rules integration, so you should have started a thread of your own.

So far no one has confirmed that the way Rules saves a changed node does indeed trigger Subscriptions to send update notifications, but I'm pretty sure it does.

thadwheeler’s picture

@salvis

so by saying I don't need the rules integration are you suggesting doing it in custom code?

I need to test each "issue" node each day to see what status to apply to it. I was thinking without rules I need to hook into cron (hook_cron) and run through each node - that's not in a certain status - then test each. Setting the status as I go.

Any thoughts or suggestions on this idea?
I am comfortable with the PHP but I am still learning my way around the API.

salvis’s picture

Category: task » support

No, I'm suggesting to see if it will just work.

I need to test each "issue" node each day to see what status to apply to it. I was thinking without rules I need to hook into cron (hook_cron) and run through each node - that's not in a certain status - then test each. Setting the status as I go.

This is too abstract. I don't understand what you're saying. I'm not even sure what you're saying relates to Subscriptions and "Rules integration" (which would mean that this is the wrong thread)...

Oliver Huynh’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Component: Miscellaneous » Code
Category: support » feature
Status: Active » Needs review
FileSize
2.51 KB

I attached below a simple integration between subscriptions and rules.
It provides two actions: subscribe/unsubscribe a user to content for now. I will provide more if you guys see that this is valuable.

To use this, we need a module_load_include('inc', 'custommodule', 'subscriptions.rules') in your custom module. But for ported, this code should be moved directly to subscriptions.module.

Updated: Attachment has been updated in next comments.

Oliver Huynh’s picture

Latest code is attached

salvis’s picture

Status: Needs review » Needs work

Thank you, this looks interesting. We need reviews, please!

Please turn it into a module that can be activated if desired, rather than relying on a third-party module calling module_load_include(). Either put it under subscriptions/contrib/subscriptions_rules and post patches, or create a sandbox project under your own account if you plan to turn it into a full project.

Oliver Huynh’s picture

Status: Needs work » Needs review

I added a sandbox project and added some more actions. Pls review.
URL: http://drupal.org/sandbox/oliverhuynh/1591962

salvis’s picture

Any interest in this?

bulat’s picture

Well, we have done rules integration with Oliver's code. It will be grate if rules were supported by Subscriptions out of the box.

bulat’s picture

Here are my thoughts on the code in Sandbox:

Rule callbacks should leverage functions from the core module. If we take subscriptions_rules_add_user_content_callback() for example, it knows to much (more than Subscriptions module itself) about the db structure and therefore there is too much code dealing with tables records directly. What we should see ideally is this:

/**
 * Rule subscriptions_add_user_content callback
 */
function subscriptions_rules_add_user_content_callback($node, $user, $type = 'node', $send_interval = "") {
  // Prepare params.
  $send_comments = ($type === 'comment') ? TRUE : NULL;
  $send_updates = ($type === 'node') ? TRUE : NULL;
  $send_interval = is_numeric($send_interval) ? $send_interval : NULL;
  // Write subscription.
  subscriptions_write_subscription('node', 'nid', $node->nid, -1, $user->uid, $send_interval, $send_updates, $send_comments);
}

This is much less code which is easier to read and if signature of subscriptions_write_subscription() does not change, it will not need to change.

This also means that once subscriptions_write_subscription() is covered by tests we will not need to worry about tests for subscriptions_rules_add_user_content_callback().

I think all the fancy logic (if it's needed at all) should be moved to subscriptions_write_subscription() so all extensions could enjoy it.

I also want to thank Oliver for the great work he has done, amazing attention to details shown in the code.

zorax’s picture

Hello,
I just test the subscription rules module, it is very usefull!!
Can you just tell me how to add the possibility to subscribe to a taxon, because there's only subsrciptions to :
-user to node
-user to node type
Regards,

salvis’s picture

#13: Your question is completely unrelated to the topic of this thread. Please create your own issue.

mattsmith3’s picture

I would love to see this as part of the subscriptions module.

Oliver Huynh’s picture

Hi,

I would prefer my sandbox (http://drupal.org/sandbox/oliverhuynh/1591962) to be integrated with Subscriptions but if not, I can promote it to full project.
Tell me your thoughts.

mattsmith3’s picture

I think rules integration for subscriptions is a brilliant idea. As far as I can tell, the sandbox module works wonderfully.

bulat has a nice point regarding more direct subscription module integration. It seems that reusing some of the core modules' functions would be smart, but honestly, I don't consider myself qualified to speak to that issue. I only wonder if this is a concern for maintainers?

As to the question of promoting to a full project:
There is no doubt in my mind that people need/want this functionality. With flags, subscriptions, this sandbox module, and 10 minutes you can build the drupal.org follow issue functionality with ease. With the flexibility of that same flags/subscriptions/rules integration the implications of UI/UX hotsauce and flexibility just makes my mouth water. Any application of a CRM or Project Management implementation in Drupal could certainly use this.

It looks like salvis is a maintainer. If they are not ready to add this directly, I'd say promoting to a full project is the way to go. Converting the sandbox to a full module would get this idea more usage, and hopefully more contributors to the conversation. With some traffic on the module usage and a little time this would be a perfectly logical addition to the subscriptions module.

What are the maintainers thoughts?

salvis’s picture

Personally, I rarely use Rules and don't intend to use it with Subscriptions, so I'm not in a good position to evaluate the quality and general usefulness of the sandbox code. That's why I've asked for feedback, and until recently we've gotten just about none.

Is this the proper way to integrate with Rules? Is it usable? Does it cover the most common use cases? What is missing? Not that we have to add everything immediately — if we get reasonable base functionality then I'm happy — but we need to have an idea of where this might be going.

Looking at http://drupalcode.org/sandbox/oliverhuynh/1591962.git/blob/183fda1f4c435..., the code looks clean. There are some minor formatting and especially commenting issues. Also, quoting in translatable strings should be avoided.

The comments in #12 are definitely worth discussing. The base module should provide the necessary functions to manage the database; if database access is duplicated and distributed everywhere in the code base, then maintainability suffers. We should rather work on a flexible API, so that other future functionality can profit form a higher abstraction level.

The use of call_user_func_array() hurts maintainability and I rarely see your pattern of gathering arguments in enumerated arrays in D7.

* TODO: user_access needs to be implemented.

That said, I'd be happy to get the Rules integration into Subscriptions, if we can manage to make it a bit more Drupal-like. The next step into that direction would be to get a patch here in this issue, and I think that should also result in more exposure and feedback.

jcam88’s picture

Great sandbox module. Would appreciate an additional rule that provides a "Delivery of Notifications" toggle.

vuil’s picture

Issue summary: View changes