The future of custom subscriptions

I'm wondering whether the problem is on the custom subscriptions level or the other administration levels that treat certain semi-arbitrary "subscription types" specially. Custom subscriptions can overlap exactly with the fields of predefined sub types, but they also can include other combinations, and I don't think we want to forgo or marginalize the flexibility of this latter use case.

On the other hand, I think particularly the user subscription admin pages could use some rethinking, because 1) they are provided largely independently by each module, creating overlapping, only semi-standardized code and UI, and 2) notifications itself has all the information it really needs to create an automatic listing, probably with a view filtered by subscription fields. Notifications_views is already in distribution, and if we added some more functionality along these lines to it we might be able to implement this, in which case all you'd have to do is either use the default view or override it to list certain custom subscriptions in the same way as standard nodetype ones if they shared fields. Ideally, by default the actual "subscription type" would become trivialized in favor of field-based filtering on the UI. Does that sound reasonable? I'm not actually very familiar with the autosubscribing portions of notifications_custom, so maybe I'm missing something in that regard.

David

Not sure where this feature goes - but it can be confusing to a user that subscribes to the site to see another area called manage subscriptions.

Question: Is there a way to rename the user interface titles, similar to the way block and menu titles can be changed?

Changing it to notifications/alerts is OK with me but someone else may have a problem with those terms.

By the way this is the same issues with the simplenes module that also calls uses "subscriptions" and "newsletters" in the titles used in the my account center.

Any help appreciated.
iwebconsultant@yahoo.com

Yes, I have to agree this is a bit of a mixed feature, and still experimental, actually that's the reason why this is not in the main Notifications package yet.

About bundling several subscriptions, it sounds like a good idea, though it is a different feature. The idea I have in mind for the whole subscriptions stack is something like this:

- Modules define subscription types (notifications_content, notifications_custom, etc...). Though there may be some overlap here, we don't really want to push the complexity of the custom subscriptions for everybody to use, so the modules providing simpler subscription types (content type, tag). Maybe the breakthrough feature here would be being able to export such custom subscriptions and paste them in your module, using some views like approach.
- Bundling several subscription types into one would be a nice feature too, creating something like 'meta subscriptions', though I'm afraid this would push the complexity of the module maybe a bit too far. It needs some good UI too, so maybe this is better as a separate module for now.
- Then, making subscriptions available for user registering, optional or not, or mass applying that subscriptions to a group or users, which are currently implemented in notifications_custom doesn't actually belong here it should be a different layer, so we can apply these settings to subscriptions defined by other modules too.
- About the UI, agreed it should be handled by the framework itself. However this needs some more data (per subscription type) to define whether it should be available, visible and editable and for which roles.

So I think the way to move forward here is to merge custom subscriptions and all other subscriptions in a table which defines all the other things (user register, visible, editable). This would be a 'views like' approach on which some modules define predefined subscriptions that are stored on the table, and the 'notifications_custom' module is kind of a 'views_ui', which lets you edit/create all the other subscriptions.

Btw, the data model (notifications, fields) is documented here, http://drupal.org/node/312427

Yeah, it seems we were talking different things here. Just to make it clearer:

Subscription type === n (AND) subscription conditions (node type = x, tag = y, author = z.....)

Custom Subscriptions is used to build new of such Subscription Types (you select the conditions)

Bundling subscription types, the way I think of it, would be combining two or more Subscription types in a new one (OR), with only practical UI consequences (admin/user subscribes/unsubscribes to both things with a single click)

An example:
- Type1 is 'news' content posted by admin (2 AND conditions)
- Type2 is any content tagged with 'urgent' (1 condition)
- Type3 could bundle both (Type1 + Type2) and be named like "Subscribe to important posts" (1 option in the UI that would create 2 subscriptions in the backend though).

However, you could also think of bundling subscription types as creating a new one that just adds up all the conditions of each, that would be AND. And that makes sense too, though it could be implemented just as an admin UI artifact.... (select the conditions of this and this other type and add them together).

Another interesting feature would be to create subscription types with 'OR' conditions, and I think simpler ones could be easily implemented in notifications_custom. If you look at the data model, the notifications (one row per subscription) has a 'conditions' field (= number of subscriptions that must match for notifications to be triggered) so it wouldn't be too difficult creating a subscription with two conditions, that just need meeting one of them.

About the 'being visible in user registration', etc... yes, as I wrote above, this doesn't actually belong into custom subscriptions, should be moved to the framework somehow.

At this point I think the most interesting feature to implement would be making subscriptions 'views like' so modules can define default subscriptions, you can enable/disable/clone/edit them to create your own... That would mean moving the notifications custom table into the framework, then keeping this module just as an UI (views_ui?)

All the suggestions are great. But, I think a version of this module, perhaps under a different name, would be more useful than this whole bundling BOOLEAN AND approach. Just a simple administrator-forced subscribe to a set of users or all new users that set the appropriate settings in Notifications once, visible in the tag and group lists in the notifications UI, and then let the user take over and manage them. I think this is most appropriate as it doesn't create a new notifications type/tab, and the while check/uncheck of the "bundled" settings is really just a side thing for highly specialized environments.

IMO. I may just even code such a thing hacking this module, because I need to simplify it and make it less confusing for people than to have a series of disjointed subscriptions to the same content.

--glen