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.When editing a component, if you check "Configure access for using this component with a permission" and check one or more roles then submit the form, you will see errors similar to this:
- Notice: Undefined index: use Rules component rules_machine_name in user_role_grant_permissions() (line 3172 of /var/www/localhost/public_html/modules/user/user.module).
- PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'module' cannot be null: INSERT INTO {role_permission} (rid, permission, module) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 4 [:db_insert_placeholder_1] => use Rules rules_machine_name [:db_insert_placeholder_2] => ) in user_role_grant_permissions() (line 3174 of /var/www/localhost/public_html/modules/user/user.module).
To reproduce:
- Go to admin/config/workflow/rules/components and click on "Add new component".
- Choose "Condition set (OR)". Any other selection will also give the same result. Press "Continue".
- Name the component "Test component permission". The machine name should be automatically set to "test_component_permission". Press "Continue".
- Click "Configure access for using this component with a permission." then check one or more of the role checkboxes. Press "Save changes".
- You will see a new page showing the above errors along with the text "The website encountered an unexpected error. Please try again later."
- These errors will also show up in the dblog at admin/reports/dblog.
Original post:
I'm experiencing an issue where changing the Machine Name of a component results in the following error:
Notice: Undefined index: use Rules component rules_old_machine_name in user_role_grant_permissions()This only happens when per-role permissions have been previously configured.
As a work-around:
Disabling "Configure access for using this component with a permission." and changing the Machine Name, then reconfiguring those permissions seems to work.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2340505-9-test-plus-fix.patch | 4.63 KB | TR |
| |||
| #9 | 2340505-9-test-only.patch | 2.6 KB | TR |
| #4 | 2340505-4.patch | 1.71 KB | TR |
Comments
Comment #1
TR CreditAttribution: TR commentedI don't understand how you are changing the machine name of a component in the UI. Rules uses the Drupal core "machine_name" form element, and once the machine name is set you are not give the option of changing it.
Comment #2
TR CreditAttribution: TR commentedOK, I see that I was using module-defined components, which have an immutable machine name. If I define a component through the UI then I *can* change the machine name. So that's one step.
But now I don't know exactly what you mean by "This only happens when per-role permissions have been previously configured."
It would be really nice if you provided detailed steps for reproducing this issue, including an export of your component so we can see exactly what you are using (Is this and action set, a rules set, an AND set, an OR set? Do you have a problem with all of these?) and so we don't have to keep trying guess what you're doing.
So far I don't see this error, and have never seen it, so IMO it's not likely I'll stumble upon the right combination of settings to reproduce the error without some guidance.
Comment #3
TR CreditAttribution: TR commentedOK, I was able to figure this out. IMO the feature to add access per-role to Rules components is just broken - I don't see how it ever worked properly. This feature was introduced by #1217128: limiting Rules components to specific permissions.
Specifically, if you check "Configure access for using this component with a permission", then you CANNOT select any of the role checkboxes which appear, otherwise you'll get a PDO exception. You need to SAVE the form first, THEN select the checkboxes, THEN save the form again. The tests don't catch this problem because these are not functional tests - they don't go through the UI, they test the feature programmatically.
This problem affects ALL components of all types.
The reason is that Rules defines the per-component permissions dynamically in hook_permissions() by querying the DB for components that have the 'access_exposed' key. This key is set by the "Configure access for using this component with a permission" checkbox, so until that checkbox is checked and the form is saved Rules won't define the permission for that component. The reason this causes a PDO exception if you try to select the role checkboxes at the same time is because then Drupal core will try to assign this new permission to the checked roles during the form submission handler, but at that point the component hasn't been saved yet so Rules hasn't defined that new permission yet.
The original post points out a similar problem caused when changing the machine name. The per-component permission dynamically defined by Rules includes the machine name in the permission key. If the machine name is changed, the permission for the new name isn't defined by Rules yet until the component has been saved in the DB. So you can't have the "Configure access for using this component with a permission" checkbox checked when you are changing the machine name. That is why the workaround you posted above, to uncheck the "Configure access for using this component with a permission", SAVE, then check it and SAVE again, DOES work to get around this error. The machine name problem only affects components that have editable machine names.
Bottom line, the code which generates and processes the component edit form, found in ui/ui.core.inc, just does not work properly. I've managed to fix part of it, and I should be able to come up with a fix for the rest soon.
Comment #4
TR CreditAttribution: TR commentedI think this fixes the operation of "Configure access for using this component with a permission" for both situations I described in #3 (one of which is the original poster's situation).
Comment #5
TR CreditAttribution: TR commentedAdding the "Needs tests" tag, because the operation of this form element should be tested.
Comment #6
TR CreditAttribution: TR commentedUpdated issue summary.
Comment #7
TR CreditAttribution: TR commentedI finally got around to writing the test for this. Here are two patches:
Comment #8
TR CreditAttribution: TR commentedThe error
D7 Drush setup of Drupal Failedis because of a core Drupal bug that was introduced this morning.I'm curious as to why the test-only patch works - that fails on my local test setup with the same error message as shown in the issue summary...
Comment #9
TR CreditAttribution: TR commentedPatches needed to be re-rolled now that #3005864: Fix @todo "Enable AJAX once #756762 is fixed" has been committed.
Comment #12
TR CreditAttribution: TR commentedThat's more like it. The test-only patch failed, as expected, because of the bug described in this issue.
And the test-plus-fix patch succeeded, as expected, because the patch fixes the issue.
Committed the test-plus-fix patch from #9.