unsubscribe reverts back after cron run

You find this string in Simplenews_roles. The Synchronize option deletes the subscription if the user account is removed and updates the email addres. It has no effect of being subscribed or not.
Changing project.

Yes agreed ... I have the same issue. The way we are able to work around this in our installation is a user must have a unique role called "receive newsletter". Only this role receives emails. We have a workflow-ng trigger that says when someone removes themselves from the newsletter, to remove the "receive newsletter" role.

It's far more complicated than it needs to be, but it works for the time being.

How were you able to setup workflow-ng to notice when a user unsubscribes. That "event" doesn't show up in my lists. Am I missing something?

You want to use the "User has updated his account details" event, then check in the database to see which newsletters are selected. This information can then be used to return a value to determine if the role needs to be removed. Requires a small amount of custom PHP code to query the database and make some updates, but not too terribly difficult.

Would you mind copy/pasting the PHP code that you created?

Is this the same ron_s from the ubercart forums?

Hi there Ryan, sorry it has taken me a while to post a reply. Yes this is the same ron_s from the ubercart forums. I have now created several versions of this code for different scenarios. I want to forewarn you it is *not* the exact same code in every situation, and you do have to make adjustments based on whether or not it is an ubercart subscription, workflow role assignment, manually selected, etc. However this code should give you the baseline for whatever situation you might have.

$tid = array(225);   // set an array of newsletter IDs
$rid = 7;   // list the role ID being removed

// Loop through all newsletters in the array
for($i = 0; $i < count($tid); $i++) {

   // Select the user IDs and subscription IDs for the given newsletter
   $result = db_query("SELECT u.uid AS uid, ss.snid AS snid FROM {users} u 
      INNER JOIN {simplenews_subscriptions} ss ON (u.uid = ss.uid) 
      INNER JOIN {simplenews_snid_tid} sst ON (ss.snid = sst.snid) 
      WHERE sst.tid = ".$tid[$i]);

   while($results = db_fetch_object($result)) 

      // For each user associated with a given newsletter, determine if they have the proper role.
      $sql = "SELECT COUNT(r.rid) AS role FROM {users_roles} r WHERE r.rid = ".$rid." AND r.uid = ".$results->uid;
      $cid = db_fetch_object(db_query($sql));

      // If they do NOT have the proper role, delete their newsletter subscription.
      if($cid->role == 0) {
         $sql = "DELETE FROM {simplenews_snid_tid} WHERE snid = ".$results->snid." AND tid = ".$tid[$i];
         $final = db_query($sql);
      }
   }
   
}

After creating all of these workflows, I decided to get rid of Simplenews Roles for now. I just don't see the value in it, and using Workflow is far more flexible. Also for this particular scenario, it is typically best to run it using the "Cron maintenance tasks performed" event.

Same issue here. Subscribing to this.

I'll install workflow_ng. I'm not a developer, but I do believe I understand what that code is doing. Thanks for posting!

This is a pretty big flaw -- many countries require you by law to allow users to unsubscribe from emails.

The problem though is that when we synchronize users in the role to subscriptions, we've no way of knowing whether the user was recently added to the role, or intentionally unsubscribed.

I suppose removing the sync on hook_cron and only doing it on account change would go some way towards taking care of this.
There's also simplenews_roles_nodeapi, which I don't see the point of.
But simplenews_roles_newsletter_submit is necessary so a newsletter that's been set to use a role gets its subscriptions.

I'm not sure this can be fixed without a change in architecture in simplenews itself -- to distinguish between an email being "not subscribed" and being "actively unsubcribed".

This is a pretty big flaw -- many countries require you by law to allow users to unsubscribe from emails.

Yes, this is the exact reason we decided to create a custom workflow instead, as noted in #8. We had users contacting us who had opted out of a newsletter, only to find they had been re-subscribed after a cron run.

My opinion is Simplenews Roles tries to be "too sophisticated" in its approach. It offers integrated synchronization capabilities, keeping accounts up-to-date at all times. However this leads to conflicts when someone wants to unsubscribe, yet the system won't let them do so because they still have a given role.

A better approach is to make the process more linear. When someone registers, give them access to a particular newsletter. When someone unsubscribes, remove access to the newsletter. If an admin removes access to a newsletter for a user, don't re-add it in the next cron run.

We also have a more unique problem where we have both "private" newsletters (paid subscribers) and "public" newsletters (basic registered users). We don't allow users to access "My Newsletters" in their profile because technically a registered user would be able to give himself or herself access to paid newsletters they should not have.

This just provides another level of caution for us that we need to make sure our process for assigning subscribe/unsubscribe for newsletters needs to be flawless.

Marking this as postponed --
we need #528808: distinguish between "not subscribed" and "unsubscribed" to get into the main Simplenews module and then we can use the new API to test whether subscribers already removed themselves from the list.

#528808: distinguish between "not subscribed" and "unsubscribed" has been committed to simplenews CVS.
This bug is open for business again :)

This is pretty hairy.

Here are my notes so far:

the rules are:
- we can change status from 1 to 0 in all cases
(we may unsub anybody)
- we can only change status from 0 to 1 if we are the source of the 0
(we can't resub users who unsubbed themselves.)
(this accounts for role changes)
- we can add subs if status doesn't exist.

the steps:
- 1
set status to 0 if user doesn't have role

- 2
insert all from role not already in
insert where (in role but not in sub)
not in sub means NULL
this is good as we keep off the status 0 records!

- 3
insert the ones we removed ourselves
in case a user loses then regains a role
insert where (in role but 0 in sub AND source is us)

This results in some pretty horrendous UPDATE queries.
It would be much simpler doing this in PHP by comparing arrays of uids -- but will that scale?

here's a query that illustrates the schema:

SELECT * FROM
simplenews_snid_tid snst
LEFT JOIN simplenews_subscriptions sns
ON snst.snid = sns.snid
LEFT JOIN users u
ON sns.uid = u.uid
LEFT JOIN users_roles ur
ON u.uid = ur.uid AND ur.rid = (ROLE ID)
WHERE
ur.uid IS NULL
AND
snst.status = 1

I've committed a fix for this to a new 6--2 branch.
This requires the current CVS HEAD version of Simplenews.
The 6--1 branch will continue to work with Simplenews 6--1.

Leaving this issue open -- please test and give feedback.

Is there any update for us D5 users? Please?

Like I said, fixing this requires a total change in the way Simplenews stores data about subscribers.
The change has been committed by the SImplenews maintainer to Simplenews HEAD, for an eventual 2.0 branch: #528808: distinguish between "not subscribed" and "unsubscribed".
This means that neither SN 5.x nor 6.x-1.0 will be able to have this bug fixed.

I would appreciate testing and feedback for 6.x-2.0, as the queries involved are quite complex.

I'm going to mark this as postponed so it still shows up in searches.

For reference:
- 2.x -- fix committed. Please try it!
- 1.x -- no fix possible.

Without waiting for the work on the simplenews 2.x branch (Look who 's talking ;) ) I made a quick patch to add a selection to restrict a newsletter to a role (the current operation of Simplenews Roles) or to allow other users too, like anonymous subscribers. Perhaps this patch will not make it into the module, pending the new approach, but who knows I make someone happy.

So, just to check I understand the patch properly:
- some NLs are marked as restricted.
- the restricted NLs behave as before the patch: cron resets everything
- not restricted NLs don't get the subs deleted by cron.

This solves the problem of an anon user subscribing to a synced newsletter getting unsubscribed. (though btw, I'm fixing this in 6--2: #600040: don't allow users to subscribe to newletters they can't be synced to.
What it doesn't solve as far as I can see is a user unsubbing from the newsletter, and then cron subbing them back again because they have a role.

Have I got that right?
I'll commit this anyway, as it will improve matters, as you say :)

subscribe

subscribe

I created a separate bug about this but as it's also said here in #17 I think it need to be emphasized that Simplenews CVS HEAD now is the wrong call for this and what's needed is Simplenews 6.x-2.x-dev

Hi, I'm getting the unsubscribe issue after cron happening on the 6.x-2.x-dev version with simplenews 6.x-2.x-dev (as of july 2010)

Any hints as thought this was ironed out in the 6.x-2.x-dev?

subscribe

As of the module page this should be solved.
Hovever this issue was never updated. :-S

Closing this to tidy up the issue queue.