Делал ежемесячную рассылку прайс-листа оптовикам и обнаружил интересную особенность модуля рассылок Битрикса.
Если пользователь сменит через редактирование профиля свой e-mail, то рассылка останется на старый адрес.
От ТП Битрика на вопрос, будут ли рассылки уходить на старый адрес получил подтверждение
Подписку делал на отдельной странице в виде галочки "подписаться/отменить" подписку, без указания пользователем адреса, куда он хочет получать прайс-листы. В функцию CSubscription::Update() передаю текущий адрес пользователя $USER->GetEmail(). Поэтому пользователь даже не узнает, что прайс-листы не будут уходить по новому адресу
Напрашиваются следующие обходные решения:
Варианты решения:
1) Дать воможность вводить явно e-mail.
Если пользователь сменит свой e-mail в профиле, на этой странице останется старый, он это сможет увидеть и поменять.
2) Выводить как сейчас только галочку, но e-mail брать из подписки. При её отмене или подтверждении (при изменении состояния) заменять на текущий. Не очень очевидно для пользователя, но зато пользователь не ошибётся в e-mail
3) Синхронизовать изменения e-mail с подпиской, при изменении данных пользователя обновлять его подписки. Т.е. пользователю вообще ничего не надо будет делать.
Учитывая что на сайте есть и другие подписки, вариант №3 кажется оптимальным, т.к. не надо делать смену адреса для других подписок (новости, рекламные акции и т.д.)
Если пользователь сменит через редактирование профиля свой e-mail, то рассылка останется на старый адрес.
От ТП Битрика на вопрос, будут ли рассылки уходить на старый адрес получил подтверждение
Да, будут уходить на старый адрес, пока пользователь не отпишется от рассылки. |
Напрашиваются следующие обходные решения:
Варианты решения:
1) Дать воможность вводить явно e-mail.
Если пользователь сменит свой e-mail в профиле, на этой странице останется старый, он это сможет увидеть и поменять.
2) Выводить как сейчас только галочку, но e-mail брать из подписки. При её отмене или подтверждении (при изменении состояния) заменять на текущий. Не очень очевидно для пользователя, но зато пользователь не ошибётся в e-mail
3) Синхронизовать изменения e-mail с подпиской, при изменении данных пользователя обновлять его подписки. Т.е. пользователю вообще ничего не надо будет делать.
Учитывая что на сайте есть и другие подписки, вариант №3 кажется оптимальным, т.к. не надо делать смену адреса для других подписок (новости, рекламные акции и т.д.)