I have a use case that requires a group of users to be able to by pass the disabled log in but they can't be added them to a role with the permission.

I have to write this code for my project so I will add the patch once I am finished.

CommentFileSizeAuthor
#6 login_disable_add_user_option_2304459.patch6.38 KBwonder95
#1 login_disable-user_bypass-2304459-1.patch2.08 KBgeekygnr

Comments

geekygnr’s picture

geekygnr commented
Status: Active » Needs review
StatusFileSize
new login_disable-user_bypass-2304459-1.patch2.08 KB

I have set this information up in the $user->data array. The D7 description of that field suggests not using it because it will be removed in future versions but it looks like there is an https://www.drupal.org/node/1852360 for this information moving to D8. In my mind that makes this the best place to store this information.

For those with proper permissions there will now be a check box on the user edit form for admins to allow users to by pass a disabled login.

budda’s picture

budda
Primary language English
Location Cheshire
commented

Can this not be done with a Drupal User Role and assigning the role to the specific users and assigning the bypass role permission?

geekygnr’s picture

geekygnr commented

It could, I have an odd use case where I am working with an install profile that is managed by another team and they manage the roles and to a certain extent role membership. So creating a new role for a subset of users to have certain permissions isn't an option for me.

It is a customization I need because of the way I have to go about managing certain things but perhaps it isn't something for the official release. I didn't want to not offer the code in case it was useful to others.

wonder95’s picture

wonder95 commented

I'm in a similar position as @geekygnr, in that I have a use case where because of a bug in Drupal that keeps user names from being viewed for anon users on content when the account is blocked, I need to be able to specify on a per-user basis whether the account can be used to log in and still stay active. I started to write my own code, but then I came across this module. I've been playing with it most of the day, and after applying this patch, I really think it exposes two things:

  1. The flaw in the current architecture of the module, and
  2. The way it needs to go.

because this patch can't really work in conjunction with the current architecture. As a case in point, say you have a user account with the bypass option form added by this patch checked, so it should be able to login (this is all with the "Prevent user log in" option enabled in the admin). Even though that option is checked in the user profile, the user can't even get to the user profile screen to log in in the first place without the secret code in the URL. since you're still anonymous at that point, so there's no user profile to check against to get past that.

Even without this patch, it's still sort of cloogy, because if you only want to disable login for some, you have to disable it for all users, and then you have to either grant the bypass permission to a role or have the user add the secret code to the URL. To address @budda's suggestion in #2 above, in my case the role route isn't really feasible, because I would be creating a whole new role for only one permission, which seems like overkill. Plus, I'm installing this at the start of building a new site where I will be migrating everything from a current D6 site, so if this is indeed a user profile setting, I will be able to set it during the migration.

So, with all that being said, here are the options I see to make this more useful:

  1. Convert the module to use the user profile setting instead of the URL parameter.
  2. Make it so that either option can be used. In other words, the admin settings would have the option to use either the URL argument or the user profile setting.

I will be working on this tomorrow, so I can do either one. If I don't hear any feedback by then, I will probably go with the second option and submit a patch, although I might just do the first and keep it as a custom module for my projects.

Thoughts?

geekygnr’s picture

geekygnr commented

@wonder95 I think I am tracking what your saying. What I am hearing is you want to be able to use my patch while not needing to use that special code the url to get to the log in page. Well I know this is possible because it is what I am doing.

If you leave the access key blank it should do this.

There are a number of issues I have created for this module and about half of them have patches. So if it isn't working maybe there is something in one of the other patches I submitted that made that change.

I hope this helps it has been a while since I thought about this module so I hope I haven't forgotten something.

wonder95’s picture

wonder95 commented
StatusFileSize
new login_disable_add_user_option_2304459.patch6.38 KB

Attached is a patch that adds an option to disable login on a per-user basis instead of the original message. The settings screen has two options now, which are mutually exclusive (some jQuery makes the checkboxes act like radio buttons). I tried to display a message when the user is logged out, but it's not possible currently due to the session variables being deleted when the user is logged out.

This also includes the patch from #2375073: Logn disabled message displayed when login allowed.

geekygnr’s picture

geekygnr commented
Assigned: geekygnr » Unassigned

I am going to remove myself as the assigned member for this ticket. I am no longer working on the project that I was using this module for and my focus is elsewhere.