A site manager can access all parts of administration necessary for allowed site customization, content editing, and user management
User story
Given that I am logged in as an editor,
when I visit administration
I want to be able to see and reach anything related to content, public-facing menus, theme colors, and users so that i can manage the site.
Background
This is a meta issue to cover some discussion that's begun in meetings, but isn't in issues yet. Cribbed from our meeting notes:
What can members customize?
- Colour. If we come up with a set of pre-defined colour schemes members can choose from, that would allow us to keep their sites using Octavia as a theme.
- Going beyond colors would require a custom theme.
- If someone wants their own custom colours, we may not be able to do it through the UI right away, but it's probably pretty easy to add a new colour scheme for someone who wants it (we don't have to tell people they can only choose from the five we start with; we can allow requests).
Rosemary did a review of what a site manager can do, assuming that's our top level role.
- They have full control over blocks, taxonomies, contact form settings.
- There are some areas we need to do further work locking down. What people can now do but should not have access to.
- There is further work to do creating a drutopia_platform module that would lock down some of that.
- What might people want to be able to do that they can't?
- Perhaps create a custom form (single configuration page) where we can put all the customizations that members could have access to. Example: a place to customize the title of a particular view display.
- There are some things that site admins don't yet have access to that we might want to reconsider. Example: menu administration, comment settings.
- What about enabling new Drutopia features? It's great to let people grow into their site. Right now site managers don't have that ability. Nedjo noted that for drutopia_platform feature we could require Paranoia method in it to iterate through modules on modules admin page and hide everything that is not prefixed with the install profile (or a base install profile). Would effectively mean that as a manager you would only have access to features. Dependencies should be enabled through this process.
- Probably we should not allow disabling, since effectively with a feature it doesn't do anything (e.g., a content type provided by the feature isn't deleted).
- Maybe a white list for modules that can be manually installed.
- There's a whole bunch more research to be done on customizations and permissions. It will be good to get people's ideas about what will make sense. But we need to test against the configuration management suite of modules. We're going to need some guiding principles, but also practical concerns that need to be addressed as well.
Central thing to look at: What configuration changes can break upgrades and new feature additions?
Interim answer to the question, "what can I customize?"
- Colour: choosing from a defined list of colour schemes. Advantage of being an early adopter, you can advocate for one that doesn't exist yet.
- Names of pages: selected ones can be customized (via config form).
- Edit order of menu items, add a static page to an existing menu, add a new menu.
- Ability to select which Drutopia modules are installed.
Proposed solution
See the above.
Also, to consider, these modules (courtesy comments in the issue to add a content editor to Drupal core):
- https://www.drupal.org/project/menu_admin_per_menu
- https://www.drupal.org/project/role_delegation
- https://www.drupal.org/project/view_unpublished
- https://www.drupal.org/project/override_node_options
- https://www.drupal.org/project/tasty_backend
- https://www.drupal.org/project/administerusersbyrole
Remaining work
Lots, to be determined.
Edited by Nedjo Rogers