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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

zhangtaihao’s picture

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

Countzero’s picture

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

zhangtaihao’s picture

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

Countzero’s picture

FileSize
1.21 KB

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

zhangtaihao’s picture

Well, French is less unreadable than Greek to me.

Two questions:

  1. 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?
  2. How are you triggering cron (and are you sure cron is running correctly)?
Countzero’s picture

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

zhangtaihao’s picture

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

Countzero’s picture

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

zhangtaihao’s picture

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

Countzero’s picture

Here is the view, full of crap french.

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.

zhangtaihao’s picture

Did you mean to upload the exported view?

Countzero’s picture

FileSize
6.88 KB

OMG. Please see the attachment. Sorry for that.

Countzero’s picture

FileSize
41.98 KB
85.44 KB

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

Countzero’s picture

Status: Active » Closed (works as designed)

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

zhangtaihao’s picture

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

lzimmerman’s picture

Thanks for sharing this. I have been trying to solve the same puzzle, and the fix you referenced worked perfectly.

Countzero’s picture

Well, 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.

David Stosik’s picture

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

zhangtaihao’s picture

Indeed. I have specifically referenced this issue on the project page.

Thank you for your suggestion.

qasimzee’s picture

David Stosik, very nice suggestion. Hats off. Much better than using code based solutions.

ericyellin’s picture

Issue summary: View changes

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

ChristianWespire’s picture

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