Patch to improve permissions - ready for release

Hi Andrew, thanks for your feedback.

First regarding your previous post... I agree that "use" may make more sense than "access". I can reroll a patch for that.

For your second post...

1) Non-administrator or site builder roles should not be given permission to administer this module... Drupal does always "allow" any role to have "any" permission though... it's just how it works. Just as you could allow "administer search" or some other permission to authenticated users, you could do the same in this case - but you should not of course. And generally if you "are" giving administration related permissions to a role, you always have "access administration pages" permission as well. That confusing permission simply allows the first ground level of access to the admin paths, while not actually granting any specific permission to "do" anything.

The settings of Add Another module (administer add another) are not something any user besides UID 1 or a top level site builder/administrator role ever needs access to. The settings of the module affect all other users on the site and should only be exposed to privileged users. The only aspect of the module that should be exposed to regular end users is its actual function, which is to add an "Add another [node type]" link into the message area that appears after you submit a new node (so long as it is of a type determined by the site administrator). No other menus or pages of the module should be known or accessible to other users, just as (for example) admin/settings/search or other configuration pages should not be. For instance, with "access administration pages" permission disabled and core's "administer search" permission enabled, the path "admin/settings/search" is now accessible to the user, however no menu items, nor parent pages (e.g. /admin) are available.

2) You're right that the "more help..." link gives access denied in this case. This however is an issue with modules overall if "access administration pages" permission is not given. For example with the above configured example of "administer search" the same is true, where admin/help/search is access denied. This is not something we can fix (to my knowledge) in the module. As mentioned, when a role is being given administrative permissions, also giving the "access administration pages" permission is standard practice, which solves this issue. Personally I don't see or understand the value of the "access administration pages" permission at all, but that's how it currently works.

So to wrap up:
- I'll re-roll the patch to change the permission to "use" instead of "access".
- We can add additional documentation to inform users that "access administration pages" permission is a general prerequisite if the user is going to "administer add another", however there's nothing beyond that we can or should do in this module regarding that issue. The rest is up to core (e.g. submit issues against D7 regarding how to handle administration permissions, access to the help pages, etc).

Again thanks for the feedback, and let me know your thoughts on the above.

Made the mentioned changes and re-rolled patch. Re-roll also includes a few minor code style adjustments that Coder module caught.
Have tested applying the patch and running the update, and it appears to be perfect... if anyone can take a moment to apply the patch and confirm that would be excellent :)

Hi Robin... any chance of a new release soon?
Thanks :)

Hello Robin, just checking in as it's been a while. Would you mind please rolling out an official release? I like using this module for a variety of my sites and client sites and would prefer to not keep juggling the custom patched copy. If by chance you've decided not to maintain this module any further, please let me know and I would be happy to co-maintain.

Thanks!