Извините, старый пост, но почему бы вам не разместить вашу тему в репозитории GitHub? Предоставьте команде по дизайну и UX доступ для обновления темы в GitHub.
В Discourse теперь можно настроить темы на автоматическое обновление при пересборке.
Теперь вашим администраторам нужно будет только выполнить пересборку, чтобы внести любые изменения, сделанные командой по дизайну и UX, а последней вообще не потребуется доступ к администрированию.
Короткое замечание:
При реализации механизмов контроля доступа, как правило, проверки RBAC должны выполняться на стороне сервера.
Код RBAC в клиентском JavaScript может быть изменен клиентом.
Это означает, что при определении основных разрешений RBAC для сотрудников, администраторов и модераторов это следует делать (в общем случае) в Rails, а не в JavaScript.
Кстати, именно так Discourse теперь реализует RBAC, используя то, что в Discourse называют «guardian» — класс Ruby под названием class Guardian, вот здесь:
Если разработчик планирует добавлять проверки RBAC в JavaScript-код, вызывая API Discourse, имейте в виду, что такой код может быть скомпрометирован, поскольку код, выполняющийся в браузере, может быть изменен.
Моя рекомендация — убедиться, что весь основной код RBAC выполняется на стороне сервера, и не пытаться обходить это правило с помощью клиентского JavaScript.
Также существуют уровень доверия 4 и модераторы категорий в Discourse 2.5 и новее.
У меня похожий случай: я управляю небольшим некоммерческим сообществом, где один из наших пользователей отвечает за поддержку тем и дизайна.
Я не хочу предоставлять никому, кроме себя и моего со-владельца, доступ к личным данным пользователей (например, адресам электронной почты), но у меня есть 4 модератора.
Чтобы дизайнер мог работать, я создал копию сайта без контента, где он является администратором, а затем вручную копирую темы и компоненты. Однако это неудобно, поскольку для проверки некоторых изменений требуется наличие контента.
Почему бы не добавить контент на тестовый / стендовый сайт? Это была бы типичная рекомендация.
Итак, пусть разработчик работает на тестовом сайте и выгружает темы в GitHub. Но вам всё равно придётся обновлять их самостоятельно. Можно попытаться реализовать обновление через API и каким-то образом дать разработчику возможность запускать его.
Я работаю над инструментом, который может помочь в этом.
У нас возникла точно такая же потребность. Не удалось ли кому-нибудь решить эту проблему?
Не знаю, полезно ли это в данной ситуации, но если вам просто нужно какое-то содержимое, существует задача populate в Rake:
Спасибо, но, к сожалению, это пока не очень полезно.
Если вы не доверяете дизайнеру доступ к своим данным, какое решение вы могли бы представить?
Может быть, вы могли бы предоставить им только ключ API, который позволил бы им использовать discourse_cli для загрузки темы, а затем отключить его после завершения работы?
У дизайнера абсолютно нет причин иметь доступ к 100 000 пользователей, ха-ха. Кроме того, это нарушало бы правила GDPR. Возможно ли выдать CLI-ключ только для обновлений темы?
Прошу прощения! Думаю, вы правы.
Теперь, в отличие от того времени, когда была создана эта тема (что, видимо, было в моей голове, когда я писал свой ответ), у нас есть детализированные API-ключи. Добавить новую область действия специально для управления темами должно быть несложно.
Стоит создать новую тему в #feature с запросом на область действия API-ключа для разработчика тем. Это кажется отличной идеей.
Нет, это не так. Это может противоречить правилам этого сайта, но они могут и должны измениться.
Было бы хорошо, если бы @AV_C мог, возможно, опубликовать ссылку на это требование. Хотя я полностью понимаю, почему клиент может захотеть ограничить доступ к базе пользователей и даже к приватным категориям по различным причинам. Полные права администратора позволяют получать доступ к email-адресам при регистрации пользователей, а приватные категории могут содержать другую конфиденциальную информацию в зависимости от сценария использования клиента.
Я считаю, что у @pfaffman есть отличная идея обеспечить покрытие такого рода пробелов через ограниченный API администратора. После завершения работы дизайнера ключ можно будет отозвать до момента, пока он снова не понадобится.
Это также соответствует идее Джей не отображать пользователя как администратора на странице «О нас».