Problem/Motivation

While there are some sites where we can disable Context UI in the production environment, we find that more often clients want the ability to move a block to a different location, or add a new block they have created to a region. Either we have to do it for them, or give them the "Administer contexts" permission.

By providing access to such a powerful permission, there's a fair risk of something going wrong. All it takes is one condition to be removed by accident for the site to stop functioning correctly.

Proposed resolution

There is an existing Context Permissions module, but it has several issues:

  • Lack of direct access to the context_export_ui class severely limits features that can be included.
  • Limited set of permissions options.
  • Dependency on PHP filter module.
  • Several key bugs have not been resolved.
  • Naming issue causes drush problems -- code functions are named "context_permissions", but module name is set as "context_permisssions" (three s's).

To resolve these issues, we have created a patch that implements context_ui_permissions, a new submodule for context_ui. The patch will be posted for review shortly.

Remaining tasks

Review is needed of the submodule. If we can agree on the basic approach, tests will need to be written. Documentation is already in place.

User interface changes

When first installed, the submodule will grant the following roles to anyone who has "Administer contexts":

  • Access context overview page: Allows a user to access the primary Context UI overview page located at `admin/structure/context`.
  • Administer context settings: Allows a user to access and modify the Context Settings page located at `admin/structure/context/settings`.
  • Add contexts: Enable users to add new contexts to the site.
  • Import contexts: Enable users to import contexts.
  • Export contexts: Enable users to export contexts.
  • Show all contexts in Context UI: Displays all contexts on the Context UI overview page. A shortcut option for showing all rather than needing to set `Show` permissions for each Context using the advanced settings (see below).
  • Edit any context: Allows a user to click the 'edit' link on any Context, access the Context's edit page, and perform context edits. However, unless the `Edit all context fields` permission has been selected, the user will only be able to modify field contents, and cannot add or remove conditions and reactions.
  • Edit all context fields: Allows a user to modify the settings of the context's conditions and reactions, but cannot add any new conditions and reactions, and cannot remove any existing ones. This is an important option when requiring site builders to add and remove blocks or content, but not change the overall context structure.
  • Revert any context: Enable users to revert contexts.
  • Delete any context: Enable users to delete contexts.
  • Clone any context: Enable users to clone contexts.
  • Enable any context: Enable users to enable contexts.
  • Disable any context: Enable users to disable contexts.

These will be editable through the standard permissions page (admin/people/permissions).

An advanced option is the ability to choose "Enable role permissions by context" on the Context UI Settings page. Selecting this option will present the user with a series of checkboxes: Show, Edit, Edit fields, Revert, Delete, Clone, Enable, and Disable.

For each checkbox selected, permissions will be created for each context in the site. For example, if there is a context called "sitewide" and the "Delete" checkbox is selected, an administrator will have the ability to set in the site permissions which user roles can delete the "sitewide" context.

Please see the attached pictures for more information on the available options.

API changes

The patch has no API changes, but there is an .install file to add the basic permissions to any role that currently has the "Administer contexts" permission.

Data model changes

No data model changes. The submodule only controls access to existing features. If the module is uninstalled, Context UI will revert to functioning as it does today.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ron_s created an issue. See original summary.

ron_s’s picture

Please review the attached patch. I would appreciate your feedback. Thanks.

ron_s’s picture

After some further testing, we've created an improved version of the patch. This one includes the following changes:

  • Remove "Show context" options. Instead, automatically hide a context from display if a user has no permissions for it.
  • Simplify "Permissions per context" settings to only show a list of checkbox options (see attached image).
  • Split "Edit fields" option into "Edit condition triggers", "Edit condition settings", and "Edit reaction actions". "Triggers" are for the condition select and checkbox, "Settings" are for the condition values and options, and "Actions" are for the reaction select.
  • Add logic to hide contexts in the inline editor if user does not have permission to access them.
  • Fix code to properly save a context when a user has reduced permissions. Because context_ui is using the ctools export, there is no $form or $form_state['values'] available. All values must be used from $form_state['input']. This requires some unique processing to ensure the values aren't lost.
  • Built helper function (context_ui_permissions_ops_settings) to return operations set from anywhere in the code.

ron_s’s picture

The last submitted patch, 3: interdiff-2731977-2-3.patch, failed testing.

The last submitted patch, 3: interdiff-2731977-2-3.patch, failed testing.

The last submitted patch, 3: interdiff-2731977-2-3.patch, failed testing.

The last submitted patch, 3: interdiff-2731977-2-3.patch, failed testing.