Хочу выразить большую благодарность команде Discourse за добавление параметра bypass_bump! Это небольшой, но мощный инструмент — он позволяет скриптам и плагинам обновлять контент незаметно, не поднимая случайно старые темы в списке последних.
В нашем случае мы используем его для скриптов синхронизации ICS, что гарантирует, что темы поднимаются только при действительно значимых изменениях. Продуманное дополнение, которое помогает поддерживать чистоту на форумах сообщества и не нарушает опыт чтения — ещё раз спасибо!
Это не вводящий в заблуждение пост с похвалой, как мой предыдущий , потому что:
Discourse поддерживает флаг bypass_bump при редактировании поста; он предотвращает изменение даты поднятия темы, даже если вы редактируете последний (или единственный) пост. Это явно указано в опциях PostRevisor («- bypass_bump: не поднимать тему, даже если это последний пост»).
Тема с похвалой существует и прямо указывает на этот случай использования.
Исторически люди использовали обходной путь /t/{id}/reset-bump-date, поскольку эта опция не была широко известна/документирована в документации API, но она всё ещё доступна при необходимости.
Практическое замечание: при отправке PUT-запроса к /posts/{post_id}.json с новым raw и указанием bypass_bump=true, редактирование не отобразит тему в разделе /latest. (Официальная документация не описывает этот параметр явно, но он подключён на стороне сервера через PostRevisor.)
Я всё ещё не на 100% уверен в официальном статусе параметра bypass_bump в документации API — он нигде явно не упоминается.
Однако логи Python-скрипта синхронизации от Ethsim12 весьма показательны. Скрипт пытается вызвать API с параметром bypass_bump=true. Если бы этот параметр игнорировался или был некорректным, единственным механизмом, предотвращающим лишние обновления, стал бы добавленный ими запасной вариант — ручной вызов:
/t/{topic_id}/reset-bump-date
Таким образом, сам вывод логов становится убедительным доказательством. Если в логах видно, что темы обновляются, не появляясь в разделе /latest (и без необходимости использовать запасной вариант сброса), это довольно весомое подтверждение того, что bypass_bump активен и работает. Если же скрипт всегда прибегает к reset-bump-date, возможно, параметр не работает.
Иными словами, логи этого скрипта во многом помогают подтвердить, существует ли параметр bypass_bump и действительно ли Discourse его учитывает.
Спасибо за этот PR, moin — очень полезный контекст.
Для моего стороннего проекта (импортер ics_to_discourse.py) я как раз только что закоммитил изменение, чтобы остановить «шумное» обновление тем при календарных обновлениях:
Этот коммит добавляет логику для определения, является ли правка «существенной» (изменение времени, места и т. д.), и использует bypass_bump с запасным вариантом сброса даты обновления, чтобы обычные синхронизации ICS не поднимали темы без необходимости.
Так что этот PR идеально совпадает с тем, к чему я стремился — приятно видеть, что ядро движется в том же направлении. Как только поведение «не обновлять при правке» будет слито, я упрощу код и уберу дополнительный запасной вариант, но пока что этот коммит сохраняет всё в тишине на текущих установках Discourse.
, потому что: