User permission handling

It's possible?

Based upon pure curiosity I tried to implement a module which allows to merge multiple roles together into one: https://www.drupal.org/project/role_mixin
It turns out, beside major UI problems, its actually quite doable.

This could be a solution for most problems here, but would require to add back the permissions into the exports

For the record, having all permissions in the roles exports was better than not having them at all.

I'm providing a "revert" patch for people that'd need it until something cleaner is found.

For the record, having all permissions in the roles exports was better than not having them at all.

I disagree. That tells me you are still using Features for config deployment rather than for bundling functionality. When bundling functionality into a "Feature" you would only want the specific permissions that you have added in your module.

Use "drush config-export" and "drush config-import" to fully deploy your configuration. Treat user permission settings like you would other site-specific content such as vocabulary terms and set them in code rather than relying on Features for that.

But if people use your patch then they can easily lose config on their system, which would be very bad. You might be importing a feature that doesn't have a full set of permissions causing other permissions to get lost. This could even be a security issue on your site by resetting permission defaults.

Edited: The *Real* solution to this issue is to open a Core issue to get the way roles and permission config is stored to be improved (maybe there is already such an issue, if so, please link it here)

Disclaimer : as a non-native english speaker with a messy mind, the following post probably contains a lot of mistakes and is certainly confuse. I apologize for this.
---

I'm sorry, I should have been more specific in my message in #8.
For me, right now, having all permissions in the roles exports is better than not having them at all. I know what the risks are and I'd love to have something like Features 7.x did but it does not seem to be for now.

I did take some time to temper my answer because yours made me a bit furious.
There are a lot of different kind of companies/shops out there, some big, some small, some experienced, some not, and a lot of different kind of projects too. In the particular project I'm currently working on, you're probably right, Features is not the best option. But I faced and heard a lot of other cases where Features was still the right choice to deploy configuration. As an example, I can talk about a multisite sharing some identical features that we had to maintain over time.
My first D8 project was made without Features and I had so many problems with deployment issues that I couldn't wait for Features to be ready. Today, I still maintain that project and while it's now running D8.2 it's still a pain in the ass to deal with that deployment issues. Plus, the funny thing is that I'm working on that project on my own. I can't imagine the same workflow on my current projet on which I have to collaborate with another developper.

From my point of view with my tiny understanding and my microscopic experience, I feel that CMI is an amazing base system but that it hasn't been designed for real world problems so we need to find some workarounds to continue building our projects. I probably missed something because when I read your comment or any blogpost or even when I watch some lectures about CMI, everybody says it's easy and perfect. Fortunately, I'm not the only one with another opinion, so I don't feel being so stupid but I really really wonder how 3/4 people can work together on the same project before and after it has gone live.

Anyway, today, with my understanding and the time I (don't) have to search new solutions and experiment, I'm still going to use Features for deployment for a while and it's OK. It can do it so, unless you remove all options to import Features settings, people are going to continue using it for deployment.

I'm very sorry for the off topic, it had to go outside. Thank you for all what you do, as my d.o bio said, I'm a strong supporter of Features so maybe I can't let it go ;)

Sure, I understand your frustrations. Sorry if my reply made you mad. When I give my talk on "Best Practices for Deployment in D8" I talk about 3 options: 1) pure CMI, 2) pure Features, 3) Hybrid mix CMI + Features. Obviously I end up recommending the Hybrid approach. But I recognize some people are still using option 2 for various reasons.

In D7, Features *was* CMI so we had full control over how various Core configuration was exported. But in D8 we rely on CMI to handle the actual configuration entities. If we want User Roles and Permissions to be handled differently, then it's really a core issue. I completely agree that it is important and I'd be happy to chime in and support in whatever core issue might get created on this.

I still disagree that putting all permissions in roles was better because that caused real sites to lose real data and I never want sites to lose data. I think Nedjo has the best way forward in #9 about making a plugin for this that people can enable or disable until it can be improved in code.

I'll let further work happen in that other plugin issue and closing this one.

Option 3) still comes in action when exporting user permissions.

Aim: Site A same roles and permissions as Site B.

I change permissions on Site A and would expect the active "roles" feature to recognize that to then be exported and then imported on Site B. Then on both sites config-export, done. Now I need to do that manually on each site.

Jesus, I now found the configurable setting to un-exclude user permissions. Big thanks for having built this into features!

Just for reference for everybody else coming here via search engine:

Go to /admin/config/development/features > Select your bundle > (Tab) Configure Bundles > Alter (Configure) > Uncheck "Strip out user permissions."

@leymannx You are an absolute star. This was hard to find even when following your instructions!! Absolute life saver. Owe you a pint.

Holy crap.. that was 2 hours of pulling my hair out trying to figure out why permissions were no longer being exported to features.
And then I found this thread.
@leymannx+++;

If you need permissions managed by Features, check out: https://www.drupal.org/project/features_permissions