This was found by #1901456: META: Config syncing does not work reliably., and I tracked it down.

Files: 
CommentFileSizeAuthor
filter-import-PASS.patch2.79 KBtim.plunkett
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch filter-import-PASS.patch. Unable to apply patch. See the log in the details link for more information. View
filter-import-FAIL.patch1.89 KBtim.plunkett
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,543 pass(es). View

Comments

tim.plunkett’s picture

Assigned: Unassigned » sun

Assigning to sun, because while this treats the symptom, I have a feeling something is out of order here, and he would know. :)

sun’s picture

Assigned: sun » Unassigned

I think the root cause here is #1808248: Add a separate module install/uninstall step to the config import process

The user role permission query fails, because the filter_test module is not enabled, and thus, the module that owns the permission cannot be found.

If you agree, let's mark this as duplicate.

tim.plunkett’s picture

I don't

+++ b/core/modules/filter/lib/Drupal/filter/Tests/FilterConfigTest.phpundefined
@@ -0,0 +1,62 @@
+  public static $modules = array('config', 'filter_test');

I'm enabling filter_test here. Everything in the method is after setUp(), so the module is already enabled...

sun’s picture

Oh. The 'roles' property shouldn't be contained in the first place.

I believe it's only part of the exported config, because I sent @EclipseGc a tarball of my entire active config dir — in which I apparently developed the FilterFormat config conversion, and at some earlier point, the 'roles' property was part of exported text format config objects :)

So to some extent, I think this is just broken data.

OTOH, it's interesting that the config import code fails on that. FilterFormat::postSave() changes the user role permissions upon creating a new format. The format is indeed "new".


The actual cause is that filter_permissions() calls into filter_formats() in order to retrieve the text format names.

However, filter_formats() excludes disabled formats.

sun’s picture

Status: Needs review » Needs work

#4 begs the question whether the 'roles' property needs to be exported, or whether user roles + role permissions are synced completely independently. To my knowledge, roles are converted into config already, but the role permissions are not.

Also, the new test here is a nice one. Let's convert it to DUTB though.

We should change filter_permissions() to call entity_load_multiple(), and make it... hm. I wanted to say "manually filter out disabled formats", but that would have the exact same result. :(

sun’s picture

Alas, we're running into the exact problem space that is being discussed in #1826602: Allow all configuration entities to be enabled/disabled

tim.plunkett’s picture

#737816: user_role_grant_permissions() throws PDOException when used with non-existent permissions (e.g. a permission for a disabled/uninstalled module) appears to be the same bug and fix, and seems to be in D7 as well. But I'm not sure if it's actually two bugs, with one fix, so I'm not marking either a duplicate yet.

Wim Leers’s picture

andypost’s picture

Priority: Normal » Major

Got that trouble. That's caused by export of filter format.
Actually export of fielter format does not provides "roles" key, so when format is imported postSave() does not assign permissions.
Also filter should depend on roles

andypost’s picture

Issue tags: +FilterSystemRevamp

Berdir queued filter-import-FAIL.patch for re-testing.

Status: Needs work » Needs review

Berdir queued filter-import-PASS.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, filter-import-PASS.patch, failed testing.

alexpott’s picture

Is this still an issue?

xjm’s picture

xjm’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.