apply "type" template for "nid" subscriptions

No, sorry, I can't accept #1. chx has looked deeply into making immediate sending work, and it won't. The problem is that you can't do proper access checking at that point in time, which is a limitation of core. This is one of the issues that has always plagued 1.x, and we're not going to introduce it in 2.0.

You'll have to explain #2 a bit more. The user can freely choose whether he wants to subscribe to the node or to the type. Why would you want to enter a type subscription if the user chooses node?

#2: No, it is not related to change user subscription type, it is only about template applying. For example:

1. User subscribed to the specific forum message, say /node/222.
2. On new comment it got a new record in table subscriptions_queue with module/type/value to be node/nid/222.
3. And on actual sending template subscriptions-node-nid will be applied, instead of more relevant subscriptions-node-type-forum.

That is the problem. It is pretty difficult to create universal subscriptions-node-nid template, which contain useful information for all node types. And i just don`t know how to translate such universal template properly to my language (Russian). Additionally, !term_name does not work for subscriptions-node-nid.

My solution is simple -- determine node type at sending time and use proper template subscriptions-node-type-forum.

This is an interesting idea, and it could work for update notifications, but I don't think it's appropriate for comment notifications.

I use Subscriptions to send full bodies for the type and taxa subscriptions. However, there's no point in sending those bodies over and over again with every comment notification. On the contrary, I do want (full) comment notifications to go out as node/nid, which only has the title (and maybe the teaser) of the original post.

The issue is different for update notications -- there it might make sense to convert node/nid into type/typeid.

Please take a look at the new templates...

I've been thinking about converting node/nid notifications of updates to the appropriate node/type/typeid notifications in order to get the custom format and full selection of variables for the type.

The problem I see is that the admin may have put the type on the omitted list and not have defined the template, and so he might be taken by surprise to suddenly have notifications go out with a template that he didn't expect to be used.

If I understand this issue correctly then currently a user gets the notification emails styled with different templates depending on whether they subscribed for all nodes of a particular type or only to a specific node of that type. This I find very confusing.

Salvis, the confusion on the part of the admin could easily be avoided by explaining this in the installation instructions.

Hmm, I'm not sure what to explain.

You simply get what you ask for. If you enter a node/nid subscription, then you get that generic/comment-oriented template; you never get that for a new node, of course, because you need to have the node first, before you can enter such a subscription. If you enter a node/type subscription you get the template for that type. If you enter a taxa subscription, you get the taxa template.

If more than one subscription is triggered, then they are queued in the order they are triggered, which I believe is
1. any subscriptions outside of subscriptions_content.module (blog is inside)
2. node/nid
3. node/type

This is how they go into the queue, and if they have the same Send Interval, then the first one wins.

As we've already found above, it might make sense to use the appropriate node/type template in the case where node/nid is triggered by an update, but only if the type is not omitted.

I guess there is something that I could explain, but does it make sense to explain that?

Marking this fixed. I implemented sending node/nid updates as node/type.

For non-updates (i.e. comments), node/nid is more appropriate IMO, because we don't want to keep sending the root node over and over again.

Due to a limitation in core, instant sending cannot properly respect access control. So this part of the issue is a "won't fix."

Automatically closed -- issue fixed for two weeks with no activity.

I like this idea of using the type templates for notifications of new and updated nodes while using the nid templates for comment notifications. I think this principle should apply in general. All notifications of new and updated nodes should be using the appropriate type template, irrespective of whether they come from a nid or a tid subscription.

I have tried to describe the current situation on the help page at http://drupal.org/node/344030 as follows. Did I get it correct?

You will find that the subscriptions module is providing a range of templates. Which template is used for a particular notification depends on the kind of subscription that is triggering it. So for example a notification that is sent because the user has subscribed to a taxonomy term will use the subscriptions_taxonomy_node-tid template. Notifications that are sent because the user has subscribed to a content type will use the content type specific template, for example subscriptions_content_node-type-blog for a subscription to all blogs. Similarly, a notification that is sent because the user has subscribed to a specific node will usually use the subscriptions_content_node-nid template.

However, there is an exception to the above rule: notifications of updated nodes that are sent because of a node subscription will nevertheless use the content-type-specific template, but only for those content types that the user could subscribe to. Note that this exception is only used for subscriptions to individual nodes, NOT to any other subscription type. So, for example, if a notification is sent out about an updated book page because the user has subscribed to a particular taxonomy term that the book page is tagged with, then the notification will NOT use the book page template subscriptions_content_node-type-book but the generic subscriptions_content_node-nid template.

Re #10: Hmm, I'm not sure...

The tid template lets you tell the user why they're getting a given notification (because they subscribed to a specific term). I guess you could come up with conditional text in the templates that does this for each type, but that'll be a lot of duplication...

Re #11: (our messages crossed...)

Wow, that's a very nice page — thank you for doing this!

1. The last few words should read

but the normal subscriptions_content_node-tid template.

(tid, not nid)

2. Since you say "usually" near the end of the first paragraph, what you describe in the second paragraph is not "an exception to the above rule."

3. I would try to approach this from a different angle, something like this:

Similarly, comment notifications that are sent because the user has subscribed to a specific node will use the subscriptions_content_node-nid template; however, there's an exception for that kind of subscription: update notifications use the corresponding node's type template rather than the nid template. This allows you to send full bodies from the type template for node updates, and for comments only teasers (or not even teasers) from the nid template.

I agree that the content-type specific templates lead to a lot of duplication. But unfortunately there are some things that can only be done with content-type specific templates. In particular the CCK fields can only be shown on content-type specific templates.

My particular use case is that I want users to be able to subscribe to events that match their interests. That means they have to subscribe by taxonomy. But the event emails really are not very useful without the date information. The date information (which is in a date CCK field) I can only supply via the event type template.

But many similar use cases will arise. Subscribing by taxonomy to content types with CCK fields will be quite common.

But maybe I am wrong and it is possible to include CCK field also in the taxonomy template?

Re#13: I like your text. Will you edit the page or do you want me to do it?

Re#13: I like your text. Will you edit the page or do you want me to do it?

Please do, you're doing a great job on that page, and my phrasing is a bit bumpy...

I see your use case. I think you should be able to test for (and use) CCK fields in the taxonomy template, but this would get messy if you have more than one or two content types with CCK fields.

It seems like we need something like

[ ] Always use this template for this content type
Generally, the subscription kind determines what template is being used, for example the subscriptions_taxonomy_node-tid template is used for Taxonomy subscriptions. Enable this option to use this template instead. Note: Page subscriptions are unaffected by this setting.

on the template's page.

Ah, I hadn't realised that I could use CCK variables in the taxonomy template. Stupid me. They are explicitly listed on the lsit of replacement patterns for that template. I guess the ones that do not exist for a particular content type are just undefined. That solves my problem. In fact it means that on my site I can ignore content type templates (and the duplication that goes along with them) altogether, because I do not intent to allow users to subscribe by content type. Thanks a lot for your help. I withdraw my feature request and put this issue back to its old form.

I guess the ones that do not exist for a particular content type are just undefined.

Indeed. Does that make you reconsider the value of being able to test for defined (or not), as we're currently discussing in #344021: Template question?

As for ignoring type templates: don't forget that update notifications for Page subscriptions are sent by type...

"don't forget that update notifications for Page subscriptions are sent by type...". But only if content subscriptions are turned on for that type, right?

Yes, if they're not unlisted. (Try it out before you bet your farm on it...)

Automatically closed -- issue fixed for two weeks with no activity.

Even though I allowed users to subscribe to a category item, there is no setting option on mail_edit settings. I mean I cant see "subscriptions_taxonomy_node-tid" on that page but I can see for example "subscriptions_content_node-nid "...

Do you know why?

The mailkey that you're looking for is subscriptions_taxonomy_node-tid — Notifications for Categories subscriptions.