Rename permissions

I also was confused by the permission titles.

I found the following description in notification.module to be helpful:

  * - maintain own subscriptions = Create / delete own subscriptions
  * - manage own subscriptions = Access the subscriptions management tab

Based on this, I took that to mean maintain is the more basic permission that all users will need, and then manage is necessary if users should be allowed to view the "Notifications" tab in their user account page.

However, this does not appear to be the case. Between examining the behavior of the site with different combinations of maintain and manage, and looking at notifications.module, it appears that the only permission necessary is maintain (it will allow users to see the users/[uid]/notifications tab as well as seeing the subscribe links on nodes), and that there is no additional functionality that manage grants.

Thanks for the great module and any clarification on this issue.

After playing with this more, I realized what the manage permission does.

With this permission enabled, a new link ("Administer your subscriptions") will take you from the overview tab to the subscriptions tab on the users account page.

If manage own subscription is enabled, a new tab called 'subscriptions' will be displayed on the user's account page. This tab will allow the users to administer their subscriptions: they will be able to select any or all of their existing subscriptions and perform update operations on those subscriptions. The update operations include the ability to change the send method (mail, sms, etc), change the send frequency (every hour, every week, etc), or to activiate, deactivate, or delete subscriptions.

+1

Only way I managed to figure this out was by digging in the code :/

Am I right in thinking it's:

maintain -- set up general rules
manage -- fine-control each individual subscription to each individual node

Not really.

> they will be able to select any or all of their existing subscriptions and perform update operations on those subscriptions

This is ambiguous. There are two kinds of things feasibly called 'subscriptions':
- A: a rule like 'subscribe me to all nodes of type X'
- B: email me when node 1234 updates.

Ok, this makes sense, may get fixed on the 4.x branch.

The contest for a (clean) list of suggested permission names and what each of them allows is open.

(In a few weeks we'll have a stable version and from that point they won't change again, unless someone wants to provide the full update scripts).

Subscribing. I'll need to remember to update the permissions in my Features modules to reflect these changes when/if they occur.

subscribe

hm, the two permissions confuse me.

1.) I don't see the need for two permissions with the purpose that a user can view and edit own subscriptions.

2.) The two permissions are not totaly distinguished:
For the User account tabs (in the code from line 148 to 199 in notifications.module) some lokal tasks use
'access callback' => 'notifications_access_user'; function notifications_access_user distinguishes between $op == maintain and $op == manage (according to the permission and operation).

For the pathes
notifications/subscribe/%user
user/%user/notifications (since maintain is the default as second argument for the function notifications_access_user) and
user/%user/notifications/update/%
a user needs the permission maintain own subscriptions (checked in line 264 and 334 notifications.module).
('maintain own subscriptions' is also used in notifications_anonymous/notifications_anonymous.module, but why should someone activate the module "Anonymous subscriptions", if anonymous users should not have the possibility to subscribe and unsubscribe, so i don't activate this module)

Only for the path
user/%user/notifications/subscriptions
a user needs the right to manage own subscriptions.

But i can't see a (usual) usecase where a administrator would give the user only one of the rights 'manage own subscriptions' or 'maintain own subscriptions'.

(Maybe i missed something …)

If there are going to be two permissions, perhaps they should be:

1) Manage own notification settings

2) Manage own notification subscriptions

The first can let people decide things like whether they want to receive notifications at all, while the second lets them chose which ones.

Is this still necessary, in the Drupal 7 version? Drupal 6 isn't supported anymore, so that module version won't be changed.

In the Drupal 7 version, the permissions are the following and they have a description.

• administer notifications: Administer all notifications options
• create subscriptions: Create own subscriptions
• maintain own subscriptions: Create, delete or edit own subscriptions
• manage all subscriptions: Administer other subscriptions for other users
• skip notifications: Make changes with an option to skip notifications when available