Harmonize app/distro/feature component names (roles, vocabularies, and so on)

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Incompatible component names are a significant barrier to interoperable features. Component types that tend to be shared between multiple features or apps include: roles, taxonomy vocabularies, text formats, and content types.

The Apps compatible module is one initiative to address incompatibilities by providing a set of generic components and methods to share them between apps.

To help determine what standardized component names would make sense for compatible features between apps and distros, a first step is to inventory the roles and names currently in use.

This wiki page aims to capture existing names for some key component types as used in various features sets and distros. Please help fill it out!

Related content
Related Discussion:
Should distro based features be compatible with other distro features?
Which feature based conflicts could be solved by standards or naming conventions?

Related Poll:
Would you, as a Feature/Distro developer agree to a standardized feature creation process?

Related Issue: Make Commons Features as interoperable with other features as possible


Role Administer site Manage content and users Manage content Post content Translate content and localize interface Maintain blog
Drupal core "standard" administrator
Commons (6.x) site admin content manager
Julio administrator content creator
Nodestream administrator editor writer translator blogger
Open Aid administrator content editor
Open Atrium (6.x) administrator manager
OpenEnterprise administrator editor copywriter
OpenDeals administrator Manager
Open Outreach administrator editor contributor
OpenPublic administrator editor
OpenPublish administrator editor author
OpenChurch administrator editor
Panopoly administrator editor
Most used administrator (12) manager (2) editor (8) ? translator (1) blogger (1)

Not yet categorized

Commons: community manager
Nodestream: chief editor
OpenPublic: staff

Conflicts: Distro based

Distro Features Conflict Comparison - Commons 7.x based


The list I am using

murrayw's picture

Interesting issue.

I have built a distro with a number of features for which need to reuse roles. I decided to use a list of roles mentioned in a presentation I saw (heard?) on Workbench. Apparently the following roles have been found to work well for a number of scenarios:


The Workbench people may have some further feedback on this.

The issue of roles is a very vexed because they (i) cut across features for permissions and (ii) can be a dependency for things like WYSIWYG/text formats.

I have solved the second problem by having a "roles" feature which is used as a dependency by my WYSIWYG feature (and others). Not really a "solution" but at least the roles part of the equation has been factored out. ie. My app commits to a known set of supported roles. It's a shame too be prescriptive so early but it is a choice you are forced to make.

On the permissions side of things for content types I have handled this by defining the perms programatically in my "roles" feature rather than chrystalizing them in Features. The code listens out for the creation of new content types and then populates permissions according to a mapping. eg. editor can edit all content for type x, author can edit own content for type x.

I went down this path because site builders will always need to override perms for special cases. Features is not a good solution here because of inevitable overrides (oh noes). Also, it handles the creation of unknown future content types. This has been working well for me so far. This may be a possible solution for http://drupal.org/node/1738396.

Generally speaking I have found that making your Features as small as possible minimises the chance of overrides. Cross site stuff really should not be mixed in with the Feature as things will get messy as soon as the site builder needs the flexibility they are so used to.

I would suggest that only feature specific roles should make it into a "vertical" Feature. eg. "modulex manager". Horizontal roles (site wide ones such as being discussed here) and their perms probably should be handled outside the Feature somehow. Having a list of predefined roles could just lead to brittle solutions. Auto creating perms via a mapping could be a viable solution, as discussed above. However, in the case of roles being used as a dependency (as in the case of WYSIWYG/text formats) having cross site roles would be very helpful.

It's a toughie.

Nedjo - I smiled when I saw your Apps Compatible module. It is tackling the kind of issues I have been pondering the last 6 months. I settled on a few extra slots for use across content types: tag, category, thumbnail, hero, banner, attachment, photo, see_also, etc. These are specific to my use case though. It is a fine line to draw between what is truely reusable and what is helpful for just you. Another discussion, another page.

I'll be following what you are doing. Solving this stuff is crucial for getting Features to play nice on unknown target systems.

Drupal Geek

murrayw > what's the

guillaumev's picture

murrayw > what's the difference between the editor, moderator and publisher roles in your post ?

As murrayw explained it very well, roles are crucial for compatible apps. In my opinion, these roles should cover 90 % of what everyone has or might have, but no more, otherwise we'll end up with too many roles. I would say that we should have no more than 5 default roles.

I don't really agree however, with the idea of having permissions assigned programmatically. One advantage of features is that you can know easily what you have inside the feature. If you start adding custom code, then you might as well create a module... For things that are currently still not features exportable, I agree with adding custom code, however, for the others (such as permissions or variables), Features Override is there.

Finally, I'm going to start working on Base features: basically the issue for me was that I tried to build a website based on the Debut features set, but I ended up changing various things (such as the article view/context or the links view/context), and I now believe that an app should be:

  • One "model" feature, which provides only fields, content types, permissions and variables and does not assume anything on how the content should be displayed
  • One "view" feature which can include a view, a context, a menu item etc... and displays the content in a specific way

Ideally, any article app should be based on the same "model" feature but can provide different "view" features, and the end user would just have to choose which app he prefers to use to display his articles the way he prefers...

I will work on those base features and let you know how it goes, but obviously any comment on this is welcome.

Role definitions

murrayw's picture

To be honest I am only currently using author and editor:
- author can create and edit their own
- editor can create, edit, delete

The other roles would be for workflow, something I am yet to implement. As I said, the roles were mentioned by one of the Workbench devs as being ones they have found useful. Taking a stab at a definition:
- moderator can OK new content
- publisher can push it live.

If you are going to come up with a list of roles then you may also need to consider these workflow aspects as well as content type CRUD.

@guillaumev With respect to your comments on a custom module - you are right, that is exactly what I am suggesting. I propose that a "roles" module/feature has some smarts to populate permissions for the roles on new content types. It works as follows:
- roles module installed
- feature_x module (roles as a dependency) is installed with content_type_y
- roles module populates cross cutting permissions on the content_type_y(if none have already been installed by feature_x)
- site builder can go in and edit perms if they need to
- no overrides.

I like this approach because the "roles" module/feature encapsulates the roles and permissions. It is free to cross cut horizontally over vertical features. The vertical Feature knows it is dependent on roles and can therefore hand content type perms off to it. I get the fear about hardcoding these roles into vertical features because you are being prescriptive. Not all site builders are going to be happy about the overrides. To be honest, I haven't played with Features Overrides so can't really comment on that. I see it as a solution to a problem I would rather avoid.

@guillaumev I'm digging your thoughts on the standard functionality for a content type (context, views, perms, variables). I went down the path of having a standard set of aspects captured in a Feature as well. Overtime I took most of them out of the Feature due to overrides. The site builder I was working with was relentless in forcing me to design a system which would be flexible :) They now are populated in code during install profile (or possibly in code in the feature itself). Context is nasty because any extra reactions leads to an override. Ditto for cross cutting permissions (see above). In the end I was left with fields, a couple of views, some metatag config, schema.org definitions and a base set of view modes (key for me) and a context (only if the feature really needed it for block placement). My experience has been that populating this stuff by code is the way to go in order to give site builders freedom. It has really made me question the utility of Features for all config given the need for freedom.

I'm really enjoying this conversation :)

Drupal Geek

Just a quick comment that we

randallknutson's picture

Just a quick comment that we considered using author but ran into issue with nodes actually having an author field so it gets confusing. I'd recommend against using that name.

Why only Roles?

jimcet's picture

nedyo.Thanks for the overview list and more for the name of your post, but it is not only the roles, it's also taxonomy type names, content type names, text formats.

Have I forgot something?

I do understand that there are modules already existent, who try or solve some or almost all of them, but does it make it easier for everyone?


nedjo's picture

Definitely all those entity and config types, and more, could use analysis and work. I inventoried role names only as a start. If you'd like to create wiki pages for terms, content types, and text formats, and inventory each, that would be great!

no worries

jimcet's picture

Are you ok with changing the title of the post, so it's more generic?
I have prepared a overview table of conflicts based on commons 7.x and compared to the distros you've started with the roles.

That would be great!

nedjo's picture

@jimcet: I've gone ahead and generecized the title and body. Please edit away!


jimcet's picture

I have added a link to the wiki.
have also added links to related content/polls/discussions.

Distribution profiles

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: