Add an 'Administer login destination' permission

We should make use of existing features and not multiply them. A whole bunch of Drupal code behaves like this. You can always hack it if you need this specific behavior.

Let me clarify. I base the judgment on my personal opinion and experience. I am pretty much tired of forgetting to add such admin permissions to the "admin" role every time I add new module. I do not see a reason why administering LD differs from administering the site, or users, it requires the same amount of trust. So if I can remove one line of code this way, I do it. And if I can make the configuration easier and more straightforward, I do it. I prefer using existing elements, behaviors, perhaps saying "feature" was a wrong choice of words. I think drupal already suffers from too much permissions, and too much modules, but this is still only my view.

LD even uses the PHP permission from the PHP module. So if you do not enable the PHP module you cannot write PHP in LD. It is a way of creating a secure and consistent system, I think.

Nevertheless, if you provide a reference to a guideline that says otherwise, I am willing to change my mind. Maybe I am missing a point.

Great module... nice, simple and gets the job done (with one caveat).

I just came across this discussion while searching for a way to disable access to "Login destinations" for a client with limited site management options. When I deliver a site with specific core functionality (such as destination upon login), I don't wish to rely upon verbal communication... "don't play with option x or you will break your site," as it would be a bit unprofessional on my part.

Yes, the client can manage users and grant roles... they should not, however, change the expected workflow of the site. There is little choice but for me to customize the module to add such a permission, making future upgrades less easy and less straightforward. I'd rather set an extra permission than turn over a forked/custom module to a client.

Just another opinion... no guideline to cite, other than enhanced usefulness, professionalism and maintainability upon delivery. YMMV.

Thanks for sharing a useful module... now I'm off to hack it a bit to accommodate a "site manager" role (with limited admin).

Permission set/overridden with Custom Permissions module. All is good.

EDIT: See also Path Access or System Permissions modules as alternative options.

+1 for 'Administer login destination' permission
I totally agree with #2 and #4 and I can't believe there actually is a debate on that. Managing users and login redirect is 100% different.

Well I guess this is pretty much textbook that there should be a permission like this

Absolutely agree with opinion that module should have own permissions. Guys here is the patch.

I manually tested and it works well for me.

#10 Works well for me.

just reviewed this one and got me thinking - what will happen when somebody UPDATES the module from
permissions = admin users
TO the new version where u need:
permissions = admin LD but will only have permissions = admin users set... ?

Option 1: LD does nothing on update and silently leaves the admin user wondering "Why cant I now admin this module any more ?"

Option 2: LD puts a warning after update that wont go away unless you manually go to admin permissions and set at least 1 role to permission = "admin LD". ( if the adminrole module does that automatically for the admin role - this will not show which is ok )
possibly check if current user is uid = 1 which has access to all...

Option 3: LD sets at least one role's permission to "admin LD"

Any thoughts @DmitryDrozdik? Should we write some update hook to notify user of the change ? I think this is the best option - number 2 above.

Hey guys,

@rsvelko, After updating the module will be used option 1. If earlier user role with access to "administer users" had this possibility after update it will not. I did not add update function, because it will enable access to configuration page for roles which maybe should not have it. Also in update function we can not understand what role should have access and what role should not. But in any case user with role "administrator" or uid == 1 will have access to manage configuration of the module, and will be able grant permissions for any needed roles.

@DmitryDrozdik, @rooby and @all:
the potential breakage is just that "some former admins wont be able to access the settings page" - no surprises should happen with the redirection itself... just to clarify.

And about whether to update actively perms or leave upto the admins to give perms...

I think I vote in favour of rooby ( that is LD should update perms proactively on update ), because 'administer users' is a permission that is very high in the permissions hierarchy, I mean yoou give it to very well trusted users in the site, so giving them 'administer login destination' wont be a problem and IS EXPECTED by the site admins and sub-admins.

so to follow the least-pain path for users on update, I would proactively update permissions of roles that have 'administer users' to have the new one too... maybe some site admins will need to revoke the permission for some of their clients but that will be the minority imho.

@rooby: what other module precedents have u seen - give us their names.

I have added an update function with message and enable new permission for all roles which have access administer users.