Заметки о влиянии изменения автоматических заголовков групп (TL и др.) через тексты сайта

[ToddZ]

Не знаю, заинтересует ли это кого-то, кроме @haydenjames, но я решил разобраться с второстепенным запросом в теме, где в целом уже всё решено, касательно групповых личных ящиков:

@haydenjames

Можно ли переименовать заголовок этих групп уровней доверия? Например, Trust Level 2 вместо trust_level_2?

…речь идёт о:

Вот что мне удалось понять…

Поскольку названия полей для «имён» пользователей и групп пересекаются и вызывают путаницу, я классифицирую их здесь как @-никнейм и полное имя. В никнеймах пробелы не допускаются, а в полных именах — да.

	@-никнейм	полное имя
пользователи	поле Username (Agent_007)	поле Name (James Bond)
группы, созданные администратором	поле Name (poke_pros)	поле Full Name (Pokemon Pros)
автоматические группы	выводится из имени текста сайта (trust_level_2)	имя текста сайта (trust_level_2)

Автоматические группы, например модераторы, уровни доверия и т. д., не имеют редактируемых полей «никнейм» и «полное имя».

Однако у автоматических групп есть имена текста сайта, которые можно редактировать:

Это меняет отображение заголовка группы на страницах «Группы».
Возможно, вам это пригодится…

…но это не влияет на Ящик, где для всех групп, автоматических или нет, отображается именно никнейм:

Не знаю, сколько работы потребуется, чтобы отображать здесь вместо никнейма поля полного имени, но если это небольшая доработка, это было бы приятным штрихом.

РЕДАКТИРОВАНИЕ: Осознаю, что хотя использование полного имени в ящике могло бы выглядеть красиво, логично, что там отображается именно никнейм, который используется для @-упоминаний.

Если вы хотите переименовать автоматическую группу и присвоить ей соответствующий новый никнейм, то новое название группы в текстах сайта должно быть допустимым для этой цели, то есть не содержать пробелов.

[JammyDodger]

Я думаю, что изменение текста сайта (например) groups.default_names.trust_level_4 действительно приводит к его обновлению и в других местах. Полагаю, это естественным образом является частью фоновой ежедневной задачи, но если у вас есть доступ к странице /sidekiq/scheduler, вы можете вручную запустить задачу jobs::EnsureDbConsistency оттуда, чтобы ускорить процесс.

---

Ах да, но пробелы действительно станут проблемой, так как упоминания и имена не могут их обрабатывать.

[ToddZ]

Что ж, это интересно..! Ответ JammyDodger привёл меня к новым экспериментам.

Переименование автоматических групп через настройку текста сайта вызвало путаницу, когда речь шла о пробелах, поскольку пробелы мешают использовать их в качестве обработчиков (handles). Если текущий производный обработчик не переопределяется настройкой текста сайта из-за наличия пробелов, он остаётся без изменений. Я обнаружил это, когда временно застрял заголовок группы без пробелов в качестве обработчика.

Осознание влияния пробелов и использование задания Sidekiq EnsureDbConsistency прояснило ситуацию.

Я изменю своё предложение в исходном сообщении относительно отображения правильных имён во входящих сообщениях, так как это несовместимо с использованием @-упоминаний, которые требуют обработчик.

Детальные шаги тестирования

1. Начиная с описанной выше ситуации, я подтвердил, что задание Sidekiq было выполнено, и запустил его снова. Действительно, оно не уловило изменения имён для входящих сообщений — из-за пробелов, как вы и объяснили.

2. Изменил текст сайта для TL2 с “Trust Level 2” на “Sophomores” и запустил задание Sidekiq:

Теперь изменение имени распространилось как на заголовок группы, так и на обработчик во входящих сообщениях — потому что пробелов нет:

3. Вернул имя текста сайта обратно на “Trust Level 2” и запустил задание Sidekiq. Обработчик, назначенный в предыдущей операции, теперь застрял там — очевидно, потому что пробелы в этом заголовке текста сайта делают его недопустимым обработчиком:

4. Вернул текст сайта к значению по умолчанию “trust_level_2” и не запускал задание Sidekiq. Это обновило заголовок, но не обработчик:

5. Запустил задание Sidekiq, которое очистило изменённый обработчик, сбросив его на значение по умолчанию во входящих сообщениях:

[JammyDodger]

@ToddZ

Что ж, это интересно..! Первоначальный ответ JammyDodger — теперь удалённый — подтолкнул меня к новым экспериментам.

Извините за это. Иногда я понимаю, что вмешался слишком рано, и испытываю «синдром автора сообщения». Верну его для истории.

[ToddZ]

Быстрый ввод был очень полезен!