Cron wasn't sending my newsletter, but after some checking I discovered that running cron after logging in does it.

I have seen a permission to "send newsletter", but I don't think giving anonymous user sending privileges is a good thing.

How can this be fixed?

Comments

sutharsan’s picture

sutharsan commented
Status: Active » Postponed (maintainer needs more info)

Permission to "send newsletter" is required to send the newsletter when you edit/create the newsletter. No permissions are required to send a newsletter via cron.

enboig’s picture

enboig commented

that's not what I see. My site was not sending newsletters, but if I login and then go to cron.php they were sent. I tried loging out and then newsletters stop being sent.

shrop’s picture

shrop commented

I have experienced the same issue. A user reported that the newsletter was in process to send for a couple of days. I logged in and checked to make sure that my hourly cron had been running in Drupal logs. They haad been. I then ran /cron.php while logged in and then emails started flowing.

Thanks,
Shrop

sponnet’s picture

sponnet commented

I found a solution for this problem. We're using 'taxonomy access lite' and our problem was related to the fact that the 'Anonymous User' role didn't have access to the newsletter taxonomy terms.
After correcting this, the newsletters got sent from cron. Using curl instead of wget doesn't seem to change anything.
A structural problem may arise when users create new newsletters. They need to remember to add that term in the TAC-lite admin screen, or their problem will re-appear. You also need to give your newsletter administrative role access to the TAC-lite pages, which may not be what you want...
Possibly the same thing will happen when you use other modules like 'Taxonomy Access'

This problem looks to be related as a problem that was previously reported on Drupal 4.7 : http://drupal.org/node/134058

Stefaan Ponnet - Fusebox

chrissearle’s picture

chrissearle commented

Hmm. I can confirm that the problem described in #4 is the same with full taxonomy access control.

Not so sure of the solution tho - since we don't want the nodes being sent to be accessible to the anonymous user :(

Open for suggestions - but - as a workaround I may have to code up a perl script that logs in first - grabs the login cookie then calls cron.php

sutharsan’s picture

sutharsan commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

No response. Closing issue.

chrissearle’s picture

chrissearle commented

It's still an issue - however the problem seems to be simplenews together with an access control (Taxonomy Access, Taxonomy Access Lite, Simple Access etc) in combination.

I don't know enough about the access control mechanisms to say if simplenews can grab the posts as anonymous (i.e. when running cron) that are not available to anonymous.

However - while this issue exists - simplenews users who have access control protected newsletter nodes cannot get cron based delivery.

I have hacked around this with the following perl script:

http://www.chrissearle.org/node/261

This logs in, grabs the cookie and thus runs cron as a logged in user who has access to the simplenews nodes themselves.

To summarize - its nothing to do with the "send newsletter" permission, and will not affect users who have newsletter nodes available to anonymous users.

enboig’s picture

enboig commented

Any progress with this? Changing cron.php to look like

// $Id: cron.php,v 1.36 2006/08/09 07:42:55 dries Exp $

/**
 * @file
 * Handles incoming requests to fire off regularly-scheduled tasks (cron jobs).
 */

include_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
user_authenticate('admin', 'admin');
drupal_cron_run();

would solve the problem?

sutharsan’s picture

sutharsan commented

See #256795: Allow simplenews cron to send nodes that anonymous users cannot access for a patch.