Subscription gui displays unauthorized subscriptions

Your observation is correct, and that's how it's intended to work. 'subscribe to content' is a bit of a misnomer -- it used to control whether you get subscribe links with each node, and now it controls, whether you get the "Subscribe to this post" option or not.

I always thought, it should be renamed to 'subscribe to comments', since that's what it used to provide. With Subscriptions 2.0 you can get comments (and even updates!) from all subscription types, and I'm not sure whether it's useful anymore. I guess you could only give 'subscribe to comments'...

Comments?

I reconsidered what I wrote above and changed how it works. Now, if a user doesn't have 'subscribe to content', there's no more "Subscribe" fieldset on the node forms.

I think this is going to confuse users no end. Permissions are traditionally not used to switch certain interface elements on or off but are used to enable or disable certain functionality. If subscriptions has a permission called "subscribe to content" which does not control whether a user can subscribe to content or not but only controls which route they have to take to subscribe to content then that is very confusing.

I propose to rename the "Subscribe to content" permission to "Subscribe to content items" and use it with the same meaning as the corresponding permissions "Subscribe to blogs", "Subscribe to taxonomy terms", and so on.

I have attached a patch that does this.

The attached patch does not automatically assign the "Subscribe to content items" permission to all roles that had the old "Subscribe to content" permission. I think that is not necessary because we are still in beta and people could do that permission setting by hand on their test servers.

But what is the point of removing that one option, when there's a full set of much more powerful subscription options available right there?

Removing the node UI does have the side-effect of making it impossible to subscribe to threads — on the Threads page you can only unsubscribe.

I am not sure what the point would be of removing the option to subscribe to individual items. Perhaps it would be to make things simpler for the user. For example some users might be used to the way organic group subscriptions work at the moment (where you can only subscribe to all posts in a group, not to individual posts) and the site admin might want to keep the experience for these users the same even though the site has switched to using subscriptions.

It is impossible to know what use people will put the permissions to. But I think it is important to have a consistent set of permissions that people can understand. So having one permission per subscription type is very sensible.

This is related to #232276: post or thread? --> page?. I remain unconvinced.

Given that the option is called "Subscribe to this page", a permission that would control that option, would need to be called "subscribe to pages". I'm sure that's not what you want.

"subscribe to content" controls whether nodes (= content) have a "Subscribe" link, can show the node subscription form and whether /user/UID/subscriptions/node (aka the "Pages" Subscriptions page) exists. IMO, these three pieces always go together, and it's a permission that controls whether they're available or not.

I don't want a separate permission for the "Subscribe to this page" option. You get there by clicking the "Subscribe" link on the node, and I'm not going to tell the user 'What? You thought you'd be able to subscribe to this page by clicking on the "Subscribe" link? Well, forget it!'

Offering the other subscription options, preconfigured for this node, is just a convenience feature.