It would be super neato if there were some permissions to go along with features so that, for example, you could grant the following permissions:

  • administer features (this would let you do everything you can now do in features)
  • manage feature_name (this would allow a user with this permission to enable and disable a given feature)

So there would be a manage permission for each feature that's created. So a user that had the manage blog_feature permission but not he administer features permission could enable or disable the blog feature and that is all.

Currently you can use spaces and create a site space and then allow for something similar to this, but in order for features to be available to enable/disable in spaces it seems that the feature has to be enabled first within features (unless I'm missing something).

Comments

yhahn’s picture

yhahn CreditAttribution: yhahn commented
Assigned: Unassigned » yhahn

Interesting idea -- I take it the use case here is to allow clients or similar non-site builders to enable and disable features as they like?

jponch’s picture

jponch CreditAttribution: jponch commented

Yes - that's exactly correct. Open Atrium is another example - so that a client role can turn only select things on and off in their space and that's it.

We're looking to do it more on client websites though - so that the client can enable and disable some specific site features and not others. This would allow us to have lots of things residing in code as features - things the client doesn't need to worry about. Right now, if we want to keep the UI really clean and simple for the client, that's meant we manually create our own module that does a lot of the things several features could easily do. We then use features for things we don't mind the client seeing. Features is so much nicer though for organizing functionality into logical chunks and makes ongoing improvement and maintenance so nice that I'd like to use it for everything and just be able to hide some features from the client role. I'd also prefer the client role to not see all the other info on the features that won't make sense to them, just the title, description, and enable disable.

jponch’s picture

jponch CreditAttribution: jponch commented

And - just to clarify - the problem we have with the spaces implementation of this sort of thing is at least two-fold. One, this is for site-wide features that don't necessarily need the spaces module to even be used so creating a site space might be overkill. Two, we're hoping to eventually find a way for disabling a feature to disable dependent modules and eliminate node types, disable views, etc. and the spaces implementation requires a feature to be enabled in admin/build/features in order for it to show as a feature to enable/disable in spaces.

yhahn’s picture

yhahn CreditAttribution: yhahn commented

Hi Jared,

Thanks for the notes, they were very helpful. Back when we refactored spaces to take advantage of features I had a very similar conversation with Jeff Miccolis here about the eventual fate of spaces_site -- it seems nearly obsolete in the face of the way features is developing. We never got a chance to circle back around and figure out how to refactor that situation so that spaces truly is just a way to manage features on a per-group/user/xxx-space basis. For the site as a whole I agree it would be great to start fleshing out Features as a higher-level UI for site admins (ie. client) rather than site builders (ie. drupal developer).

Keep us posted on any thoughts or ideas you have for developments here and we'll keep you posted on any work coming through the pipelines on this front.

yhahn’s picture

yhahn CreditAttribution: yhahn commented
Status: Active » Fixed

This commit implements the 'administer features' and 'manage features' perms. We won't be doing per feature manage perms, as this seems rather ill-advised.

http://drupal.org/cvs?commit=270366

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

SocialNicheGuru’s picture

SocialNicheGuru CreditAttribution: SocialNicheGuru commented

We have a user case for per feature user permissions

I have two features: image board, calendar

I want to give some users the ability to add and manage the image board but not the calendar, other users the calendar and not the image board, and still other users get both.

Unless someone can point me to another way to do it without having to give each of the roles above 'manage feature' permission

Thomas_Zahreddin’s picture

Thomas_Zahreddin CreditAttribution: Thomas_Zahreddin commented
Assigned: yhahn » Unassigned
Category: feature » support
Status: Closed (fixed) » Active

i can see the usecase for these two seperate permissions …

but if the idea of ‚administer feature‘ only is to activate or decativate a feature - then i don't understand why admin/build/features/create has ‚administer feature‘ as permission?

And the permission ‚manage feature‘ should include ‚administer feature‘ - right?

Hope you can help me, to better understand what these two permissions should seperate - and in german they are nearly untranslatable, because the meaning of both words (manage and administer) is so close.

hefox’s picture

hefox CreditAttribution: hefox commented
Status: Active » Fixed

Administer is for admin type things like creating/editing features and enabling/disabling, manage for managing the individual feature configuration it looks like.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.