Notification if a blog's status is 0 when added, and set to "published" later

1) If a blog's status is 0 by default, and then it's set to "1" later by a person or through Drupal's interface (therefore doing a node_save), is the module going to send the notifications *then*?

Yes, if you publish by saving the node, then this is how it works. Notifications are not sent when you do bulk publishing through Administer|Content though.

2)
In Free Software Magazine, blog entries are published by default. Then, I have a custom module that hooks to nodeapi and "unpublishes" them on the fly if they are from our columnists, which means they need to be edited. The nodeapi hook is called before Subscriptions' (the module starts with a "b"!). Apart from the fact that this is a little fragile, will it work OK with "subscriptions"? (I do a DB update and then set $node->status=0 when I sneakily set the entry to unpublished). The "theory" is that "subscriptions" won't even notice that $node->status was ever "1". Do you think my theory "holds"?
(I think it does. However, there is some seriously involved testing in this, and I will only do it if you *think* it will work)

Yes, that should work. Actually, it's a bit more stable than you think, because subscriptions_content.module ensures that it's heavier than taxonomy.module (which has a weight of 0). So, unless you weigh down your custom module for some reason, it will definitely run before subscriptions_content.

The weight is set in subscriptions_content.install.

I intend to look into mass-publishing, hopefully today. The idea is to alter the form so that my function is called first, where I can do the queueing, and then I'll call the original function.

You can assemble an event object as it's done in subscriptions_content_nodeapi() and call subscriptions_queue() with it, assuming you're dealing with simple nodes.

If you have special requirements for your content type, you can either implement a special GUI for them (subscriptions_blog_ui.module is an example) and keep using subscriptions_content.module, or your own Subscriptions add-in module (see the separate subscriptions_og project).

It doesn't keep track of sent notifications. Those that are sent are removed from {subscriptions_queue}, that's all.

If you unpublish and republish (without unchecking Send subscriptions notifications under Publishing options), new notifications are sent.

Merc, I too would be interested in a patch that made the subscriptions module keep track of the notifications it has already sent out. Do you want to open a new issue for that? I would need such functionality for example for the intelligent "send notification" link that I am planning, see http://drupal.org/node/214495.

@mercmobily:

I have the feeling this behaviour might become problematic for most sites.

Why do you think that "most sites" will keep turning the published state on and off continuously?

I believe that turning it off (after it has been on and notifications have been sent) and then turning it back on would be a very rare exception that is covered by the checkbox in the publication options. Am I missing something?

At this point I see little benefit in introducing a table that keeps on growing indefinitely, so no, there are no plans for such a feature. Maybe you can convince me otherwise, but so far I don't think this is core functionality, and it would be best to put this into an add-on module.

I will certainly help if you want to work on it.