Our config is not set up like that so this line would not be used. Is the idea of this that people granted the 'inactive' group would not be able to read pages, but would still be able to log in?
The wiki is challenging to remove past members of the committee since they use this "inactive user" group to put the former members into; however, it seems that the permissions for that group don't actually prevent them from reading the wiki, just from editing it. We need to make it so that past members cannot edit or read the wiki. Not sure why they need to log in - perhaps access cannot be fully blocked?
It looks like wgBlockDisablesLogin is set to true by default on all private wikis, so blocking should protect user from editing too. Maybe you should consider indef blocking instead of inactive user group. Another solution will be to install DisableAccount. I recommend you the first solution because the second one is not reversible without filling request here but the first one can be reverted by each sysop.
hphpd> =$wgBlockDisablesLogin =$wgBlockDisablesLogin true hphpd> =$wgGroupPermissions['inactive'] =$wgGroupPermissions['inactive'] Array ( )
The inactive group does not control ability to do anything itself (the group has no rights granted), it is just a marker used by DisableAccount to show that they have been disabled. What DisableAccount really does behind the scenes is change the user's password and email address to null (meaning they can't log in or change their password - which is why our intervention would be required to reopen such an account).
Another reason this request doesn't make sense is that the inactive group is not granted the read right itself (or any other rights), that is provided by the special user group.
You should be using blocking (BlockDisablesLogin is enabled) instead of the DisableAccount extension.
I'm going to leave this as stalled instead of invalid for now.