Meta-issue for Beta 2 release

There are so many issues to fix that it's simply not practical to have a separate patch for each one. Here is a summary of the changes in this patch and why. Yes, I am aware I haven't uploaded the patch yet - I want to upload the description first so that people don't start using it without knowing what they are getting.

1) Permissions (administerusersbyrole_permission)

• Drop the "and other roles" permissions as per #2379013: "XX and other roles" permission can give admin access by accident.
• Internal permissions names use role ID not role name (user visible permission titles are unaltered). This fixes several problems. Title can be translated; title can change; title can contain special characters, which are stripped, but then two different roles could collide.
• For simplicity and efficiency, no need to have special case for "no custom roles" - we can just use role ID DRUPAL_AUTHENTICATED_RID. (Except we do special case the title to help users.)
• Now we are no longer relying on 'administer users' permission, we need a base permission that enables the function of this module (e.g. to govern access to admin/people). The neatest solution seems to be to use the "no custom roles" permissions. Hence there is a small change to the meaning of these permissions: to edit a user requires "edit users with no custom roles" plus the specific permission per role of the user.
• Pointless to have a permission for anonymous user.

2) Menus (hook_menu_alter).

• Add permission hook to view user to ensure that blocked users are visible when we have permission to edit them.
• Add permission hook to allow creation of users based on permissions.
• Add permission hook for admin/people for users that have some edit or cancel permissions.

3) Calculation of access (_administerusersbyrole_can_*)

• Always start by calling the existing functions in the user module (such as user_edit_access),rather than attempting to duplicate the logic, and leading to bugs where it's not identical.
• Never allow UID 0 or 1.
• The code in the user module to create and cancel users relies on 'administer users' permission, so we simulate this similar to the Subuser module (thanks to BWPanda in #1717876: Remove dependency on 'Administer users' permission).
• On the admin/people page, only show users that are editable - this is important to ensure that bulk operations are subject to the permissions checking.
• Fix bug causing error messages on cancel confirm (administerusersbyrole_form_user_multiple_cancel_confirm_alter).
• Fix bugs in visibility on user edit form (administerusersbyrole_form_user_profile_form_alter); make sure we don't duplicate the logic of the base form function, just add visibility where needed.

4) Views - just minor tidy up

• hook_views_handlers is no longer needed in Views 3.
• _administerusersbyrole_can_cancel_user now calls user_cancel_access so it's a waste of time to call it again.
• Fix the text on the button to match the code now in Views.

OK, here is my first version of the patch. Comments, success/bug reports and questions welcome. Those of you that have indicate on other issues that you would like to have a working version of the module - I need your help now to test, review, criticise and so on.

This is my first try at being a module maintainer so please forgive my mistakes in following the correct process.

Using the patch

Updated instructions to use this module:

• Create a role for the users who you'd like to be able to create/edit/delete other users
• Give that new role the desired Administer Users by Role permissions plus "access user profiles"
• The user-doing-the-editing must have permission "Edit users with no custom roles" plus permission to edit ALL of the user-being-edited's roles.

Key points:

• You must disable 'administer users' permission except on real all-powerful admins.
• After you install the patch, all your administerusersbyrole edit and cancel permissions will disappear and you will have to set them again. Hopefully there will be some migration code at a later stage.
• "Edit users with no custom roles" is now required to enable editing - without it you can't edit at all. This slight change was necessary to ensure there is a single permission to check when determining whether to allow access to admin/people. Hopefully most sites will have this enabled anyway, which means it's a lot less work for people than if I create a new permission. (And at least to me, it's more logical this way.)
• The "and other roles" permissions have now gone as they caused a security problem (see #2379013: "XX and other roles" permission can give admin access by accident).

Given that the changes to make it secure have led to some changes in the permissions, and there isn't a clean upgrade, I have decided it's best to make a version 2 of the module. Please check out the dev release that should be available shortly.

Fixes now available in latest release

@ciss This is a meta-issue so not the best place for specific issue debating. I suggest the best place for you to look is the more recent issue #2414853: Errors after export and re-import via features . Please read that and add a comment there if you wish.

Bear in mind a) this problem goes away with D8 and b) we have a stable release now (yes you are awfully late!) and renaming the permissions would be a complexity with potential bugs for all users. It might be most realistic for you to create a patch which you apply locally and share it here for anyone else who also wants it. I doubt there will be a lot of new releases to D7. Also it might be easier if your comments could stick to the facts without sharing your personal thoughts on what is "huge" and "easily" done.

No problem, no offense taken - I should have put a smiley. It's definitely valuable to have the patch available for anyone who wants it. Please link your new issue from the existing one.