(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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

manoloka’s picture

same here

ncarty97’s picture

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.

Morten Andersen’s picture

Having the same issue with 7.x-2.5

Adam Wood’s picture

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.

adaddinsane’s picture

Priority: Normal » Major

Uprated priorty - this makes Rules virtually unusable.

adaddinsane’s picture

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'.

dojorob76’s picture

+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.

iKb’s picture

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

mvdve’s picture

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

Devin Carlson’s picture

Status: Active » Needs review
jantoine’s picture

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.

recrit’s picture

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

kevinquillen’s picture

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:

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

to

$conditions = 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..

Majdi’s picture

The patch in #9 fixes the issue.

fago’s picture

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',
  ));
}
Majdi’s picture

for me i already have the owner column

kevinquillen’s picture

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.

fago’s picture

Priority: Major » Critical
FileSize
1.64 KB

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.

kevinquillen’s picture

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.

recrit’s picture

@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.

fago’s picture

Status: Needs work » Needs review
FileSize
2.11 KB

Updated test-export to include the owner.

Perignon’s picture

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.

fago’s picture

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.

kevinquillen’s picture

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().

fago’s picture

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.

recrit’s picture

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

fago’s picture

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.

fago’s picture

Status: Active » Needs review
FileSize
766 bytes

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.

Norberto Ostallo’s picture

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.

fago’s picture

Status: Active » Needs review
jhedstrom’s picture

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.

fago’s picture

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.

jhedstrom’s picture

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.

fago’s picture

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

jonathan1055’s picture

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.

Jonathan
ps Thanks for a great module.

vensires’s picture

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

ncarty97’s picture

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.

vensires’s picture

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

jonathan1055’s picture

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.

Jonathan

jonathan1055’s picture

Title: Disabling a rule makes it disappear without a trace » Enabling or disabling a contrib rule makes it disappear

Make the title more informative

vegantriathlete’s picture

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

ncarty97’s picture

Ahh, missed that little detail! Thanks! :)

Anjaro’s picture

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 ???

jonathan1055’s picture

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.

Jonathan

Anjaro’s picture

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

FiNeX’s picture

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

RyJ’s picture

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

Anybody’s picture

The patch works fine. Thanks a lot!

fago’s picture

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.

girishmuraly’s picture

Issue summary: View changes

Unfortunately, this patch did not fix it for me when I upgrade Rules 2.3 to 2.7. I've posted a patch in https://www.drupal.org/node/2094879#comment-9403987 which helps me.

jonathan1055’s picture

Hi girishmuraly,
The code fix was at 2.5+2 so would have appeared in the full 7.x-2.6 release. So you should not need to use any patches if upgrading to 7.x-2.7

girishmuraly’s picture

Hi jonathan1055, sorry I didn't mean to say I patched again. As you said this patch (fix) is already in 2.7 so I was using 2.7 as is.

yaach’s picture

FYI,

I did have the same problem - disabling a rule will not longer be listed on the Workflow Rules list, not even in the Inactive Rules section. Just in case you want to start from scratch installing or updating Rules again, you need to delete all references for the specific 'inactive' rules in the Rules tables. This was my case using the Resource_conflict module which brings a default rule. I disabled the rule and I was not able to see it again, so I delete all references to that rule in the Rules tables, and then update Rules. Finally I was able to see my rule again.

(Note: Just Updating Rules was not fixing my problem.)

Using Rules 7.x.2.9