Соблюдайте настройки видимости всех автоматических групп

[mdoggydog]

(Запрос функции от одного человека — это отчёт об ошибке для другого… )

Страница индекса «Группы» (например, /groups или /g) должна учитывать настройки видимости автоматических групп и отображать их соответствующим образом. Это работает для группы Moderators, но не для остальных. Причина — жёстко заданное исключение в GroupsController.index(), из-за которого другие автоматические группы никогда не появляются на странице индекса для пользователей, не являющихся сотрудниками, независимо от настроек видимости.

Такое исключительное поведение проблематично как минимум по двум причинам:

1. Если администратор хочет сделать автоматические группы доступными для индексации обычными пользователями, это ему не позволяет.
2. Разрыв между настройкой видимости и фактической видимостью опасным образом запутывает. В частности, создаётся впечатление, что настройка игнорируется или не имеет значения для автоматических групп (например, «Ну ладно, похоже, автоматические группы всегда доступны только сотрудникам, что бы я ни настраивал…»), хотя на самом деле настройка продолжает контролировать доступ к страницам конкретных групп (например, /g/trust_level_0) и их спискам участников.

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

Я предлагаю просто удалить 6 строк кода из app/controllers/groups_controller.rb, реализующих это поведение.

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

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

К сведению, эта тема является продолжением обсуждения:

How does visibility of automatic groups work?

I’m a bit confused as to how the visibility of automatic groups works. At this point, I am just talking about the /groups directory. Here is what I am seeing in a pretty fresh install of 2.7.0.beta4: If an user with admin or moderator bits looks at /groups, they see all 8 automatic groups (admins, moderators, staff, trust_level_[0-4]). If a non-admin, non-moderator user (no matter the trust_level) looks at /groups, they see only the moderators group. But, all of these groups have the same, …

[simon]

@mdoggydog

Разрыв между настройкой видимости и фактической видимостью опасно запутывает.

Как обычный пользователь, я предпочитаю очищенный вид; группы по уровню доверия кажутся мне нерелевантными. Но я также согласен, что текущий порядок работы кажется странным. Особенно учитывая следующее:

@mdoggydog

хотя настройка по-прежнему контролирует доступ к страницам конкретных групп (например, /g/trust_level_0) и к их спискам участников.

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

@mdoggydog

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

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

[RGJ (Richard - Communiteq)]

Так что не решается ли это легко следующим образом:

• сделать «Автоматические группы» доступными в выпадающем списке фильтров для неадминистраторов?
• установить фильтр по умолчанию (как для администраторов, так и для обычных пользователей) так, чтобы он исключал автоматические группы;
• убедиться, что /g/trust_level_0?asc=true использует ту же логику авторизации, что и /g?type=automatic (сейчас первый работает, а второй выдаёт сообщение «Нет видимых групп»).

Дополнительная просьба: если перейти к /g через /admin, то панели меню администратора внезапно исчезают. Это раздражает. Как насчёт того, чтобы добавить эти панели на эту страницу, если к /g обращается администратор?

[Moin]

@RGJ

Дополнительная просьба: если зайти в /g через /admin, то внезапно исчезают панели меню администратора

Обсуждение этой проблемы есть в теме #ux: Groups Tab in Admin Inconsistent With Other Tabs

[mdoggydog]

@simon

Для меня это имеет смысл. Возможно, потребуется проявить осторожность, чтобы ограничение видимости группы уровня доверия ничего не сломало.

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

@RGJ

Разве это не можно легко решить:

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

Действительно! Я не заметил, что опция «автоматические» недоступна в выпадающем списке фильтров для неперсонала. (Она исключается тем же блоком кода из шести строк, который скрывает автоматические группы — значит, удаление этого кода решит и эту проблему.)

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

[tobiaseigen]

@mdoggydog

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

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

@mdoggydog

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

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

@mdoggydog

Я предлагаю просто удалить 6 строк кода из app/controllers/groups_controller.rb, которые реализуют это поведение.

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

Эти два пункта кажутся разумными. Однако прежде чем мы это сделаем, есть ли какие-либо непредвиденные последствия изменения настроек видимости для автоматических групп?

@RGJ

Так не решается ли это легко путём:

• предоставления «Автоматических групп» в выпадающем списке фильтров для неадминистраторов?
• установки фильтра по умолчанию (как для администраторов, так и для обычных пользователей) так, чтобы он исключал автоматические группы?
• обеспечения того, что /g/trust_level_0?asc=true использует ту же логику авторизации, что и /g?type=automatic (сейчас первый работает, а второй выводит сообщение «Нет видимых групп».)

Это выглядит как хороший список задач. Спасибо, что сформулировали это таким образом.

[mdoggydog]

@tobiaseigen

@mdoggydog

• Если администратор хочет индексировать автоматические группы для не-сотрудников, это мешает ему это сделать.

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

В приведённом выше цитировании я конкретно имею в виду «показывать автоматические группы на странице индекса /g, когда её просматривают не-сотрудники». Независимо от настроек фильтра, автоматические группы (кроме «Модераторов») в настоящее время не разрешено отображать на странице индекса /g для не-сотрудников.

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

@tobiaseigen

@mdoggydog

Я предлагаю просто удалить 6 строк кода из app/controllers/groups_controller.rb, которые реализуют это поведение.

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

Эти два момента кажутся разумными. Однако прежде чем мы это сделаем, есть ли какие-либо непредвиденные последствия изменения настроек видимости для автоматических групп?

Обратите внимание, что я отредактировал своё предложение по умолчанию по упрощению интерфейса до вашего сообщения; вы процитировали исходную версию. Исправленный/текущий текст моего первого сообщения (без зачёркиваний для краткости) выглядит так:

@mdoggydog

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

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

[tobiaseigen]

В настоящее время на новом сайте список пользователей выглядит следующим образом.

Если кратко своими словами, запрос состоит в том, чтобы изменить каталог групп по адресу /g следующим образом:

1. также отображать фильтр «Автоматические группы» для участников;
2. отображать все автоматические группы участникам при выборе фильтра;
3. исключить автоматические группы из вида по умолчанию по адресу /g.

Мне кажется, что пункт (3) должен применяться ко всем пользователям, а не только к участникам. Одна из наших целей — обеспечить администраторам и модераторам максимально похожий на опыт участников интерфейс, чтобы снизить путаницу.

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

Для администратора:

Для участника:

[mdoggydog]

@Тобиас Айн

Если перефразировать своими словами, то запрос заключается в следующем изменении каталога групп по адресу /g:

1. также отображать фильтр «Автоматические группы» для участников
2. отображать все автоматические группы участникам при выборе фильтра
3. исключить автоматические группы из представления по умолчанию на странице /g

Я бы переформулировал это с точки зрения необходимых изменений и немного пересмотрел приоритеты:
A. прекратить исключение автоматических групп из индекса для пользователей, не являющихся сотрудниками
B. прекратить исключение фильтра «Автоматические группы» из выпадающего меню для пользователей, не являющихся сотрудниками
C. добавить в выпадающее меню фильтр «Неавтоматические группы» для всех пользователей
D. включить фильтр «Неавтоматические группы» по умолчанию на странице /g

Моя формулировка пунктов C и D по сравнению с пунктом 3 не случайна: я считаю, что интерфейс должен быть максимально прозрачным в отношении применяемой фильтрации. Если фильтр не выбран, интерфейс должен отображать нефильтрованный вид, то есть показывать все группы, видимые/доступные пользователю.

Пункт 3 можно интерпретировать как «когда фильтр не выбран, тихо применять фильтр non_automatic», но я считаю, что это всё равно будет запутанно. Если фильтр не выбран, то и фильтрация не должна применяться. И наоборот, если фильтрация применяется, она должна быть названа и очевидна для пользователя.

Если копнуть глубже в детали: часть проблемы выбора фильтра связана с тем, как подсказка «Фильтр по типу группы» была втиснута в метку элемента меню «Фильтр не выбран». Я считаю, что в конечном итоге будет понятнее, если элемент «Фильтр не выбран» будет называться «Все группы». Затем добавьте дополнительный элемент «Неавтоматические группы», и вы сможете сделать любой из них элементом по умолчанию. Таким образом, (a) будет понятно, когда пользователь видит отфильтрованный список, и (b) будет понятно, как переключиться на нефильтрованный вид.

Если бы это зависело от меня, я бы назвал элементы меню фильтрации так:

• Все группы
• Группы, в которых я состою (так как Мои группы неоднозначно.)
• Группы, которыми я владею
• Публичные группы
• Приватные группы (так как Закрытые звучит как «закрыты» или «больше не используются».)
• Автоматические группы
• Неавтоматические группы

Кроме того, я бы изменил строку подсказки в текстовом поле с «Все группы» на «фильтр по названию группы».

И… я бы поменял местами выпадающее меню и текстовое поле!

[tobiaseigen]

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

@mdoggydog

Если бы это зависело от меня, я бы назвал пункты меню фильтрации так:

• Все группы
• Группы, в которых я состою (потому что Мои группы неоднозначно.)
• Группы, которыми я владею
• Публичные группы
• Закрытые группы (потому что Закрытые звучит как «закрыто» или «больше не используется».)
• Автоматические группы
• Неавтоматические группы

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

[almereyda (jon r)]

Только что зашел с той же мыслью: было бы лучше, если бы по умолчанию отображалось то, что сейчас называют «Публичные + Закрытые группы», и при этом появилась бы такая опция. А также убрать двусмысленность вокруг «Мои группы», которую можно понять как «Группы, которыми я владею», и «Закрытые группы», которые могут звучать так, будто они больше не активны, — это тоже кажется разумным.

@mdoggydog

• Автоматические группы
• Неавтоматические группы

Звучит это очень похоже на:

• Системные группы
• Группы пользователей, «Публичные и частные группы» или просто «Группы»

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

Также было бы полезно давать человеко-читаемые псевдонимы для «Автоматических/Системных групп». Например, в некоторых языках предпочитают заглавные буквы в начале, как в поле «Полное имя» в обычных группах. Кроме того, предоставление им опциональных, логичных текстов описания по умолчанию могло бы сделать их менее «техническими», если администратор сайта не решит объяснить их в описании через меню «Управление».

Возможно, также можно было бы добавить какое-то визуальное различие между «Автоматическими» и «Неавтоматическими» группами, например, иконку или лёгкую серую заливку их блоков, или что-то подобное.

[tobiaseigen]

Мне нравятся системные группы!

[simon]

“Автоматические” звучит так, будто речь идёт о деталях реализации — пользователи автоматически добавляются в группы. С точки зрения обычного пользователя это кажется не совсем логичным. Кроме того, это не совсем точно: пользователи не автоматически добавляются в группы сотрудников. Возможно, наиболее точное название для таких групп — «предварительно созданные группы», но это ужасное название.

Группы «Системные» звучат нормально, но как насчёт того, чтобы разделить автоматические группы на «Уровни доверия» и «Сотрудники»? Фильтр типов групп мог бы выглядеть так:

• Мои группы
• Группы, которыми я владею
• Публичные группы
• Закрытые группы
• Уровни доверия
• Сотрудники

При необходимости можно добавить настройку сайта trust level groups public, которая определяла бы, отображаются ли группы уровней доверия на странице групп.

[tobiaseigen]

Отделить сотрудников сайта — отличная идея. Люди, возможно, по достоинству оценят возможность увидеть здесь список модераторов и администраторов. В противном случае им нужно знать, что нужно перейти на страницу /about.

[mdoggydog]

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

В любом случае, мой приоритет — обеспечить возможность использования настоящего нефильтрованного варианта «Все группы», и я лично предпочитаю простоту: сделать его фильтром по умолчанию для страницы /groups.