Hello and thanks a ton for this excellent module. I can think of many uses for it.
As of now, I'm trying to use it to send reminders for unpaid orders :
- The view works OK and returns an Order entity and a User entity for each row. They are correctly co,figured as such in the Rules Variables section of the view.
- I set up a rule triggered on cron run.
- I added an action to fetch the view's rows.
- I added a regular rules loop to go through the list.
- I added an action in the loop to display a message stating that order x is being treated (will be replaced by a Send mail action later).
If I run cron, the action is correctly triggered and the loop executed (Rules log says so), but the messages are not displayed.
I tried to trigger the rule on another event (Order Viewing, just for the sake of testing) and the messages are displayed correctly, one for each order fetched by the view.
So I'm pretty sure something is messed up when the action is triggered in cron's context.
Could anybody point me to the source of this problem, or even to a solution ?
Thanks in advance.
Comment | File | Size | Author |
---|---|---|---|
#13 | rule_on_view_order.jpg | 85.44 KB | Countzero |
#13 | rule_on_cron.jpg | 41.98 KB | Countzero |
#12 | view_rule.txt | 6.88 KB | Countzero |
#4 | cron_rule.txt | 1.21 KB | Countzero |
Comments
Comment #1
zhangtaihao CreditAttribution: zhangtaihao commentedWhat do you mean by "display a message"? Do you mean "Show a message on the site"? If yes, it doesn't show up because cron is typically not run as your logged in user. Cron isn't designed to show messages because cron is designed for system maintenance tasks. The first (and not the only) question is how cron would determine who the message is for when running outside of an authenticated context.
Traditionally, this problem is circumvented by setting a variable during a cron task. Then, on initializing Drupal, only under certain conditions (e.g. the currently authenticated user has the role "administrator") the variable is checked, a message is shown, and the variable is cleared. You should be able to do the same in Rules.
Comment #2
Countzero CreditAttribution: Countzero commentedThanks for your answer.
Yes, I meant that : "Displaying a message on the site", but it was just for testing purposes.
The real goal is to send reminder emails, so the current user shouldn't be relevant, as no information is fetched from the current context, but only from the view.
I understand I should use the same set-variable/run-on-init technique anyway ? It doesn't explain why the rule is not triggered AT ALL while set to fire on cron run though, and I really wish I could understand that ...
Comment #3
zhangtaihao CreditAttribution: zhangtaihao commentedCould you export your rule and attach it here? I have no idea what is going on until I've seen your rule.
In any case, I know of only two ways to run a rule on cron without writing your own module: using the event "Cron maintenance tasks are performed" and using Rules Scheduler.
Comment #4
Countzero CreditAttribution: Countzero commentedHere it is. Sorry for the french peaces, but it should be understandable anyway.
I left the debug part : message displaying and the "Order is viewed" event. The rule does trigger on this one, but not on the cron event.
Thanks for your time.
Comment #5
zhangtaihao CreditAttribution: zhangtaihao commentedWell, French is less unreadable than Greek to me.
Two questions:
Are you saying "Loop view Impayés" is showing up in the log for cron runs specifically?Oops. Are you testing cron by "Run cron" in the admin form, running cron using the cron.php link, or running cron via Drush?Comment #6
Countzero CreditAttribution: Countzero commentedThe log says cron runs flawlessly. Unfortunately, I can't access the server logs to doublecheck if something goes wrong, but I'm pretty sure it's OK.
I test via the admin link in admin_menu and via admin interface. The message 'Lopp view impayes' does display, sorry for the unprecise info I gave before.
Cannot test via drush : no ssh.
Comment #7
zhangtaihao CreditAttribution: zhangtaihao commentedRules doesn't trigger an output if there is an error. The question is, does the cron-triggered rule run? If you can't determine in the log normally, try adding a PHP action to execute
watchdog()
in the rule itself to try and log a cron run in the rule.Comment #8
Countzero CreditAttribution: Countzero commentedDid what you said. As expected, I can output to watchdog just before the View loop, but not inside it.
So we're sure the rule is triggered, but something is messed up with the view loop.
I retried with the other event (Order is viewed) and can write to watchdog inside the loop with no problem. The mails are also sent correctly.
Comment #9
zhangtaihao CreditAttribution: zhangtaihao commentedI've simulated your rule. The view rule runs just fine both on the site and in Drush. Having said that, I'm testing it on content types.
Do you know if your view attempts to use any environmental variables, specifically those that might not be available during cron? Also, given you are using Commerce, have you tried using something like VBO to achieve the same results?
Comment #10
Countzero CreditAttribution: Countzero commentedHere is the view, full of
crapfrench.It only uses the current date and user and order data.
I did try to use VBO first, but couldn't manage to launch it from cron.
Also, using your module would be a more elegant solution in my book.
Comment #11
zhangtaihao CreditAttribution: zhangtaihao commentedDid you mean to upload the exported view?
Comment #12
Countzero CreditAttribution: Countzero commentedOMG. Please see the attachment. Sorry for that.
Comment #13
Countzero CreditAttribution: Countzero commentedHere are two screenshots, displaying the Rules debug log :
- rule_on_view_order : Here you can see everything works fine.
- rule_on_cron : It's as the View Loop doesn't exist.
Nothing was change to the rule between the two calls.
Hope it will help you help me.
Comment #14
Countzero CreditAttribution: Countzero commentedI have to apology here.
It happens the website I work on, which I neither designed nor set up, has some weirdy access rights check implementation, so the Anonymous User, and cron alike, didn't have access to the view, despite it being accessible by everyone.
I used this fix and it works like a charm.
So your module is not at fault here but I think it could be useful to mention this cron rights problem somewhere. It should be more obvious in Rules documentation too, if you ask me, but well.
Thank you for your time and again, please accept my apologies for wasting it.
Comment #15
zhangtaihao CreditAttribution: zhangtaihao commentedNo apologies necessary :)
Glad you found the solution. I had a suspicion it was an access check problem, but it would have been near impossible to determine what exactly from my end (e.g. content, Views, Commerce, Rules, cron, etc.).
Good catch.
Comment #16
lzimmerman CreditAttribution: lzimmerman commentedThanks for sharing this. I have been trying to solve the same puzzle, and the fix you referenced worked perfectly.
Comment #17
Countzero CreditAttribution: Countzero commentedWell, thanks for your thanks (!), but the guy at the end of the link is the only one who actually diserves some :D.
Glad my post helped you find this fix anyway.
Comment #18
David Stosik CreditAttribution: David Stosik commentedThis issue has been closed for a while, but some people may be interested to know that if you set the view's query settings to "Disable SQL rewriting", then the results returned by the view may be the same, wether admin or anonymous.
Comment #19
zhangtaihao CreditAttribution: zhangtaihao commentedIndeed. I have specifically referenced this issue on the project page.
Thank you for your suggestion.
Comment #20
qasimzee CreditAttribution: qasimzee commentedDavid Stosik, very nice suggestion. Hats off. Much better than using code based solutions.
Comment #21
ericyellin CreditAttribution: ericyellin as a volunteer commentedI know this is an old thread, but I am wondering if anyone has determined why this issue with View Loop is happening and what access is impacting it.
I had the exact same issue on a multi-site setting where the issue is happening only for one site. All sites on same server, same core code and modules and same permission setting. I implemented David Stosik's solution Thanks It was driving us crazy! and it resolved the issue. Still I am not happy opening access in this way and am wondering if anyone has discovered the root cause.
Comment #22
ChristianWespire CreditAttribution: ChristianWespire commentedSame fix used here, David Stosik's solution figured it out. Is this a security vulnerability? Or is a view of type 'rules' only accessable by a rules loop and not by, for example, a url?