1

I need to carry out a review of our user roles and permissions. Currently some roles and permissions are already bundled into existing features (usually custom content types), but most are not. I would like to get everything committed into features to kick-start the review.

What are the pros and cons of either of these approaches:

  1. Have one 'roles and permissions' feature that collects all of the roles and permissions? (This adds a lot of modules as dependencies.)
  2. Include roles and permissions into other features when needed? (This might still require a separate feature for the permissions that don't fit into other features.)

Alternative methods (eg to help reduce the amount of roles/permissions) welcome too!

Note: a lot of our custom content types share reusable fields, which will need to have user permissions defined for them.

Improve this question
5
  • 1
    I think you should rephrase your question from "is it better ..." to "what are the pros and cons ...". So that "you" decide for yourself based on such pros and cons, and so that you avoid asking an opinion based question. Also, are you interested in "other" techniques/solutions that may help to reduce the amount of roles/permissions?
    – Pierre.Vriens
    Apr 13, 2016 at 13:32
  • 1
    Thanks, @Pierre.Vriens - I've changed my phrasing according to your recommendation. And yes, other techniques/solutions are welcome!
    – kdmcguire
    Apr 13, 2016 at 13:37
  • Merci for taking my advice, much better question already. I tried to further condense it a bit (without changing the actual question too much). And integrated part of the comments also. Please verify if you agree with it, if not re-correct where needed. Just trying to help, ok?
    – Pierre.Vriens
    Apr 13, 2016 at 13:47
  • 1
    That is much better, thanks for your help :). I agree with your edits!
    – kdmcguire
    Apr 13, 2016 at 13:49
  • Just finished my "alternative method" suggestion ... enjoy digesting my answer ... and have a look at the video link "to get the idea". Curious about your feedback after you're done digesting ... If you want to consider the Group module, and you'd have followup questions related to "group", just post a new question.
    – Pierre.Vriens
    Apr 13, 2016 at 14:31

2 Answers 2

Reset to default
1

In terms of the user experience, listing the permission along with the feature is the better option. You will need to be searching a very long list if your permissions are complex and extensive.

The even more compelling reason to keep the feature and permissions together is for exporting. If you only plan to export a particular feature, it takes a long with it dependencies from a bunch of other modules.

Improve this answer
3
  • We don't do a lot of exporting, really. The content type features already depend on a couple of core features, like field bases, breadcrumbs, etc., so adding a permissions feature as another dependency isn't the first step down that path. Also, there are site administration permissions that wouldn't fit into our content features, so that would require a new feature anyway...
    – kdmcguire
    Apr 13, 2016 at 12:40
  • I would upvote you but don't have the ability to do so yet! Thanks for the input :)
    – kdmcguire
    Apr 13, 2016 at 12:44
  • I'll be going with this idea, and creating a separate 'admin permissions' feature for those not included in the content-type features. Thanks for your contribution :)
    – kdmcguire
    May 11, 2016 at 9:39
0

I'm not a features expert (or fan), but the approaches you wonder about are a ('the'?) typical challenge (pain?) in using Features. Therefor I think you should give it a thought if you can simplify the roles/permissions you are currently using. Read on for a possible approach about that, using the Group module, considered as an alternative for Organic Groups (which many people are familiar about).

Group allows for creating arbitrary collections of your content and users on your site, and grant access control permissions on those collections. It is available as of D7, and has a D8 version also. The Group module creates groups as entities, making them fully fieldable, extensible and exportable.

For this specific question, you'd enable the gnode submodule, and for each group type you would define the appropriate permissions (view, edit, delete, etc) for the various Content Types. That's it.

So it'd take some thought about how your groups and group types should look like, and what the Groups related "roles" and "permissions" would have to be for your various users. Those roles and permissions are specific to the Group module, and even though they have the same name as in Drupal core, they are not the same. After you complete your Group based roles/permissions, I bet you could get rid of quite a few of your existing roles/permissions (which make the remaining one more manageable).

After you've configured the Group module to fit your needs, you can "export" your roles/permission. Using Features I would recommend 1 single feature for this, obviously using the Group module (only?) as a dependency.

Resources

Improve this answer
2
  • Hey @Pieere.Vriens, thanks for the recommendation. I do like the look of Group, but because user roles are intricately tied in with the (paid) membership structure of our Org, it would be quite a long-term project to migrate from one system to the other. I'll keep Group in mind, though! Thanks for the info :)
    – kdmcguire
    Apr 18, 2016 at 9:58
  • I can understand it'd be a long term project. Seems like combining such switch with upgrading to D8 is a typical business case to do so (also because OG is not available for D8 yet). However, maybe you should give it some thought to already start using Group in D7 somehow, just to get used to it, and get a much better feeling of what the actual conversion effort would be.
    – Pierre.Vriens
    Apr 18, 2016 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.