This module seems to be the perfect place for a restriction to deal with contributed modules, allowing site owners peace of mind to invite others to help them with Drupal sites: for typically when assigning administrative tasks to hired labor.

Scenario:
The owner initially prepares the site in question with selected contrib modules by uploading them to the modules folder, and the hired admins should have no access to do or alter this. They should only be able to enable modules already present in the drupal installation (and disable, re-enable them at will), and configure the related settings they provide.

The hired admin(s) will have the "administer site" permission, and through using "role_delegation" or "role_assign" modules (and other such features), they will have the permissions to adjust some settings for selected user roles, but never to escalate their own, and no possibility to sneak in any module or script that may provide the ability to run custom PHP code.

Through core features, configuration schemes and other contrib. modules we can currently arrange the following:
1. Allow them to enable and disable modules, and configure the related new permissions that each newly enabled module provides.
2. Prevent changes to the file system.
3. Prevent changes to certain permissions such as "administer permissions", "administer users", "administer input formats", yet allow administering the rest. (This can be achieved by using two admin roles, where the default Administrator role inherits all new permissions for newly enabled modules by default, as it currently does, and moving selected permissions onto a secondary "Admins2" role.)

BUT: there are two major implications, or missing pieces:
- The security breaks if the admins need access to enable/disable modules on the modules page
- It would also break if such admins has access to use the updates manager (because of the "upload feature" that comes with it).

Therefore, we need Update Status Advanced to come to our rescue :-)

To make the above feasible, I suggest adding the following features to this module:

  • a) Prevent enabling selected modules (such as core's php module).
    This means a tick mark for each module, enabled for all by default, so that new enabled modules can take part in updates, but remove tick mark for modules that should not be possible to enable. This should override the main modules page, could be that this should be a separate settings tab that just lists all currently available (enabled AND disabled!) modules (including all core modules), with one tick mark each, enabled for all by default).
  • b) Prevent uploading new modules.
    Enforce that the updates can be done ONLY from drupal.org, only through the automatic suggestions by the update manager. Roles that does not have the permission to ADMINISTER _this_ module (Update Status Advanced settings), should not see the "Install new module or theme" link (or the field/button if not using javascript) on the Available Updates page.
  • c) To make A and B possible, it would require a new, separate permission to Administer Update Status Advanced SETTINGS. (_this_ module's configuration options)

Users with the permission to ADMINISTER Update Status Advanced, should be allowed to circumvent those limitations without needing to change settings. Hence, the limitations should be enforced only to users that does NOT have the permission to ADMINISTER this module.

This is a missing piece relevant for maaany small projects that does not have their own Drupal specialists, and also for many projects that want to recruit new people, let them prove themselves, but without having to trust them with permissions that would otherwise trigger a whole other set of considerations regarding the server, co-located sites, etc.

PS. There are situations where we would like to give permission to perform updates, or even just "check for updates", without giving the permission to enable or disable modules. That should also be taken into account here. Would be nice with an option to just check and perhaps report interesting updates to the users that has the permission to actually fetch updates. That might be a separate feature request, though.

Comments

karenann’s picture

I have been tasked with building a module which comes extremely close to what you have elegantly described. I am interested to know if any developments have happened since this was first posted and, going forward, I'll be happy to share any progress I make.

dww’s picture

Status: Active » Closed (won't fix)

The core update manager feature that lets you install new modules and update to newer versions already comes with a kill-switch. See the 'allow_authorize_operations' setting in the default.settings.php file that ships with core. People using the update manager in core have to have FTP/ssh access to the server for the update manager to work. You simply can not allow people to update modules without giving them full access to your filesystem. Period. So, I'm sorry to say, but you'll have to forget about that entire aspect of this request.

The thing about preventing certain modules from being enabled by a user who can otherwise enable/disable modules is out of scope for this module. That would be a problem for sites that aren't using the update manager at all. This module is only for extending/enhancing the functionality of the core update manager, not for all module-related feature requests that can't be done in core.

Sorry,
-Derek