User with "administer user subscriptions" permission cannot access subscription settings page

administer user subscriptions is intended to give access to the user/UID/subscriptions pages.

Attached are patches to subscriptions.module, subscriptions_content.module and subscriptions.admin.inc (I don't know how to create a multifile patch, yet).

Essentially, I've created an "administer subscriptions" permission which will allow the user with this permission to perform all subscriptions.module functions that previously required the "administer site configuration" permission. My logic behind this is that by giving someone the "administer site configuration" permission, you give him the ability to do much more than is needed if you only want the user to be able to administer the subscriptions module.

Hope you agree.

Thank you for the patch. Some quick comments:

Does the user also need access administrative pages?

Should admin/settings/subscriptions/userdefaults be accessible via either permission?

administer subscriptions does not include administer user subscriptions, does it? It shouldn't.

There should be some brief documentation in README.txt of what the admin permissions allow (see the questions above).

(From http://drupal.org/patch/create: "When you've modified multiple files in the source tree, use diff's ability to compare directories." Use the dot directory as the one where the new versions are, i.e. run the diff command from there.)

Does the user also need access administrative pages?

No, not for access to subscription settings. Yes, for access to linked functions such as:

Permissions
Mail templates
Run cron manually

But, that make sense.

Should admin/settings/subscriptions/userdefaults be accessible via either permission?

My thinking on the subject was that I wanted to identify a user as being able to set and modify the userdefaults for the site without giving that user full site administrative access. Since most Drupal core module admin pages have their own admin permissions outside of "access administrative pages", I would think that this would serve as the model.

So, my answer to the question is that a user should have the "administer subscriptions" permission to administer subscriptions settings, period.

administer subscriptions does not include administer user subscriptions, does it? It shouldn't.

No.

There should be some brief documentation in README.txt of what the admin permissions allow (see the questions above).

OK. Will do.

Should admin/settings/subscriptions/userdefaults be accessible via either permission?

My thinking on the subject was that I wanted to identify a user as being able to set and modify the userdefaults for the site without giving that user full site administrative access. Since most Drupal core module admin pages have their own admin permissions outside of "access administrative pages", I would think that this would serve as the model.

So, my answer to the question is that a user should have the "administer subscriptions" permission to administer subscriptions settings, period.

Your strategy has the beauty of simplicity.

However, editing user subscriptions requires more trust that editing user default subscriptions, because it involves privacy in addition to security. If we allow someone to mess with other user's subscriptions (so they could go in and make systematic changes to every new user), they should be competent and trustworthy enough that we allow them to adjust the defaults for new users and make their lives easier by saving tedious and repetitive work.

Can you think of a situation where you'd allow changing user subscriptions but purposely withhold changing default user subscriptions?

Can you think of a situation where you'd allow changing user subscriptions but purposely withhold changing default user subscriptions?

I think it's a matter of choice. In my situation, I want the user to have one permission to access all subscription settings, including setting the user defaults. I envision the user who has this permission being a highly trusted user.

If the patch I submitted is incorporated, then existing sites will have to change their current subscription admin roles to change one permission for the other. This will be a rather simple matter since currently there is only one permission for access to the subscription settings.

If we add yet another permission for access to the user defaults, then existing users will have to spend some time re-thinking their current roles(s) before making changes.

If you want to fine tune permissions, then, yes, add one specifically for userdefaults. But, since I've not found any issues on this subject, I'd say just stay with the one admin permission instead of two.

I think it's a matter of choice. In my situation, I want the user to have one permission to access all subscription settings, including setting the user defaults. I envision the user who has this permission being a highly trusted user.

Yes, I agree completely and I never intended to change that. But just as you say you don't want to have to give the administer subscriptions permission to someone who only administers user subscriptions, I think administering default user subscriptions should be possible without administer subscriptions, because that's pretty much on the same level as user subscriptions.

So, rather than introducing a third separate permission for user default subscriptions, I'm considering an overlap, where user default subscriptions would be available through both, administer subscriptions and administer user subscriptions.

@SomebodySysop:

So, what's your opinion on having overlapping permissions for user default subscriptions?

You missed a hook_menu() implementation in subscriptions_mail.module.

We need a hook_update_NNN() function to give administer subscriptions to those roles that have administer site configuration, so that updating doesn't break existing sites.

Will you provide an updated/rerolled/single-file patch based on HEAD?

So, what's your opinion on having overlapping permissions for user default subscriptions?

If you mean this:

So, rather than introducing a third separate permission for user default subscriptions, I'm considering an overlap, where user default subscriptions would be available through both, administer subscriptions and administer user subscriptions.

that sounds fine to me.

You missed a hook_menu() implementation in subscriptions_mail.module.

Not sure what this is.

We need a hook_update_NNN() function to give administer subscriptions to those roles that have administer site configuration, so that updating doesn't break existing sites.

Will take a minute to figure out how to do it, but I understand what needs to be done.

Will you provide an updated/rerolled/single-file patch based on HEAD?

Download the latest 6.x-1.x-dev, right?

Glad we found an agreement.

admin/settings/subscriptions/purge-queue in subscriptions_mail_menu() currently also requires administer site configuration. It should require administer subscriptions, but it was missing from your patch in #2.

Yes, as long as work on the D7 hasn't started yet, HEAD corresponds to 6.x-1.x-dev.

@SomebodySysop: I hope you haven't given up — we're very close...