Bug Unsubscribe issue

Status
Not open for further replies.

ichpen

Customer
So I created a test mailing list newsletter, I did not auto subscribe anyone yet I have 49 unsubscribed. I only subscribed 2 test users. How are these people unsubscribing if they're not subscribed from a newsletter that was never sent?

Also related to this viewing users of aforementioned newsletter shows 61 users and clicking on any page in the pagination bar (page 3 for example) produces Oops We ran into some problems (no server error).

Console shows:

404
 

Attachments

  • unsub.webp
    unsub.webp
    33.4 KB · Views: 5
Last edited:
How are these people unsubscribing if they're not subscribed from a newsletter that was never sent?
"Not subscribed" is not the same as "Unsubscribed".

Also related to this viewing users of aforementioned newsletter shows 61 users and clicking on any page in the pagination bar (page 3 for example) produces Oops We ran into some problems (no server error).
I'll fix that in the next version.
 
"Not subscribed" is not the same as "Unsubscribed".


I'll fix that in the next version.

Right but they're showing in the subscription log as unsubscribing to a newsletter that was never sent and they were never autosubscribed to on paper. I'm totally confused as you can tell :) Could these in fact be inactivity digest unsubscriptions being incorrectly flagged?
 
No, this is not an issue I am able to replicate. There is nothing unsubscribing users to a newly created mailing list.
 
No, this is not an issue I am able to replicate. There is nothing unsubscribing users to a newly created mailing list.

Alright it's highly confusing that's all, I have a new mailing list with a growing list of users being shown as unsubscribing in the subscription log to something that was never published and they were not subscribed to. Maybe you should consider a different choice of words in your logs?
 
I've created a new mailing list and it shows no users. In our internal testing list here @ this site, all users are in "unknown subscription state" which is what happens when the default subscription maintenance action has not yet run.

I see no need for any changes here.
 
I've created a new mailing list and it shows no users. In our internal testing list here @ this site, all users are in "unknown subscription state" which is what happens when the default subscription maintenance action has not yet run.

I see no need for any changes here.

Here's what I see in my subscription log. I see a bunch of users shown as unsubscribed from a Newsletter that they were never subscribed to and was never sent and is inactive. One thing I notice is that all users are inactive and the only thing I have running from a DB Mail perspective is the inactivity digest (main digest is disabled at the moment). If you consider that normal then so be it but to me it's not and looks like a bug with the inactivity digest unsubscribe action being logged under a different event.
 

Attachments

  • unsub-inactive.webp
    unsub-inactive.webp
    48.5 KB · Views: 4
Digest unsubscribes aren't logged, so no.

Is the ID of this mailing list 1? If not, then even if digest unsubscribes were logged, it couldn't be from this.
 
Actually I've just had a realisation, this could happen if someone clicks "Stop all email from siteName" when unsubscribing from any email.

The EmailStop feature in XF2 allows you to one-click unsubscribe from all possible email and if this happens, they are logged as unsubscribed from all mailing lists too.
 
Actually I've just had a realisation, this could happen if someone clicks "Stop all email from siteName" when unsubscribing from any email.

The EmailStop feature in XF2 allows you to one-click unsubscribe from all possible email and if this happens, they are logged as unsubscribed from all mailing lists too.

Riiiight, that makes sense now. And yes ID of mailing list above is 1.


Okay, I guess. You're still logging unsubscribed to a list that isn't active but I guess that's a byproduct or can that be logged differently somehow. It's somewhat misleading right now though one could argue also accurate.
 
The reason why they are logged in that way is because the system needs a way to detect that they have opted out, so that if later you decide to rebuild default subscribed, we are not violating their notification that they do not wish to receive email.
 
The reason why they are logged in that way is because the system needs a way to detect that they have opted out, so that if later you decide to rebuild default subscribed, we are not violating their notification that they do not wish to receive email.

OK does this mean that a future yet to be created newsletter will respect this setting if I auto sub everyone?
 
Hello @ichpen,

We hope your ticket regarding DragonByte Mail has been addressed to your satisfaction. This ticket has now been closed.

If your ticket has not been resolved, you can reply to this thread at any point in the next 7 days in order to reopen the ticket, afterwards this thread will be closed.

Please do not reply to this thread if your ticket has been resolved.

Thank you.


- DragonByte Technologies, Ltd.
 
Status
Not open for further replies.

DragonByte Mail

XenForo 1.5.3+ XenForo 2.0.x XenForo 2.1.x XenForo 2.2.x XenForo 2.3.x
Seller
DragonByte Technologies
Release date
Last update
Total downloads
1,349
Customer rating
0.00 star(s) 0 ratings
Back
Top