Closed (fixed)
Project:
Maintenance Helper
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
17 Sep 2010 at 03:01 UTC
Updated:
3 Jan 2014 at 02:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
claar commentedI realize I'm arguing with myself here, but the problem I have with a
command unsetting every role's 'login to site' permission is that it overwrites the permissions previously set on the permissions page, creating an all-or-nothing state.
It strikes me that better would be to:
Then we would create a new checkbox on the settings form that would be used to place a site into a "restricted access mode", and the drush command becomes a simple setting of that variable.
One really nice side-effect of this "restricted access mode" method is that upon enabling this module, normal logins would *not* be affected as they are now, which I believe was the cause of the confusion in issue #366095: Provide README for Maintenance Helper.
I have created a new issue for this #915062: Add a restricted-access mode, since that is a separate feature from drush support.
Comment #2
claar commentedComment #3
gregglesI think that if we have a few drush commands (I'm not sure if these exist or not):
Between those three commands it should be possible to do everything you need, right?
I'm hesitant to add more complexity with the restricted mode idea.
Comment #4
claar commentedPossible, yes, but not really usable.
I run 15 sites, soon to be 30+, each with many uniquely-named roles. Tonight, for example, we're going to be placing them *all* in "admin-only mode" during a server move. To do so, we type:
To do the equivalent with permission-based command would be incredibly painful.
It's not even in the same ball-park. So one thinks, "Perhaps a command could be written to revoke permissions from everyone at once!", getting us closer:
Oops, now we've just lost the permissions granularity wiping the "login to site" permission out every time we want to restrict logins via drush.
This is the line of reasoning that pushes me toward the "restricted-access" mode, which I actually believe simplifies the module from a usage and understanding stand-point, and is not complicated code-wise either.
Comment #5
gregglesIt simplifies the drush command, but not the general UI.
Maybe let's discuss more in irc so I can understand your needs and see if we can find a solution.
Comment #6
gregglesOk, having re-read this I'm fine with the proposal in comment #2.
Comment #7
gregglesRight, I meant, comment #1! (the second post on this issue, but indeed the first comment).
Comment #8
claar commentedAttached is a patch against 6.x-2.x -- feedback appreciated! #914238: Configure maintenance and lockout message and visibility will require additional changes, which will be handled in that issue.
Usage: drush help mh-restricted-logins
Comment #9
gregglesshould be
Ditto for the else ifs.
$clearcache doesn't seem to be used.
variable_set itself does a cache_clear, but just of the variables table. It seems like it would be good to add a code comment clarifying that the main intended cache to clear is the page cache.
Comment #10
claar commentedThanks for the excellent code review -- new patch attached.
Comment #11
claar commentedForgot to set needs review.
Comment #12
gregglesYou are welcome :) A few more small things...
I tend to do:
I think it's easier for translations if you don't have to escape the '.
Do you really need to check for both equal values and the same type of data? That seems pretty unlikely. There are a few cases of this.
Comment #13
claar commentedAddressed #12 -- thanks, greggles!
After discussion on IRC, decided to stick with === for the comparisons.
I also was calling drush_show_help with an Array argument incorrectly, causing help not to be shown. Fixed in attached patch.
Comment #14
claar commentedCommitted #13 to 6.x-2.x