Db:seed_fu не работает в 002_groups.rb при обновлении: Ошибка валидации: Имя уже занято

Внести вклад Ошибка
1

Возникла проблема при обновлении с версии v2026.3.0-latest. Задача rake db:seed_fu завершается ошибкой при выполнении файла 002_groups.rb со следующим сообщением:

ActiveRecord::RecordInvalid: Validation failed: Name has already been taken. (ActiveRecord::RecordInvalid)

Сбой происходит именно в тот момент, когда скрипт инициализации пытается создать новые системные группы (ID 4: anonymous и ID 5: logged_in_users).

Это подтверждено через консоль Rails. Ручная проверка завершается ошибкой валидации, но игнорирование валидации позволяет записать запись в базу данных без каких-либо проблем:

# Это завершается ошибкой «Name has already been taken»
g = Group.new(id: 4, name: «anonymous», automatic: true)
g.valid?

# Это работает корректно, что доказывает отсутствие реального конфликта
g.save(validate: false)

Мне удалось преодолеть это препятствие, вручную создав эти новые системные группы:

ActiveRecord::Base.transaction do
  g4 = Group.new(id: 4, name: "anonymous", automatic: true)
  g4.save(validate: false)

  g5 = Group.new(id: 5, name: "logged_in_users", automatic: true)
  g5.save(validate: false)
end

Теперь при запуске rake db:seed_fu задача выполняется без ошибок.

2 лайка
2

Куда исчезла кнопка «Мне тоже!»?

Это происходит, когда у вас уже существует группа или пользователь (!!!) с именем anonymous.

У нас есть множество форумов, где anonymous использовалось как имя пользователя после импорта.

В коммите упоминается:

Этот PR вводит две новые автоматические группы: anonymous_users и logged_in_users

но, похоже, группа в итоге была названа anonymous без _users.

Это досадно, потому что:

  • anonymous неясно: это группа пользователей или отдельный пользователь;
  • риск конфликта с существующей группой или пользователем значительно выше без _users.

Предлагаемые решения:

  1. Назвать группу anonymous_users, как и планировалось изначально; это больше соответствует logged_in_users и значительно снижает риск конфликтов.
  2. Как минимум обнаруживать конфликт и переименовывать существующего пользователя или группу вместо того, чтобы выдавать ошибку.
2 лайка
5

Изучаю этот вопрос.

Существует миграция для обработки такого конфликта имён, поэтому непонятно, почему она не сработала в случае OP:

Вы запускаете это отдельно до выполнения миграций?

6

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

7

Хм, ладно, это довольно раздражает… Сейчас создам PR для этого:

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

1 лайк
8

Отлично, это должно сработать. Кроме того, это исправляет некоторые проблемы с логикой предстоящих изменений для Granular group-based permissions for anonymous and logged in users :

https://github.com/discourse/discourse/pull/40435

2 лайка
12

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

2 лайка
13

Хорошо, я объединил PR, теперь конфликты имён должны быть устранены.

1 лайк
14

Это отличная новость!

Не могли бы вы также портировать исправление обратно в ветку 2026.5?