Cannot Set Cutoff Date

It's working as far as I can tell in the 6.x-2.x-dev branch. Do you have the "Use cutoff date" box checked?

I notice you sometimes get a garbage value in their when the box is unchecked, and I've fixed that, but it works when the box is checked.

No go amigo.

Tried 1.6 and dev release. Can not get the cutoff date to change - box or no box ticked.

'Preview and send newsletter' results in error:
The newsletter has no content. The cutoff date is Wednesday, December 31, 1969 4:00:00 PM.

test email works fine.

drupal 6.19

In addition, as I was configuring this module, I discovered it didn't quite do what I needed. (but could be worked-around via sections I suppose)

I was hoping for a user selectable "newsletter" in the user profile (IE multiple newsletters from which to subscribe), or in the alternative, the argument for the view to be supplied via a field in the user profile (thus customizing which view (in this case which organic group view using the GID) would be generated for this particular users subscription).

Thanks.

I still haven't been able to reproduce this bug.

Do you have either the Date API and/or Date Popup modules installed, and if so what version is installed? SunMailer does enhance the UI for date selection when either of these modules is installed, so perhaps there's an incompatibility here with a specific version of those modules.

The logic that save the chosen date isn't too complex, it's a simple one-liner:

variable_set('sunmailer_cutoff', strtotime($values['sunmailer_cutoff']));

If the Date API or Date Popup modules aren't installed, validation will ensure that said strtotime() can parse the given date into a numerical timestamp. If it can't parse it, strtotime() will return FALSE/0, a numerical timestamp which often translates to December 31 1969/January 1 1970). If Date API and/or Date Popup are installed, then those modules will handle validation.

It's possible one of those modules is validating something that strtotime() can't parse.

Why yes.
Date, Date Popup, Date Timezone, Date Tools and Date API - 6.x-2.4 are installed and enabled. As well as Calendar and Calendar Popup - 6.x-2.2. (drupal-commons 1.1 requirements)

Thanks.

Hmm...I have the same version for the Date API and Date Popup. I installed/enabled the other modules with the same version, but I still can't repro. Any configuration for these modules I should be aware of, I haven't done anything past enabling them. Also, if you have access to the Devel module, what's the value of the sunmailer_cutoff variable after the form is submitted?

Devel on.

How would I get that exactly with Devel? (it's changed since I've used it much - seems like it should be showing more info)

Anyway, This is from the variable editor linked page (from the Devel block).

sunmailer_cutoff i:1284165240; 13
sunmailer_cutoff_no_update b:1; 4

Tthanks again.

Well it seems like a cutoff date is being stored by SunMailer, perhaps the form is not displaying the current cutoff date on the form due to some bug. Can you grab a screenshot of what you see after you submit a date into the form?

It does absolutely nothing really. It sends the form (I can see it load), but reloads the exact same page...almost as if it took it fine, just didn't acknowledge it...and no error indicated.

Pic attached, although it doesn't show much.

fyi PHP Version 5.2.9

This seems to be slightly different than the original issue reported. Are you saying that the cutoff date updates fine on that form, but the value you entered doesn't seem to have any effect when the newsletter is generated?

Yes, sorry for that confusion.

Since the error indicated the cutoff date was 1969 in the preview (clearly not what I had set), and since there was no indication of a "date saved" message or something on submission of the cutoff date form, I assumed the cutoff date was not being saved properly.

Sounds like, this may not be the case. BUT, the module thinks it's cutoff date IS set to 1969 and thus fails with no content on the preview as noted above.

Everything is working correctly on the back-end, the issue is that the incorrect date is being displayed in the front-end. This patch should fix it.

Fantastico. Working great. Thank you very much. Configuring now...

Quick question. I need to limit this to only one certain role. I see this in the Subscription Settings:

Access control for the subscription page:
Display for authenticated users only
Display for anonymous users if they can subscribe on the user registration form
Display for anonymous users

Access control for the subscription block:
Display for authenticated users only
Display for anonymous users if they can subscribe on the user registration form
Display for anonymous users

I'm not going to ask you to add Role selection (although that would be handy, you've done enough for me), but could you point me to where I could I edit a line or two in the module to hard-code the access control for a certain role (say, with ID 5)?

What I will then have (and I think this might be useful for others) is a sunmailer module that will send out to a small number of people a specific view customized to their user ID - in this case an OG view (if I can work out the og specific view settings...argh) that details recent content for that group. This would be useful for a teacher or project supervisor to get summaries, of the groups they supervise. AND regular users COULD NOT subscribe to that summary.

Or maybe this could be done with a simple permission added to allow or not allow certain roles to access the newsletters.

Thanks.

I was hoping this would work to limit the newsletter to those of a certain role, but it doesn't seem too. I can still see the "email newsletter" tab in a user profile that is not included in the role I was allowing.

Starting at line 183 in sunmailer.module -


* Access callback for the newsletter form.
*/
function sunmailer_form_access($type) {
// Display for authenticated users.
global $user;
// Change 'desired_role_name' to the role you want to allow access.
if (in_array('desired_role_name',$user->roles)) {
return TRUE;
}
// For anonymous users, check the settings.
switch ($type) {
case 'page':
$access = variable_get('sunmailer_page_access', 'anonymous');
break;
case 'block':
$access = variable_get('sunmailer_block_access', 'authenticated');
break;
default:
return FALSE;
}
switch ($access) {
case 'authenticated':
return FALSE;
case 'anonymous_register':
return variable_get('sunmailer_subscribe_register', TRUE) && user_register_access();
case 'anonymous':
return TRUE;
}
}
(/code>

And starting at line 476 in sunmailer.module -


* Directs users to the appropriate subscription form.
*/
function sunmailer_subscribe() {
// Display the subscription form for authenticated users.
global $user;
// Change 'desired_role_name' to the role you want to allow access.
if (in_array('desired_role_name',$user->roles)) {
return drupal_get_form('sunmailer_subscribe_form');
}
// Display the registration form or a message for anonymous users.
if (variable_get('sunmailer_subscribe_register', TRUE)) {
return drupal_get_form('user_register');
}
$message = t('Only registered users can subscribe to the email newsletter. ');
$message .= t('Register for an account if you do not have one, and then login.', array('@register' => url('user/register'), '@login' => url('user')));
return $message;
}
(/code>

Thanks. Any advice appreciated.

sunmailer_form_access() is the function you would want to fork.

/*
 * Access callback for the newsletter form.
 */
function sunmailer_form_access($type) {
  global $user;
  return ($user->uid == 1) || array_key_exists(DESIRED_RID, $user->roles);
}

The problem I see with the above code is that if you don't have the desired role, it's still possible for you to get access if the remaining access checks pass for your user.