Status
Not open for further replies.
thanks, another one -

I was trying to re-subscribe a set of subscribers those were hard bounced in the last campaign through "Bulk action from source" option. I uploaded the list of emails to be re-subscribed and selected subscribe as action. System then showed action has been taken and x no.of subscribers have been affected - but I found that no "blacklisted" subscribers were affected. Group privileges allow this operation and re-subscribing manually and confirming them works. Can you take a look ?
 
@VVT - Can you try re-saving the group privileges to be sure ?
Yup, I did it again today. It works when I select one manually and then subscribe that from the drop down. But if I do it via bulk action from source, either by uploading file or putting the emails line by line on the text area, it won't work. Can you try with your instance ?
 
Question regarding "delete-inactive-subscribers": I have a list with 4 email addresses and 300 campaigns.

When I run the command " delete-inactive-subscribers --list_uid="LISTID" --time="-6 months" --limit=1000" the delete command seems to iterate / run a query per campaign. Isn't there a more efficient way of doing this as it appears that the command would execute 4 x 305 SQL statements (surely it should be possible to run a maximum of 4 SQL statements)?
 
@bidorbuy - it actually checks each subscriber, once for the opens and once for the clicks.
While i believe there's a way to do this from a single query, i think that query would be fore inefficient that what we have now.

@VVT - Can you unzip and put resulted file in apps/customer/controllers to override existing file and tell me if that fixes it?
 

Attachments

  • List_subscribersController.php.zip
    8 KB · Views: 15
  • Like
Reactions: VVT
@bidorbuy - it actually checks each subscriber, once for the opens and once for the clicks.
While i believe there's a way to do this from a single query, i think that query would be fore inefficient that what we have now.

Thank you. I have given up running it with 4 subscribers against 300 campaigns - ten minutes in it was still not complete. I don't see this work well if I were to run it against a list of 300K subs.
 
@bidorbuy - it actually checks each subscriber, once for the opens and once for the clicks.
While i believe there's a way to do this from a single query, i think that query would be fore inefficient that what we have now.

@VVT - Can you unzip and put resulted file in apps/customer/controllers to override existing file and tell me if that fixes it?
that did the trick buddy :) , thank you !
 
Upon updating one install, it set all DS to 'inactive', which seems odd (a bug)!?

The (double) opt-out comes still pre-populated with email address, which defeats the purpose of having to fill-in the correct email for verification ('Please fill in your email address in order to unsubscribe from the list.' and 'to make sure this is not an accident or somebody else tries to unsubscribe you.'). Please fix that asap as it is a safety measure and standard for goood mailers @twisted1919 thx in advance :rolleyes:

When sub unsubscribes from merged list (which was used for mailing), sub is also unsubscribed from original list which went into merge (and I believe that should not be, as the merge is done for a specific purpose, otherwise, why do it). A fix for this is also requested please.
 
Last edited:
[ADD] - Added ability for delivery servers to be used for (Use for setting) : email tests and reports
Would be great if one could select more than one purpose (and hence exclude others), then one does not have to copy that DS (helps efficiency).
 
Upon updating one install, it set all DS to 'inactive', which seems odd (a bug)!?
Yes it did because lots of inner workings related to DS changed, so making them inactive was the only sane option. The alternative would have been to have all your campaigns clogged.

The (double) opt-out comes still pre-populated with email address, which defeats the purpose of having to fill-in the correct email for verification ('Please fill in your email address in order to unsubscribe from the list.' and 'to make sure this is not an accident or somebody else tries to unsubscribe you.').
This is by design to make things easier. You cannot opt out if you don't confirm, so it's perfectly safe.

When sub unsubscribes from merged list (which was used for mailing), sub is also unsubscribed from original list which went into merge (and I believe that should not be, as the merge is done for a specific purpose, otherwise, why do it). A fix for this is also requested please.
This works as expected.

Would be great if one could select more than one purpose (and hence exclude others), then one does not have to copy that DS (helps efficiency).
Unfortunately we cannot do this, history reasons within the code won't allow such functionality.
 
by design to make things easier. You cannot opt out if you don't confirm, so it's perfectly safe
It unfortunately lends itself to abuse, especially if forwarded emails get into the wrong hands, which one must assume these days with all the privacy/security breaches on a daily basis. Please either make it not pre-populated or with one confirmation step (an input or message) to avoid abuse. In the meantime, where can one disable the pre-population?

This works as expected.
For merged lists, how can one detach them from the sources (except by copy/export)?

thx
:)
 
Status
Not open for further replies.
Back
Top