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

[martin (Martin Brennan)]

@merefield

так что некоторые люди запутались из-за того, что «все» означает только пользователей, вошедших в систему?

кто?!

«все» — это ведь все, правда? — очень ясно.

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

@merefield

так теперь полностью публичной категории нужно минимум две группы вместо одной — «вошедшие» и «анонимы»? это же глупо и не является улучшением?

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

@merefield

изменив просто TL0 на «вошедшие пользователи», вы теперь ломаете согласованность того, что каждый уровень безопасности является порогом. TL1 — это тоже порог и не совсем «одна группа». так что это значит, что нам нужна группа, названная «вошедшие пользователи, у которых как минимум уровень доверия 1»?!

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

@merefield

изменение ради изменения

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

[merefield (Robert)]

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

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

• anon
• logged in

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

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

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

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

• everyone

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

• trust_level_0
• trust_leve_1

и т. д.

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

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

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

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

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

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

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

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

[martin (Martin Brennan)]

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

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

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

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

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

@martin

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

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

[merefield (Robert)]

@martin

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

Все очень явно — на мой взгляд, это ненужная громоздкость, — но я ценю сохранённое удобство.

@martin

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

ИМХО, именно в этом и была/есть проблема, а не в исходной концепции категории «everyone».

Группа «everyone» и её использование в фундаментальной системе категорий существуют с… 2013 года?

work in progress, add fidelity to category group permissions (full, create posts, readonly)

Если система настроек разошлась и нарушила этот контракт, то это проблема работы над системой настроек, не так ли?

ИМХО, было бы здорово иметь RFC, чтобы сообщество могло предложить идеи по этому вопросу до того, как всё, похоже, идёт прямо к реализации.

Извините, если я что-то упустил…

[martin (Martin Brennan)]

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

Я не думаю, что аргумент 2013 года говорит нам о чём-либо, кроме того, как долго everyone существовала для разрешений категорий. С 2013 года в Discourse изменилось очень многое; например, многие настройки сайта раньше основывались на уровне доверия, а теперь — на группах. Никто не оспаривает, что в этом контексте это имеет смысл, и разрешения категорий не изменяются в рамках этой работы (по крайней мере, пока). Тот факт, что группа стара, не доказывает, что она имеет последовательное значение в остальной части Discourse, или что мы должны сохранять её навсегда.

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

Что касается точки об RFC, наличие общинного RFC перед внесением подобных изменений было бы медленным и чрезмерно обременительным, хотя отзывы приветствуются — для этого и предназначена предстоящая система изменений. Эта тема уже привела к нескольким улучшениям на основе примеров Мойна, и я признал случаи с темами/компонентами, которые изначально пропустил, и исправил их тоже.

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

В любом случае, у меня всё ещё много работы, отслеживаемой в The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions для этого, так что это займёт время, как и любые изменения, связанные с системой категорий, которая пока сохраняет everyone. Скорее всего, категории перейдут на систему, которую мы называем ACL (списки контроля доступа), которую уже использует Kanban: