Posted by igorik on July 3, 2009 at 7:40pm
Jump to:
| Project: | Notifications |
| Version: | 6.x-4.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Hi
I would like if you could change one of permission name, I think that now it is really confusing.
I speak about these two permissions:
maintain own subscriptions
manage own subscriptions
They have very similar names, I can't remember which permission what to do. (Then I found that maintain permission is doing page with settings on site user/xxx/notifications)
Actually, till now I never find/understand what exactly do permission "manage own subscriptions"
So, would be great if you could change the name of one of these permission to something more different and somewhere to write what the permission "manage own subscriptions" exactly doing.
Thanks for your work on this great module
Igor
http://www.somvprahe.sk
Comments
#1
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.
#2
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.
#3
Agreed. This is very confusing and needs to be changed.
#4
+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
#5
I think Shark explained it pretty well in #2 above.
#6
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.
#7
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).
#8
Subscribing. I'll need to remember to update the permissions in my Features modules to reflect these changes when/if they occur.
#9
subscribe
#10
subscribing
#11
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 …)
#12
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.