Я являюсь одновременно администратором и участником сайтов Fedora Discourse. Я хотел бы иметь возможность разделять эти роли. Я знаю, что есть «цвет сотрудников» для официальных сообщений, но я имею в виду скорее с моей стороны. Вместо того чтобы везде были административные ключи и кнопки, когда я в системе, я хотел бы иметь переключатель в меню, который включал бы и выключал режим администратора.
18 лайков
7 лайков
У нас также есть
Оба этих плагина позволяют маскировать вашу личность под сотрудника. То есть вы можете публиковать сообщения от имени более «официального» аккаунта, который нельзя явно связать с вами как с конкретным человеком.
Однако, думаю, это не совсем то, что вы имеете в виду? Вы хотите, чтобы Discourse выглядел и ощущался как для обычных пользователей, а затем «включал режим суперпользователя», чтобы открыть весь дополнительный функционал, доступный только администраторам?
Полагаю, это было бы довольно сложно реализовать… но это было бы здорово! Много лет назад (до того, как я присоединился к команде) я создал этот компонент для своего собственного форума с самохостингом. Он основан на схожей идее (делает права обычного пользователя и администратора очевидными), но ограничен одним очень конкретным случаем:
Если на вашем сайте есть и другие узкоспециализированные случаи, которые часто вызывают путаницу, возможно, создать похожие компоненты тем, которые будут выводить предупреждения перед выполнением действий, доступных только администраторам.
8 лайков
Да, именно так. Думаю, это отчасти связано с годами работы системным администратором, когда на практике был усвоен принцип «минимально необходимых привилегий». (rm -rf от имени root в неправильном месте на продакшн-системе — это своего рода обряд посвящения!)
7 лайков
Это тоже интересно для меня. Мой текущий обходной путь — использовать и Chrome, и Edge. В Chrome у меня есть административная учётная запись, а в Edge я вхожу под административной учётной записью и имитирую учётную запись пользователя с истёкшим сроком действия email. Имитация нужна только потому, что я не хочу общаться с IT-отделом.
В вашей ситуации можно создать второй вход и использовать один браузер для администратора, а другой — для пользователя. Это не идеально, но для меня этого вполне достаточно.
6 лайков
Вот хороший пример того, где это было бы полезно:
Я не хочу случайно нарушать правила маркировки. (Могут ли модераторы без прав администратора тоже случайно это сделать? Я даже не могу это легко проверить.)
Я мог бы создать отдельную учётную запись администратора и понизить свою основную до обычного пользователя, но боюсь, что пропущу важные уведомления о флагах и сообщения.
4 лайка
Это функция, которую обрабатывает сам браузер, см.
6 лайков
Это выглядит так, будто можно просто переключить весь профиль браузера? Это вроде не помогает, если только вы не создадите совершенно отдельную учётную запись пользователя Discourse для административных задач.
Или я что-то упускаю. Например, ваш аккаунт, @codinghorror, указан как администратор здесь, так что, я предполагаю, если вы не делаете чего-то, что я полностью неправильно понял, вы сейчас работаете в режиме администратора. Но вы также действуете как обычный пользователь сайта. Не сталкиваетесь ли вы с ситуациями, когда (например) случайно создаёте посты, не соответствующие настроенным правилам тегов? (Я сам такое делал не раз случайно…)
3 лайка
Не совсем — часть работы администратора заключается в понимании своей ответственности и границ, которые необходимо соблюдать. Если вы не можете этого сделать, вам не следует иметь привилегии администратора.
Однако я также понимаю тех, кто хочет быть максимально осторожным, и рекомендую им использовать две учётные записи, входя в систему как обычный пользователь, когда нужно быть абсолютно уверенным. С помощью встроенной поддержки профилей браузера это делается очень легко.
8 лайков
Ну, это во многом то же самое, что и постоянная работа от имени root в системе Linux. Речь не только о соблюдении границ, но и о том, чтобы случайно не переступить их, не осознав, что они существуют. Некоторые действия, например, переход в настройки, не могут произойти случайно, но, похоже, существует множество мелких ситуаций, когда администратор обходит конфигурацию без какого-либо уведомления о том, что что-то было обойдено.
Как я уже говорил выше, наличие второй учётной записи — не лучшее решение, поскольку я буду видеть уведомления от этой учётной записи крайне редко.
7 лайков
Понимаю обеспокоенность, но на практике это не является большой проблемой, по крайней мере за 10 лет работы над этим проектом.
(Также имейте в виду, что мы автоматически отзываем доступ сотрудников и требуем повторной проверки электронной почты для сотрудников, которые давно отсутствовали, что, на мой взгляд, автоматически устраняет большинство таких проблем)
1 лайк
Привет, Мэтт!
Хочу добавить немного контекста: возможность для администратора действовать как обычный пользователь добавила бы дополнительный уровень сложности ко всей логике авторизации, связанной с администраторами.
Хотя эта логика в основном централизована в файлах guardian.rb и /lib/guardian/*.rb, сложность и риск появления ошибок при внедрении такого изменения были бы очень велики. Необходимость этой функции должна значительно перевешивать эти риски, но в данном случае этого не происходит, учитывая существующие альтернативы.
1 лайк
Возможно ли рассмотреть более точечную «защиту» для некоторых действий, которые могут быть выполнены случайно? Например, настройку: «Персонал должен соблюдать правила категоризации по тегам». Честно говоря, одной этой настройки хватило бы, чтобы решить большинство практических проблем, с которыми я сталкиваюсь.
Или… странно, что другие ограничения, например на длину поста, всё ещё действуют даже для администраторов. Возможно, в данном случае стоит просто сделать это стандартным поведением, а не добавлять отдельную опцию?
Добавление длины поста потребовало бы изменения всей базы данных. В базе данных есть максимальное количество символов, которое можно хранить в одном поле.
Мне это кажется нелогичным, но, возможно, я что-то упускаю. Имею в виду:
- Если я администратор и пытаюсь создать пост короче, чем
min post length, я получаю обычное сообщение об ошибке и не могу продолжить. - Если я администратор и пытаюсь создать пост без тегов в категории, где они обязательны, система просто позволяет мне это сделать.
Что именно хранится в базе данных в данном случае?
4 лайка
О, извините, я имел в виду только длину поста/заголовка — в самом поле базы данных, где он хранится, есть максимальный размер. Аналогичное ограничение действует и для заголовка поста: для этого поля в базе данных выделено максимальное количество символов.
Так что, если администратор решит: «Эй, я хочу пост на 900 000 символов» или «Эй, я хочу пост с заголовком на 500 символов», это невозможно без изменения базы данных.
Это действительно технический нюанс, но раз вы упомянули длину поста, я подумал об этом.
1 лайк
А, ладно. Да, это полная противоположность той проблеме, которая меня беспокоит 
Я полагаю, что OP подразумевал работу в режиме обычного пользователя большую часть времени. Для меня тоже важно ощущать себя простым пользователем:
- меньше кнопок
- отсутствие доступа к действиям модератора/администратора
- использование типичных сценариев обычного пользователя
После обновлений или настроек я хотел бы взаимодействовать с форумом так, как его видит обычный пользователь, чтобы избежать недопонимания.
Для моего сообщества режим администратора необходим только для обновлений или тестов плагинов и интерфейса. Постоянно быть модератором тоже не нужно. Кроме того, я считаю, что для таких людей, как я, временное переключение в режим администратора лучше, чем наличие двух аккаунтов.
OP писал о sudo. Это почти то же самое, но наоборот. Обычно я временно переключаюсь на анонимный режим, чтобы проверить какие-то сценарии. В любом случае было бы здорово иметь легкую опцию для активации режима администратора, например «имперсонация» (impersonate), под специальным обычным аккаунтом.
7 лайков
Это напомнило мне о случае, который произошёл несколько дней назад. Я занимаюсь миграцией форума.
Я предоставил права администратора администратору старого форума.
Он является пользователем Discourse на двух других форумах и также модератором. Поэтому он немного знаком с интерфейсом и навигацией в Discourse.
Из своей учётной записи администратора (я не писал ему никаких инструкций, я дал ему самому разобраться) он сказал мне, что был удивлён, увидев, что может просматривать личные сообщения других людей; он случайно нажал на публичную страницу профиля и увидел список личных сообщений, что его удивило.
Он сказал, что вдруг подумал: «Ох, кажется, я оказался там, где не должен быть» (в смысле: ему не следует находиться здесь, если у него нет административных или модераторских целей в данный момент).
Он даже не подозревал, что может получить доступ к этим сообщениям через интерфейс так же легко, как вы получаете доступ к своим собственным личным сообщениям со своей страницы профиля.
Со мной это тоже произошло несколько недель назад, несмотря на то, что я являюсь администратором двух форумов на Discourse с 2018 года… 
По моему мнению, на вкладке «Личные сообщения» на публичной странице профиля пользователя у администратора должен быть значок или какое-либо предупреждение о том, что нажатие на неё является административным или модераторским действием, так как вы увидите то, что должно оставаться «частным» (по мнению 99% пользователей, во всяком случае). 
6 лайков
Итак… я подумал об этом и теперь меньше убеждён, что это такое уж большое изменение. Конечно, логика разбросана по разным местам, но ведь в итоге всё сводится к проверке is_admin или is_staff?
Режим «sudo» потребовал бы лишь добавления переключателя staff_mode, а функции is_staff и is_admin могли бы проверять состояние этого переключателя в сочетании с флагом user.admin или user.staff. (Конечно, активация переключателя требовала бы специальной проверки, которая смотрела бы исключительно на значения user.admin или user.staff.)
1 лайк