(1) new drupal 7
(2) install, activate rules_admin
(3) admin/config/workflow/rules: new rule test
(4) save it and go back to admin/config/workflow/rules
(5) now click "disable"
(6) click "confirm" on the next screen
(7) go back to admin/config/workflow/rules, and the disabled rule is neither in the active section nor in the inactive section

The rule still exists, but you don't have access to it from the admin screen, only by typing in its path (admin/config/workflow/rules/reaction/manage/whatever_rule_machine_name), from where you can reactivate it.

#29 d7_rules_owner_recover.patch766 bytesfago
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]
#22 d7_rules_are_lost.patch2.11 KBfago
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]
#18 d7_rules_are_lost.patch1.64 KBfago
FAILED: [[SimpleTest]]: [MySQL] 350 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#9 rules-rules_disappear-7889685-9.patch767 bytesmvdve
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]
Screen shot 2012-05-08 at 8.23.26 PM.png137.75 KBalberto56


same here

Any one find out the issue on this? I have a similar problem. When I enable a rule, it disappears! I'm trying to install PayPal payments for Drupal Commerce but whenever I enable the module rules, they disappear. I can see them in the rules_config table if I look at the database, but even changing the values directly there doesn't do anything.

Having the same issue with 7.x-2.5

Posted the below in the Commerce issue queue before finding this.

#2093881: Rules 7.x-2.5 inadvertently hides disabled payment method rules

Rolling back to 7.x-2.3 should resolve the problem for now if you're stuck.

Priority:Normal» Major

Uprated priorty - this makes Rules virtually unusable.

What happens:

A rule disappears from the main list, but it still exists as mentioned above.

When does it happen?

  • Enabling a rule
  • Disabling a rule
  • Deleting a condition from a rule
  • Deleting an action from a rule
  • Clone rules do not appear
  • Just saving an unchanged rule

EDIT: Additional data. We're using Features, and in the DB the invisible rules have the "owner" set to the relevant module name "mplz_rules", manually editing that to just "rules" causes the rule to reappear in the front-end.

That last one is the key - anything that involves saving a rule makes it vanish. Interestingly while simply saving makes the rule disappear, it does not flag up in Features.

In the database the "status" field of vanished rules is set to '3'.

+1 on this (#6), although changing the "owner" from my feature name to 'rules' in the db did not make the rule show up on the front end. Every saved rule does disappear, however. Rolling back to 7.23 to make my site work in the meantime.

One of the commit add a default condition that show only rules owned by rules

rules/ui/ui.controller.inc line 197

// By default show only configurations owned by rules.
$conditions += array(
'owner' => 'rules',

just comment it and issue solved

new767 bytes
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]

A patch file from the patch from #8. But why is the owner changed?

Status:Active» Needs review

The patch in #9 fixes the issue. The question is was this condition added for a reason? Seems like a feature that wasn't finished? I can't find any setting that allows one to change this condition. I also don't see a filter related to this condition.

patch #9 fixed the issue for me.
For reference, the change was introduced in #2045785: Keep track via which UI a rules has been configured

The problem appears to be in overviewTable() method in rules.

// By default show only configurations owned by rules.
$conditions += array(
'owner' => 'rules',

This eliminates any other non-Rules owned Rule from appearing until they update all their calls to this method by passing their owner to it.

Example, from Commerce Payment, my payment method screen is completely empty, until you change:

= array('event' => 'commerce_payment_methods', 'plugin' => 'reaction rule', 'active' => TRUE);


= array('event' => 'commerce_payment_methods', 'plugin' => 'reaction rule', 'active' => TRUE, 'owner' => 'commerce_payment');

Thereby including more than just 'rules' owned Rules in the query. THEN my payment method appeared, and stayed for good. This seems to affect just about any module that implements its own Rules and uses the class method above - if they do not pass owner, default Rules that get edited seem like they will vanish unless they are custom Rules created in the Rules UI (where owner is always rules).

Commenting out the owner condition in overviewTable() or not - this bug exists in a stable release and should be rectified quickly..

The patch in #9 fixes the issue.

hm, strange I cannot reproduce this. Do you have the owner column in the 'rules_config' table?

Else, try re-running rules_update_7211() manually:

function rules_update_7211() {
// Create a owner column.
db_add_field('rules_config', 'owner', array(
'description' => 'The name of the module via which the rule has been configured.',
'type' => 'varchar',
'length' => 255,
'not null' => TRUE,
'default' => 'rules',

for me i already have the owner column

I have an owner column - the issue is when the owner is reassigned from 'rules' to anything else - the $condition filter in #13 makes it not appear in results. That is why people are commenting it out.

The fix is either removing the $condition in Rules core, or every module that implements overviewTable() has to pass the owner value (as noted in #15). Otherwise, Rules who's owner is not 'rules' will not appear anywhere.

Priority:Major» Critical
new1.64 KB
FAILED: [[SimpleTest]]: [MySQL] 350 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

I had a look at this and it turns out the problem exits only in the combination with features / default rules. When a module provides a rule, it becomes $rule->module but is taken over as $rule->owner also. It may not be taken over though. However, this means we have to export the "owner" property also.

Attached patch fixes the problem for me. Please test.

Bumping priority to critical as this affects all default rules provided modules :/

>Otherwise, Rules who's owner is not 'rules' will not appear anywhere.
That's the idea. You can do your own UI and the rules will be displayed only there, e.g. commerce could do that in future.

I know - but as it stands, Commerce and contrib modules for it come with all sorts of default rules out of the box. The moment you edit them, they vanish, because the owners change. That is a separate issue from just Features exports - the query is excluding them.

@fago - patch #18 does not work for me. As kevinquillen, once you override the rule then it disappears. This is most commonly seen in Commerce Payment method rules where you have to edit them to change the gateway settings.

Status:Needs review» Needs work

The last submitted patch, d7_rules_are_lost.patch, failed testing.

Status:Needs work» Needs review
new2.11 KB
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]

Updated test-export to include the owner.

Status:Needs review» Needs work

@fago that patch does not work (#22).

#9 from @mvdve works.

I just got done trying both on a heavily loaded (module wise) Drupal Commerce site.

Status:Needs work» Fixed

#9 is a work-a-round which breaks the "owner" feature - we need a proper fix.

#22 worked in my tests, so I've committed it to move on.

ad #23:
Once you already ran into the problem, you need to revert your rule configurations to make things work again. Alternatively, you could manually set the "owner" column of you rule configurations to "rules" in the rules_config db tabe.

If the problem persists, please make sure you tried the instructions above *after* applying the fix. Then, if the problem continues to persist please reopen and provide further details.

But how does that fix the part that when overviewTable() is called, the owner is queried and set as 'rules'? This breaks other module functionality (like Commerce Payment) that implements that method. That means all of the modules in contrib land that use Rules and that method would have to update all of their conditions passed to overviewTable().

When other modules do not deal with owner, it will continue to be "rules" and the embedded UI will query for owner "rules" by default - thus, there shouldn't be any troubles for other modules like Drupal commerce.

However, they could rely on Rules >= 2.5 and start saving rules with "owner" => commerce + pass the condition to list only them if that's preferred.

for Commerce related issues follow #2093881: Rules 7.x-2.5 inadvertently hides disabled payment method rules. There is a patch pending that updates the Commerce payment admin page to filter for owner = rules or commerce_payment

Priority:Critical» Major
Status:Fixed» Active

Once you already ran into the problem, you need to revert your rule configurations to make things work again. Alternatively, you could manually set the "owner" column of you rule configurations to "rules" in the rules_config db tabe.

Thinking whether we could simplify that for folks. I figured "reverting the rules" helps is easy saying when the rules do not appear in the UI any more ;-) Thus, re-opening to find a better solution here.

-> The problematic rules should be
- overridden
- have 'module' and 'owner' being equal and
- owner != rules

-> Thus writing an update which sets the owner back to "rules" for those rules should do it.

Status:Active» Needs review
new766 bytes
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]

Here is a patch which implements the updated mentioned above. Thus, if you ran into the problem and your rules are still hidden, please try whether the update makes them appear again.

Status:Needs review» Active

Patch in #22 works fine for me.
After I applied the patch the feature was overridden, so I reverted it and rules reappeared. Then I regenerated the feature to make it return to default status.

Status:Active» Needs review

The patch in #29 returns the rules to the overview screen. However, the rules I had go missing were not disabled, they were exported to a feature, so I am unsure how the update hook will prevent them from going missing again.

They were exported to a feature but overridden, right? That's exactly what the update hook takes care off, please test it.

Updated: The fix to not let it happen again has been already committed, see #22.

They were exported to a feature but overridden, right? That's exactly what the update hook takes care off, please test it.

Yes, but an update hook only runs *once*. This is an ongoing issue. I ran the update hook, which made 3 rules appear. I then created a 4th rule, exported it, and now it is no longer visible, while the 3 that existed when the update hook was run are still visible.

Did you use the latest dev version or the patch from #22?

I had the problem as described above after updating from 2.3 to to 2.5. I have just tested the latest dev (7th Oct) and the problem has been fixed. I did not apply any of the patches above.

Just for reference and background, I am not using Features, I am not exporting any rules, I am not using my own rules ui like Commerce Payment. I am using the Scheduler module and currently writing features integrating with Rules and one part is to provide some default reaction rules. I was using Rules 2.3 fine but after updating to 2.5 I get the behaviour as described above. The reaction rules are provided initially inactive. When the rule is enabled it disappears from the list. In the db rules_config table the owner has been changed from 'scheduler' to 'rules'. I manually set it back to 'rules' and it reappears. Disabling the rule has the same problem, owner is set from 'rules' to 'scheduler'. I would have used the update in #29 but I just deleted the rows in rules_config, cleared the cache and refreshed from the .rules_default.inc file to do my tests again.

I presume it was the patch in #22, committed in #24 that has fixed the problem.

ps Thanks for a great module.

In my case I also had to use the patch found in #29 and run the update.php after that.

Dev version worked for me more or less, I think. I upgraded to Dev, ran update.php, but it found nothing to update. Changing the owner of the rule (Paypal Express Checkout) in the database directly did make it appear again.

You have to use the patch found in #29 on the dev version for update.php to fix the problem ;)

Status:Needs review» Reviewed & tested by the community

You have to use the patch found in #29 on the dev version for update.php to fix the problem

or you can manually edit the rules_config database table to set the owner back to your module name, not 'rules'.

It seems like atleast three of us agree that the dev version from 2.5+2 is working correctly now. The change in #22/#24 has already been committed, but I'm marking this RTBC in case the maintainers decided to commit the patch in #29 just for safety.


Title:Disabling a rule makes it disappear without a traceEnabling or disabling a contrib rule makes it disappear

Make the title more informative

I can confirm that when I use 7.x-2.x-dev and manually apply the patch from #29 it fixes the problem.

Ahh, missed that little detail! Thanks! :)

Mine has dissapeared too.
If i install the dev and apply the #29 patch, should i then, later, install the normal version of this module again, when a new comes out, or should i stay in dev versions ???

Hello Anjaro,
The correction in the current dev release will be included when the next full release is issued (at least that would be the usual procedure). So yes, it is preferable for live sites to update to the next full version release when it becomes available. If your site is running ok with the dev release as of now, you do not need to keep updating it when new dev releases come out, you can wait until the full release.

Does that help? I think I understood your question, but if not, ask again.


Yes, that helped me understand, thanks a lot, Jonathan :D

The patch works fine, it should be committed. Thanks.

Thank you very much! #22 + #29 works perfectly for me...

The patch works fine. Thanks a lot!

Status:Reviewed & tested by the community» Fixed

Thanks, I committed the recover-update also.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.