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.
(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.
Comment | File | Size | Author |
---|---|---|---|
#29 | d7_rules_owner_recover.patch | 766 bytes | fago |
#22 | d7_rules_are_lost.patch | 2.11 KB | fago |
#18 | d7_rules_are_lost.patch | 1.64 KB | fago |
#9 | rules-rules_disappear-7889685-9.patch | 767 bytes | mvdve |
Screen shot 2012-05-08 at 8.23.26 PM.png | 137.75 KB | alberto56 |
Comments
Comment #1
manoloka CreditAttribution: manoloka commentedsame here
Comment #2
ncarty97 CreditAttribution: ncarty97 commentedAny 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.
Comment #3
Morten Andersen CreditAttribution: Morten Andersen commentedHaving the same issue with 7.x-2.5
Comment #4
Adam Wood CreditAttribution: Adam Wood commentedPosted 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.
Comment #5
adaddinsaneUprated priorty - this makes Rules virtually unusable.
Comment #6
adaddinsaneWhat happens:
A rule disappears from the main list, but it still exists as mentioned above.
When does it happen?
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'.
Comment #7
dojorob76 CreditAttribution: dojorob76 commented+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.
Comment #8
iKb CreditAttribution: iKb commentedOne 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
Comment #9
mvdve CreditAttribution: mvdve commentedA patch file from the patch from #8. But why is the owner changed?
Comment #10
Devin Carlson CreditAttribution: Devin Carlson commentedComment #11
jantoine CreditAttribution: jantoine commentedThe 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.
Comment #12
recrit CreditAttribution: recrit commentedpatch #9 fixed the issue for me.
For reference, the change was introduced in #2045785: Keep track via which UI a rules has been configured
Comment #13
kevinquillen CreditAttribution: kevinquillen commentedThe problem appears to be in overviewTable() method in 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:
to
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..
Comment #14
Majdi CreditAttribution: Majdi commentedThe patch in #9 fixes the issue.
Comment #15
fagohm, strange I cannot reproduce this. Do you have the owner column in the 'rules_config' table?
Else, try re-running rules_update_7211() manually:
Comment #16
Majdi CreditAttribution: Majdi commentedfor me i already have the owner column
Comment #17
kevinquillen CreditAttribution: kevinquillen commentedI 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.
Comment #18
fagoI 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.
Comment #19
kevinquillen CreditAttribution: kevinquillen commentedI 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.
Comment #20
recrit CreditAttribution: recrit commented@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.
Comment #22
fagoUpdated test-export to include the owner.
Comment #23
Perignon CreditAttribution: Perignon commented@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.
Comment #24
fago#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.
Comment #25
kevinquillen CreditAttribution: kevinquillen commentedBut 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().
Comment #26
fagoWhen 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.
Comment #27
recrit CreditAttribution: recrit commentedfor 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
Comment #28
fagoThinking 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.
Comment #29
fagoHere 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.
Comment #30
Norberto Ostallo CreditAttribution: Norberto Ostallo commentedPatch 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.
Comment #31
fagoComment #32
jhedstromThe 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.
Comment #33
fagoThey 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.
Comment #34
jhedstromYes, 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.
Comment #35
fagoDid you use the latest dev version or the patch from #22?
Comment #36
jonathan1055 CreditAttribution: jonathan1055 commentedI 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.
Comment #37
vensires CreditAttribution: vensires commentedIn my case I also had to use the patch found in #29 and run the update.php after that.
Comment #38
ncarty97 CreditAttribution: ncarty97 commentedDev 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.
Comment #39
vensires CreditAttribution: vensires commentedYou have to use the patch found in #29 on the dev version for update.php to fix the problem ;)
Comment #40
jonathan1055 CreditAttribution: jonathan1055 commentedor 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
Comment #41
jonathan1055 CreditAttribution: jonathan1055 commentedMake the title more informative
Comment #42
vegantriathleteI can confirm that when I use 7.x-2.x-dev and manually apply the patch from #29 it fixes the problem.
Comment #43
ncarty97 CreditAttribution: ncarty97 commentedAhh, missed that little detail! Thanks! :)
Comment #44
Anjaro CreditAttribution: Anjaro commentedMine 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 ???
Comment #45
jonathan1055 CreditAttribution: jonathan1055 commentedHello 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
Comment #46
Anjaro CreditAttribution: Anjaro commentedYes, that helped me understand, thanks a lot, Jonathan :D
Comment #47
FiNeX CreditAttribution: FiNeX commentedThe patch works fine, it should be committed. Thanks.
Comment #48
RyJ CreditAttribution: RyJ commentedThank you very much! #22 + #29 works perfectly for me...
Comment #49
AnybodyThe patch works fine. Thanks a lot!
Comment #50
fagoThanks, I committed the recover-update also.
Comment #52
girishmuraly CreditAttribution: girishmuraly commentedUnfortunately, 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.
Comment #53
jonathan1055 CreditAttribution: jonathan1055 commentedHi 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
Comment #54
girishmuraly CreditAttribution: girishmuraly commentedHi 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.
Comment #55
yaach CreditAttribution: yaach as a volunteer commentedFYI,
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