Это похоже на тему #feature - Development, не уверен, в какой из них её следует разместить.
Есть ли способ изменить настройки сайта в плагине? Я на 99% уверен, что нет, но хочу просто подтвердить это.
Если нет, могу ли я предложить сделать их изменяемыми? Или, возможно, предоставить какой-либо API или способ «разблокировать» неизменяемость SiteSettings?
Один из возможных вариантов использования, который я рассматриваю, — это включение списка защищённых категорий в настройку, чтобы администратору было проще включать или исключать их.
Давайте начнём с этого и будем двигаться от общего к частному.
Сначала опишите вариант использования с точки зрения сообщества. Что они пытаются достичь и почему это сложно реализовать сейчас? Какую функцию вы представляете себе как решение их потребности более эффективно (независимо от способа реализации)?
Затем мы сможем на этой основе определить, лучше ли это реализовать в виде плагина или как функцию ядра.
После этого мы обсудим предложения по тому, как это можно реализовать.
Я ошибочно предположил, что раз настройки в TC неизменяемы, то они таковы и в плагинах на Ruby. Я попробую этот вариант.
Было бы неплохо сделать их редактируемыми в TC. Мой случай использования (который сейчас реализуется через плагин) заключается в том, что по умолчанию я беру все темы и посты во всех категориях и делаю с ними кое-что, но не хотел бы включать защищённые категории (например, через настройку excluded_categories).
Однако, если бы можно было добавлять защищённые категории в настройку, а затем получать к ним доступ, это было бы проще. Таким образом, администраторы могли бы включать некоторые защищённые категории, если захотят, удалив их из настройки.
С идеей @pfaffman это, вероятно, можно сделать, но не в TC.
Проблема в том, что я не знаю защищённые категории заранее.
Если вы вошли в систему как администратор, компонент темы может изменить siteSettings через API.
Тогда просто создайте настройку для компонента темы и добавьте туда эти категории? Вы не имеете в виду какую-то защищённую настройку site settings, о которой я не подумал, верно? То есть что-то вроде этого?
Не могли бы вы поделиться дополнительной информацией о вашем сообществе?
Вы являетесь основным пользователем этой функции, или в вашей команде есть другие люди, которым она нужна? Есть ли у вас документация для пользователей, описывающая рабочий процесс, зависящий от этой функции? Если да, то как она выглядит? Если нет, можете ли вы кратко описать, как она могла бы выглядеть?
Я считаю, что ответы на подобные вопросы помогут мне лучше понять контекст этого запроса.
@mcwumbly@pfaffman Хорошо, позвольте мне попытаться объяснить это как можно подробнее.
Я разрабатываю плагин, который берет темы и посты и публикует их в GitHub в виде файлов Markdown (как архив).
Однако я не хотел бы включать в это приватные категории (думаю, сейчас это правильный термин?), поскольку они «приватные».
Поэтому я ищу способ предварительно заполнить настройку списком приватных категорий, что нельзя определить в параметре default, поскольку я не знаю заранее, какие категории являются приватными.
Если это можно сделать, напрямую изменяя SiteSetting на Ruby, можно ли сделать то же самое с settings компонента темы? Я почти уверен, что последнее неизменяемо. Есть ли способ изменить это в компоненте темы?
Дело не совсем в сообществе. Я пытаюсь реализовать это таким образом (включая задачу по заполнению данных) по-своему. Это сохраняет каждую тему и пост в виде файла Markdown в репозитории.
Я до сих пор не понимаю, что для вас означает «приватный». Имеете ли вы в виду только категории, видимые всем, или анонимным пользователям? Или у вас есть другое определение?
Если вам нужны именно они, то ваш плагин может получать только их, возможно, через поиск, в который вы передаёте пользователя (или, возможно, вызывая «стража»), или просто проверяя разрешения.
Или, если «приватный» — это что-то субъективное, вы можете добавить соответствующую настройку.
И, вероятно, вы захотите выполнять это в задаче, которая запускается ежедневно или с другой периодичностью?
Если вы отправляете что-то на GitHub, я бы подумал, что вы захотите, чтобы Discourse делал это сам, вместо того чтобы возиться с тем, чтобы ваш браузер отправлял данные в Discourse? Не вижу, как и зачем вы стали бы делать это через компонент темы.
Я имею в виду категории вроде Staff и другие, доступ к которым ограничен группами. Думаю, это возможно с помощью плагина, но тогда настройки TC, наверное, нельзя будет изменять? То есть, это, вероятно, уже не относится к моему первоначальному вопросу.
Правильно ли я понимаю, что вы имеете в виду метод Category.where(...), чтобы получить эти «приватные» категории? Но что, если администратор захочет включить (некоторые из) них — нужно ли мне иметь настройку include categories, которая противодействует «приватным» категориям, определённым в коде? Не будет ли это контрпродуктивным?
Я всё ещё этого не понимаю. Да, вы можете добавить эти настройки в SiteSetting, и да, плагин может прочитать эту настройку и даже изменить её. Но зачем ему нужно менять настройку в сценарии, описанном выше?
Учитывая, как развивалась эта тема, перемещаю её в Development
Предположим, у меня есть 5 категорий: A, B, C, D и E. Допустим, B и C доступны только определённым группам. Чтобы предотвратить распространение частных тем из этих категорий при загрузке в репозиторий, B и C добавляются в настройку excluded_categories вместе с другими, например, Staff.
Теперь, если администратор сайта согласен на то, чтобы темы категории B были доступны для распространения, он может удалить B из этой настройки, оставив C.
Таким образом, в настройку excluded_categories изначально нужно будет добавить «частные» категории B и C. Не уверен, что это понятно?
Хотя с технической точки зрения это вполне возможно, я считаю, что такой подход будет излишне сложным, особенно учитывая, что «в начале» трудно определить или обнаружить, и вы хотите избежать ситуации, когда плагин снова добавляет B после того, как администратор сайта его удалил. Кроме того, при добавлении новой приватной категории плагину потребуется включить её в настройки, но при этом он должен уметь различать новую категорию (добавить) и категорию, которая ранее была удалена администратором (не добавлять заново).
Я бы выбрал настройку include_private_categories, которая изначально пуста, и плагин просто обрабатывал бы все публичные категории, а также категории из include_private_categories. Это избавит вас от множества проблем.
Кроме того, с функциональной точки зрения это упрощает отслеживание того, какие приватные категории сейчас доступны для общего доступа (в вашем подходе пришлось бы держать в уме список категорий, а затем определять, каких не хватает, сравнивая их с теми, что указаны в настройках).
Ещё один альтернативный вариант, который я могу представить, — это использование двух отдельных репозиториев: одного для публичного контента и одного для приватного контента.
Сам репозиторий с приватным контентом можно оставить закрытым (вы можете независимо определять, кто имеет к нему доступ).