Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This was found by #1901456: META: Config syncing does not work reliably., and I tracked it down.
| Comment | File | Size | Author |
|---|---|---|---|
| filter-import-PASS.patch | 2.79 KB | tim.plunkett | |
| filter-import-FAIL.patch | 1.89 KB | tim.plunkett | |
Comments
Comment #1
tim.plunkettAssigning to sun, because while this treats the symptom, I have a feeling something is out of order here, and he would know. :)
Comment #2
sunI 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.
Comment #3
tim.plunkettI don't
I'm enabling filter_test here. Everything in the method is after setUp(), so the module is already enabled...
Comment #4
sunOh. 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 intofilter_formats()in order to retrieve the text format names.However,
filter_formats()excludes disabled formats.Comment #5
sun#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 callentity_load_multiple(), and make it... hm. I wanted to say "manually filter out disabled formats", but that would have the exact same result. :(Comment #6
sunAlas, we're running into the exact problem space that is being discussed in #1826602: Allow all configuration entities to be enabled/disabled
Comment #7
tim.plunkett#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.
Comment #8
Wim LeersSo, did #1808248: Add a separate module install/uninstall step to the config import process fix this for us?
Comment #9
andypostGot 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
Comment #10
andypostComment #14
alexpottIs this still an issue?
Comment #15
xjmIssues that may be related.
Comment #16
xjmAnd the other maybe-duplicate.
Comment #25
catchGoing to go ahead and mark this duplicate of #3167198: Deprecate the 'roles' property of text formats and remove it from the UI.
Comment #26
catch