When you mass unsubscribe users, it would be good to have an option to inactivate instead of delete users.
Use case :
Currently :
- user joe subscribes
- user joe sends admin an email "Please remove me from your list"
- admin uses mass unsubscribe to remove user joe
- at a later stage some users are mass imported (including joe)
- joe is subscribed again
- joe is unhappy
With this feature :
- user joe subscribes
- user joe sends admin an email "Please remove me from your list"
- admin uses mass unsubscribe to remove user joe and checks a box "inactivate users" (or use a "mass inactivate" link)
- at a later stage some users are mass imported (including joe)
- joe, being inactive is not subscribed again
- joe is happy
Hope that makes sense
Comment | File | Size | Author |
---|---|---|---|
#16 | simplenews-1315420-16.patch | 6.81 KB | corvus_ch |
#14 | simplenews-1315420-14.patch | 6.87 KB | corvus_ch |
#12 | simplenews-1315420-12.patch | 9.43 KB | corvus_ch |
#10 | simplenews-1315420-10.patch | 4.74 KB | corvus_ch |
#8 | simplenews-1315420-8.patch | 3.59 KB | corvus_ch |
Comments
Comment #1
miro_dietikerWe don't delete users.
Simplenews stores who has been unsubscribed and also allow to export unsubscribed users / subscribers.
However it doesn't store a full history about subscribe / unsubscribe per newsletter. It only stores last subscribe / unsubscribe date.
We should only consider the state is the user on mass import.
This can be provided as a (default) option:
Unsubscribe state:
- Don't resubscribe unsubscribed subscribers... (default)
- Subscribe provided list without any filter
Possibly the option needs better wording. Any suggestion?
Some Reference
#528808: distinguish between "not subscribed" and "unsubscribed"
Comment #2
BerdirClosing #1068608: Prevent mass subscription of previously manually unsubscripted email addresses as a duplicate
Comment #3
BerdirTagging issues for test-first candidates
Comment #4
miro_dietikerRelated to
#706904: List of outstanding, unconfirmed, anonymous subscription requests.
There's some thoughts more about how statuses should work in future.
Comment #5
leobard CreditAttribution: leobard commentedI fixed this for myself for Drupal 6 / Simplenews 2-0 Alpha2. See here: #1379060: When mass subscribe exclude unsubscribed subscribers (Drupal 6 Version, fixed, plz apply patch)
maybe, when #1379060: When mass subscribe exclude unsubscribed subscribers (Drupal 6 Version, fixed, plz apply patch) is reviewed and fixed, then the Drupal 6 fix could be frontported for this ticket here.
Comment #6
miro_dietikerOops, correct tagging.
Comment #7
BerdirComment #8
corvus_ch CreditAttribution: corvus_ch commentedComment #10
corvus_ch CreditAttribution: corvus_ch commentedDiff against wrong branch. Next try.
Comment #11
BerdirHm, can we maybe simplify/shorten the description a bit?
"If checked, previously unsubscribed e-mail addresses will be resubscribed. Consider that this might be against the will of your users."
Not sure about the last sentence but we can leave it like that for now.
Can we add a comment above this line? Explain that we are checking if the has a record for that newsletter and is unsubscribed or something like that.
This will currently result in saving only a single e-mail per category. Should use [].
If you extend your tests to use multiple e-mail addresses, you should be able to reproduce this.
"If you would like to resubscribe them, use the 'Force resubscription' option."
Also, try to avoid \ in translatable strings, instead use "", some translation tools tend to double-escape these \.
Let's extend this and test three mail addresses, two unsubscribed and a subscribed one.
"throught" => "through". Same above.
Comment #12
corvus_ch CreditAttribution: corvus_ch commentedComment #13
BerdirAs discussed, we need to add the category name here.
through :)
I'd suggest doing this the other way round, sorry for not being clear. " ... ' ... '.. ", aka having the single quotes in the string, not the otherway round.
Comment #14
corvus_ch CreditAttribution: corvus_ch commentedComment #15
BerdirOne last time, promised!
The comment should be wrapped at 80 characters.
Do we really need the $show_hint variable? Can't we simply do a !empty($unsubscribed) in the if below?. Because if we never added anything, it will be an empty array. It is not possible to have a category in there but no subscribers...
Which also means that the if here is not necessary either.
While you're at it, the space in front of $tested_subscribers isn't necessary.
Tests otherwise look great and should give us the ability to quickly verify my suggested simplifications of the above code.
Comment #16
corvus_ch CreditAttribution: corvus_ch commentedComment #17
BerdirComment #19
corvus_ch CreditAttribution: corvus_ch commented#16: simplenews-1315420-16.patch queued for re-testing.
Comment #20
BerdirCommited. Marking as a possible backport and closing #1379060: When mass subscribe exclude unsubscribed subscribers (Drupal 6 Version, fixed, plz apply patch) as a duplicate.
Comment #21
BerdirComment #22
boabjohn CreditAttribution: boabjohn commentedHi guys,
Not sure if there's an update to this one, but I'm confused as to how it's supposed to be working on the 6.x-2.x-.dev branch currently?
In my tests, we're always able to re-subscribe users regardless of whether they unsubscribed themselves, or indeed, even if their listing is shown as deactivated. In this case SN simply allows the mass subscribe operation to proceed, and reports that all users have been subscribed to a selected newsletter.
When we check, we find the deactivated user has indeed been ticked on as a subscriber to the newsletter, even though they are shown as a deactivated user. Surely this is an odd outcome to silently re-subscribe deactivated users?
This is reasonably mind-bending territory, so I apologise in advance if we've missed the "correct" application/intent of this otherwise very useful-sounding feature.
Thanks in advance!
Comment #23
BerdirIt's not supposed to work. That's why the status is at "patch (to be ported)", which means it has been commited 7.x-1.x needs to update the patch to work with 6.x-2.x so that it can be commited there as well.
Comment #24
boabjohn CreditAttribution: boabjohn commentedThanks for pointing me at the obvious: guess I was being a bit optimisitic. Thanks again for your energies and contributions,
Comment #25
rmcom CreditAttribution: rmcom commenteda 6x-2x patch would be greatly appreciated
Comment #25.0
rmcom CreditAttribution: rmcom commentedcorrected typo
Comment #26
rmcom CreditAttribution: rmcom commentedhas this patch been committed to the D6 version?
Comment #27
rmcom CreditAttribution: rmcom commented:-)
Comment #29
miro_dietikerBack to 7.x where it was fixed.
Will not happen for 6.x