Although this is helpful to the Panopoly distribution, in my experience, setting permissions through defaultconfig has prevented node_export from being able to generate content when enabling a Feature that injects demo content. There may be others having similar issues when trying to use Panopoly Widgets.

Comments

brantwynn’s picture

Fixed patch and updated to latest dev snapshot.

brantwynn’s picture

Title:Permission handling for panopoly_widgets is managed by defaultconfig, prevents node_export from importing content» Permission handling for Panopoly is managed by defaultconfig, prevents node_export from importing content
StatusFileSize
new1.98 KB

This is also an issue with panopoly_wysiwyg - it would appear that the mere presence of defaultcontent prevents node_export from importing its nodes during a drush site-install.

brantwynn’s picture

Oops - forgot to remove the deps.

populist’s picture

Status:Active» Postponed (maintainer needs more info)

I do not have much familiarity with node export, but can you explain a bit more how defaultconfig is preventing it from working? Presumably there is a solution to change either node_export.module or defaultconfig.module so they work together nicely.

It doesn't seem like it should be a problem to have defaultconfig set some permissions and node_export import some nodes.

brantwynn’s picture

Title:Permission handling for Panopoly is managed by defaultconfig, prevents node_export from importing content» Permission handling for Panopoly is managed by defaultconfig
Status:Postponed (maintainer needs more info)» Active

I'm not sure if I can provide more info at this time since we are no longer using node_export on the Demo Framework in favor of migrate. It just makes more sense for us to use migration classes that import demo content from CSV. From what I remember, it seemed that just having defaultconfig installed was enough to prevent node_export from importing nodes when a feature that managed these nodes was enabled via drush. Kind of an edge case, but the patch was necessary at the time.

Anyway... I suppose I could modify this Feature request - and perhaps this makes it a support request - but I'm not sure why Panopoly needs defaultconfig.

Couldn't these simple permission settings be managed in Features through normal permissions handling?

I have yet to find a need for defaultconfig in the Demo Framework - so I'm just wondering why its necessary in Panopoly?

Its also worth noting, I'm totally okay with continuing to patch defaultconfig out of panopoly for its inclusion in the Demo Framework. (re: #1949710: Use Panopoly Widgets in Demo Framework)

populist’s picture

Title:Permission handling for Panopoly is managed by defaultconfig» Default Config Prevents Node Export from Working
Project:Panopoly» Default config

OK. I am going to move this issue to the Default Config queue since there presumably is a solution there to the specific problem (node export cannot import with defaultconfig installed).

In terms of using the module in general, I think it has a lot of value because it allows settings (like user permissions) to be set on installation but not show up as formally overridden with the feature.

brantwynn’s picture

Issue tags:-demo_framework