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.
Comment | File | Size | Author |
---|---|---|---|
#4 | interdiff-2731977-2-3.txt | 35.02 KB | ron_s |
#3 | context-context_ui_permissions-2731977-3.patch | 29.28 KB | ron_s |
#3 | context_ui_permissions_settings-2.png | 40.58 KB | ron_s |
#2 | context-context_ui_permissions-2731977-2.patch | 24.15 KB | ron_s |
context_ui_permissions_settings.png | 57.92 KB | ron_s |
Comments
Comment #2
ron_s CreditAttribution: ron_s commentedPlease review the attached patch. I would appreciate your feedback. Thanks.
Comment #3
ron_s CreditAttribution: ron_s commentedAfter some further testing, we've created an improved version of the patch. This one includes the following changes:
$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.context_ui_permissions_ops_settings
) to return operations set from anywhere in the code.Comment #4
ron_s CreditAttribution: ron_s commentedSorry, that interdiff should have been a text file. See attached.