Детальные групповые права доступа для анонимных и авторизованных пользователей

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

Мы ещё не дошли до категорий, здесь ничего не изменилось.

Люди подавляющим большинством использовали TL0, чтобы означать «все вошедшие пользователи», потому что у нас не было лучшего способа это представить. Группа logged_in_users хотя бы совершенно ясно показывает, что она включает, и абсолютно ничего не мешает вам по-прежнему использовать TL0/TL1 и т. д. Единственной удаляемой группой является everyone.

Да, конечно, я делаю всё это просто «ради изменения» :+1: Пожалуйста, подумайте о своих словах, мы не привыкли делать здесь совершенно ненужные вещи без причины. Эта работа ведется уже несколько месяцев, и её направление не меняется.

3 лайка

Хорошо, возможно, я неправильно понял это изменение?

Если предложение заключается во введении:

  • anon
  • logged in

в качестве автоматических групп

это кажется разумным, и названия сами по себе понятны.

(На самом деле, мне это даже нравится! :+1:)

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

  • everyone

то это для меня не имеет смысла, ведь «everyone» является частью набора автоматических групп, представляющих уровни доступа, в который также входят:

  • trust_level_0
  • trust_leve_1

и т. д.

все они представляют пороги доступа, включая «everyone».

Группа «everyone» также известна как “trust_level_none”

это лаконичный способ обозначить публичный доступ.

Я понимаю, что вы не предлагаете удалять её для разрешений на категории на данный момент (:+1:), но лично мне было бы приятно увидеть обязательство сохранить эту автоматическую группу, так как для меня, по крайней мере, она имеет смысл.

И тогда почему бы не разрешить её использование в других местах так же, как любую другую автоматическую группу уровня доверия?

В противном случае, везде, где нужно выразить наличие «публичного доступа», вам придется добавлять две группы, что кажется бессмысленным усложнением?

Зачем вообще добавлять логику для «маскирования» «everyone»?

Возможно, альтернативным подходом было бы пересмотреть название «everyone», если существует лучшее имя, но сохранить его значение, функциональность и доступность по всей платформе, и тогда всем (кашля) будет хорошо?

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

Например, мы могли бы добавить в выборщик групп ярлык «Публичный», который одним действием выбирал бы обе группы: anonymous_users и logged_in_users. Тогда вы бы видели, что обе группы выбраны, и могли бы удалить любую из них. Это дало бы вам то удобство, о котором вы говорите, при этом сохраняя явность базовых разрешений. Мы предложили бы этот ярлык только там, где разрешено использование обеих групп.

Проблема с сохранением существующей группы everyone заключается в том, что она не всегда означала «публичный доступ». Для видимости категорий это так, но для большинства групповых настроек сайта она фактически означала «все вошедшие пользователи». Кроме того, как показано в обсуждении выше, разные темы и плагины интерпретируют её по-разному.

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

Создание универсальной группы с последовательным определением было бы возможно, но это всё равно потребовало бы миграции и аудита, которые мы проводим сейчас. Кроме того, эту группу пришлось бы запрещать везде, где не поддерживается анонимный доступ, иначе мы снова вернёмся к ситуации, когда «everyone» означает «только вошедшие пользователи» в этих местах. Я должен был добавить anonymous_users в значение disallowed_groups для множества настроек, где этого раньше не было, хотя ранее на этих настройках разрешалась группа everyone. Например:

Я бы предпочёл обеспечить это удобство на уровне интерфейса, используя две явные группы под капотом. Тогда мы получим последовательность для администраторов и разработчиков везде.

2 лайка