I don't know whether this is a rules or token issue.
I know when the mail is not sent, it's because the recipient value is not placed. The defined token is not replaced by the real value of the CCK-email-field. So the scheduled Ruleset mail is not send to arbitrary emailadress, it's defined as token from CCK-field with emailadress
The scheduled mail is NOT sent only happened when:
1. when the CCK-email fiels not ticked "view anonymous" permissions AND anonymous views the specific node or cron is run by anonymous.


AND The scheduled mail IS sent happened when:
1. when I make the CCK-email field (=recipient) "view anonymous"
OR
2. when the CCK-email fiels not ticked "view anonymous" permissions AND CRON-RUN is done by me, logged on with administer-right (or user 1)

I've a Content Type with CCK fields, in one CCK field is a emailadres saved. I use a scheduled ruleset to send after 2 months a email to that emailadres, saved in the CCK-field. See also the attachment Message.jpg
The permissions for CCK-email-field: anonymous "not view", that seems to be the reason the recipient from the defined token is not found. When I'm logged on with administer permissions: "rights to view CCK-email-field" and the Scheduled rule is processed at that time by cron, the email is send and the recipient is found.
So the email is not send due to a permission-reason.
Is it possible to find the reason and solve this issue?
I use this scheduled ruleset for an job-bank in production, when a job is 2 months online then automatically is send an email to the contactperson of the specific job to ask if the job is still vacant.
Kind Regards

Comments

PipB’s picture

The token I used in the Scheduled Ruleset with mail to arbitrary mailadress:
[node:field_vaca_email-formatted]
I replace this with:
[node:field_vaca_email-raw]
and the scheduled mail is working.
Very strange......but my problem is solved.

But I don't know it's a very good solution because in the Api.txt file from the Token Module: the security note is not to use raw-token:

API.txt:
Security Note
========
If use any of the tokens in the ['raw'] sub-array then please note that these
are unfiltered values which could conceivably contain XSS attacks or other
malicious data. Your module should then provide it's own filtering to ensure the
safety of site users.

Because of this Security note, this issue is still active.

jpcwebb’s picture

I had the same problem - the only solution was to make the relevant field viewable by anonymous. It seems that there is a need to allow Rules to execute with a specified permission level, but in a way that does not present a security risk. I think this has been raised under the Rules issues tracker...

bluegeek9’s picture

Status: Active » Closed (outdated)