Restrict access to all admin/config/people/accounts/* and DS manage display

This patch is part of the #1day1patch initiative.

#4 is good for me

#10 is good to know but I think that User Settings Access should restrict anything related to User accounts and not rely on another module to manage Fields access. (The less you have the better you are)

Adding a module to manage all entity types when you only need to restrict users and when another module (yours) already does half the work is a bit overkill. If everyone did that kind of things, this would cause a lot of performances issues and make the website harder to maintain.
Your module's purpose is to help developpers to allow their users to administrate accounts but not user general settings. Even if an other module can complete yours, you have to offer the developpers a full set of functionnalities matching your module's scope.

If you are really afraid of a conflict with fields_ui_permissions, we could just add a if (!module_exists('fields_ui_permissions')) around my patched lines.

Patch rerolled

This one will apply when the #2096901: Apply coding standards issue will be close :)

#18: user_settings_access-restrict_account_fields_and_display-2054645-18.patch queued for re-testing.

@YesCT : job done

Update issue summary

+++ b/user_settings_access.module
@@ -41,7 +41,21 @@ function user_settings_access_help($path, $arg) {
+    if (preg_match('@^admin\/config\/people\/accounts(\/(.*)+)?$@', $route)) {

Can be simplified using only a strpos() call.
Good job, though. Thanks.

I'm not sure that path you want to avoid is a real use case but what I'm sure is that using a regular expression on every route of the website can be a real performances hole.

After a quick thinking I don't know if we really want that this module alters all admin/config/people/accounts/* routes. We do know that we want to restrict access to admin/config/people/accounts/fields and admin/config/people/accounts/display because these are Core routes. But, if we restrict admin/config/people/accounts/* routes we are going to interfere with other modules and people would not understand why they have to use 'administer account settings' permission instead of the one defined in the module that created the route.
If you really want to restrict all these routes, I guess, you should alter the routes that are using the Core's 'adminster users' permission and only these ones. I'm not sure that this is the purpose of this module, though.