Я заметил, что в разделе Администратор | Электронная почта | Отправлено дайджест-письмо не было отправлено пользователям, хотя все они получили уведомление о событии user_watching_first_post (согласно настройкам по умолчанию).
Я подтвердил, что дело не в том, что эти пользователи недавно заходили на сайт, что срок действия настройки «Отключать дайджест-письма после N дней» истёк или что они изменили свои настройки уведомлений по электронной почте.
Правильно ли я понимаю, что уведомительное письмо считается активностью пользователя, из-за чего дайджест пропускается? Если да, то это не то поведение, которое я ожидал…
Мы используем настройку «Следить за первым сообщением» для конкретного тега, чтобы уведомлять пользователей о темах высокого приоритета, но при этом хотим, чтобы они получали регулярный дайджест другой активности на форуме.
Это крайне важно для нашей концепции — буду рад любым предложениям о том, как это реализовать.
Получается, что получение уведомления по электронной почте о теме не позволяет ей отображаться в резюме? Логично, что вы не хотите видеть в резюме сообщение, которое вам уже было отправлено по электронной почте другим способом.
Это гораздо больше, чем просто это. Получение уведомления по электронной почте, похоже, полностью сбрасывает подсчёт, так что ни одна тема, старше уведомления, не попадает в сводку. Это меня всегда раздражало.
По сути, если пользователь, получивший уведомление по электронной почте, не посещает сайт, то темы, появившиеся между предыдущей сводкой и последним уведомлением, вообще не получают никакого освещения. А когда сводка наконец-то появляется, сайт выглядит гораздо более тихим, чем он есть на самом деле.
Я бы хотел видеть реализацию именно так, как вы предлагаете: чтобы для пользователей, получивших уведомление по электронной почте, но не посетивших сайт, в сводке подавлялись только те темы, по которым пришло уведомление. Это стало бы огромным улучшением для сайтов, где по умолчанию включено отслеживание множества тем!!
Спасибо за подтверждение, Нейтан. Да, дайджест не был отправлен, несмотря на наличие других новых подходящих тем.
Если бы дайджест просто избегал дублирования темы, о которой уже было уведомлено, это имело бы смысл, но то, что происходит, похоже на упущение или ошибку, которая весьма контрпродуктивна.
@pfaffman — похоже ли это на правило, которое можно как-то обойти? Или здесь потребуется внимание разработчиков?
Для этого потребуется плагин. Я однажды написал один, который, по крайней мере на тот момент, «добавлял количество новых постов в сводное/резюме-письмо на третье место (обычно туда, где указывается число новых пользователей)». Таким образом, он меняет только этот заголовок в верхней части страницы.
Он переопределяет весь шаблон, так что это потенциальное решение.
При более внимательном рассмотрении это действительно похоже на ошибку, а не на проблему, которую нужно решать с помощью плагина. Я уверен, что такое поведение не является преднамеренным.
В Site_settings есть параметры для отключения дайджеста, но ни один из них не относится к другим уведомлениям по электронной почте:
отключать письмо-дайджест через N дней
отключать категории для дайджеста
отключать теги для дайджеста
Что ещё важнее, настройка пользователя в разделе Электронная почта | Сводка активности гласит: «Когда я не захожу на сайт, отправлять мне сводку популярных тем и ответов по электронной почте». Да или нет, точка. Никакой связи с отслеживанием писем не указано.
Исходя из этих настроек, пользователи должны ожидать, что параметр «Сводка активности» будет применяться именно так, как описано, и независимо.
Хорошо бы исключить уведомленные темы из сводки-дайджеста, но я бы считал это скорее приятным дополнением. Достаточно просто сделать так, чтобы дайджест не учитывал уведомления об отслеживании писем — это привело бы систему в соответствие с ожиданиями.
Я, возможно, лезу не в своё дело, но из любопытства изучаю код на Github…
В разделе digest файла app/mailers/user_notifications.rb topics_for_digest ищутся на основе min_date, который учитывает user.last_emailed_at.
строка 227:
min_date = opts[:since] || user.last_emailed_at || user.last_seen_at || 1.month.ago
# Получаем некоторые темы и посты для отображения
digest_opts = {
limit: SiteSetting.digest_topics + SiteSetting.digest_other_topics,
top_order: true,
}
topics_for_digest = Topic.for_digest(user, min_date, digest_opts).to_a
if topics_for_digest.empty? && !user.user_option.try(:include_tl0_in_digests)
# Ищем темы от новых пользователей, которым уже хотя бы 24 часа
topics_for_digest =
Topic
.for_digest(user, min_date, digest_opts.merge(include_tl0: true))
.where("topics.created_at < ?", 24.hours.ago)
.to_a
end
(Редактирование: Я вижу, что last_emailed_at также упоминается в файлах app/jobs/scheduled/enqueue_digest_emails.rb и spec/jobs/enqueue_digest_emails_spec.rb, среди прочего.)
Это заставляет меня подумать, что дайджест просто не генерируется для пользователей, у которых user.last_emailed_at слишком свежий.
Мне не удалось выяснить, какие именно письма учитываются в last_emailed_at. Очевидно, сюда входят уведомления на основе настроек отслеживания, но что насчёт личных сообщений и прочего?
Разве дайджест должен учитывать только user.last_seen_at?
В настоящее время, когда включен режим рассылки по электронной почте — по крайней мере, на уровне предпочтений пользователя (см. следующий пост) — интерфейс четко указывает, что настройки дайджеста переопределяются.
Поэтому, возможно, стоит добавить только опцию «всегда отправлять», например:
Сводка активности:
[ ] Всегда отправлять мне дайджест по электронной почте
[ ] Отправлять дайджест по электронной почте только в том случае, если я не заходил сюда
(Выпадающий список): каждые 30 минут | ежечасно | ежедневно | еженедельно | ежемесячно | каждые шесть месяцев
Но я бы рассматривал опцию «всегда» как желательную, но не обязательную. Достаточно сделать дайджест независимым от других писем, чтобы он работал как положено.
(Кстати: если бы у меня был большой форум, я бы хотел, чтобы администратор мог настраивать доступные временные интервалы. Слишком много людей, выбирающих «всегда отправлять… каждые 30 минут», могли бы привести к значительным расходам на рассылку.)
Это вторично по отношению к моей сообщённой проблеме, но связано с беспокойством Сэма относительно режима почтового списка и сводки активности…
Интересно, что когда администратор включает «режим почтового списка по умолчанию» и «отключить режим почтового списка» (Сценарий A), неясно, что происходит. Пользователь не видит никакой информации о режиме почтового списка и, по-видимому, всё ещё может включить сводку активности и другие уведомления по электронной почте.
Два параметра администратора, похоже, независимы, хотя, возможно, между ними должна быть зависимость… переопределяет ли настройка «запретить пользователям включать режим почтового списка» настройку «режим почтового списка по умолчанию»?
Однако, если администратор оставляет опцию «отключить режим почтового списка» снятой, пользователь видит, что для него по умолчанию включён «режим почтового списка». Это кажется достаточно понятным.
Похоже, в Сценарии A чего-то не хватает, что указывало бы на то, действительно ли активен режим почтового списка. (Если только я сам чего-то не упускаю.)
Спасибо за обновление, Сэм. Жаль, что у меня нет навыков, чтобы разработать и предложить PR.
Учитывая количество исправлений и улучшений в примечаниях к выпуску, можно только представить, как выглядит очередь задач. Но я надеюсь, что это заслуживает внимания — у пользователей нет причин подозревать, что сводка не будет надежно информировать их об обновлениях.
Привет, @ToddZ — приношу извинения за молчание с моей стороны. Спасибо, что подняли этот вопрос.
Я согласен с @sam: получение уведомления не должно считаться посещением, которое мешает вам получать письмо с итогами активности. Я поработаю с командой, чтобы исправить это, и сообщу, как только мы решим эту проблему. Однако на данный момент у меня нет точных сроков, которые можно было бы назвать.
