이것은 Contribute > Feature - Development 토픽과 비슷해서, 어느 쪽에 올려야 할지 확신이 서지 않습니다.
플러그인에서 사이트 설정을 수정할 방법이 있을까요? 99%는 없다고 생각하지만, 확인을 받고 싶습니다.
만약 없다면, 이를 불변(immutable)이 아니게 해달라는 제안을 올릴 수 있을까요? 또는 SiteSettings의 불변 속성을 '잠금 해제’할 수 있는 API나 방법이 있다면 어떨까요?
고려 중인 가능한 사용 사례 중 하나는, 관리자가 포함/제외하기 쉽게 하도록 설정에 보호된 카테고리 목록을 포함하는 것입니다.
감사합니다.
단순히 사이트 설정의 값만 변경하려는 건가요? 그렇다면 SiteSetting.whatever='new value'를 실행하면 됩니다. 아니면 설정 자체에 대해 무언가를 변경하려는 건가요?
그걸 위해 설정을 추가하려는 것 아닌가요? config/settings.yml에 추가하면 되나요? 다음과 같은 형태로요:
그것이 원하시는 것이라면, rake plugin:create[plugin-name]을 사용하면 예제가 포함된 설정 파일이 자동으로 생성됩니다.
아니면 제 질문을 잘못 이해하고 있는 걸 수도 있겠네요.
여기서부터 시작해서 바깥으로 확장해 보겠습니다.
먼저 커뮤니티의 관점에서 사용 사례를 설명해 주시겠어요? 그들은 무엇을 달성하려고 하고, 현재 그것이 왜 어려운가요? (구현 방식과 무관하게) 그들의 필요를 더 효과적으로 해결할 기능은 무엇이라고 상상하시나요?
그 다음, 이것이 플러그인으로 구현하는 것이 좋은지 아니면 핵심 기능으로 추가하는 것이 좋은지 결정할 수 있습니다.
그리고 나서 구현 방법에 대한 제안을 논의해 볼 수 있습니다.
@mcwumbly @pfaffman 알려주셔서 감사합니다.
설정값이 TC(테마 컴포넌트)에서 변경 불가능(immutable)하므로, Ruby 플러그인에서도 마찬가지라고 잘못 추측했습니다. 해당 방법을 시도해 보겠습니다.
TC에서 설정값을 편집할 수 있으면 좋겠습니다. 현재 저는 플러그인을 통해 이를 해결하고 있는데, 제 사용 사례는 기본적으로 모든 카테고리의 모든 주제와 게시글을 가져와서 특정 작업을 수행하는 것입니다. 하지만 보호된 카테고리(예: excluded_categories 설정)는 포함하지 않기를 원합니다.
만약 설정에 보호된 카테고리를 추가할 수 있고, 이후에 이를 접근할 수 있다면 더 쉬울 것입니다. 이렇게 하면 관리자가 원할 경우 설정에서 해당 카테고리를 제거함으로써 보호된 카테고리를 포함시킬 수 있습니다.
@pfaffman의 아이디어로는 아마도 구현할 수 있겠지만, TC에서는 불가능할 것입니다.
이 방식의 문제는 제가 사전에 보호된 카테고리를 알 수 없다는 점입니다.
관리자로 로그인되어 있다면, 테마 컴포넌트를 통해 API를 사용하여 siteSettings를 변경할 수 있습니다.
그렇다면 테마 컴포넌트 설정을 만들고 해당 카테고리를 추가하면 되지 않을까요? 제가 생각하지 못하는 어떤 protected_categories 사이트 설정을 말씀하시는 것은 아니시죠? 이런 식으로?
더 자세히 알고 싶습니다.
커뮤니티 자체에 대해 더 많이 공유해 주실 수 있을까요?
이 기능을 주로 사용하는 사람이 본인인가요, 아니면 팀 내에서 이 기능이 필요한 다른 사람들도 있나요? 이 기능에 의존하는 워크플로우에 대한 사용자 대상 문서가 있나요? 있다면, 어떤 내용인가요? 없다면, 어떤 모습일지 간략히 설명해 주실 수 있을까요?
이러한 질문에 대한 답변이 이 요청을 더 잘 이해하는 데 도움이 될 것 같습니다.
@mcwumbly @pfaffman 네, 최대한 설명해 보겠습니다.
토픽과 게시물을 가져와 GitHub에 마크다운 파일로 게시하는 플러그인(아카이브와 유사하게)을 개발하고 있습니다.
하지만 '비공개’이므로 비공개 카테고리(지금은 이가 올바른 용어인 것 같네요)를 포함하고 싶지 않습니다.
따라서, 사전에 비공개 카테고리가 무엇인지 알 수 없으므로 default 매개변수로 정의할 수 없는 비공개 카테고리 목록으로 설정값을 미리 채우는 방법을 찾고 있습니다.
만약 Ruby에서 SiteSetting을 직접 변경하여 이를 수행할 수 있다면, 테마 컴포넌트(Theme Component)의 settings에도 동일한 작업을 수행할 수 있을까요? 후자가 불변(immutable)이라고 꽤 확신합니다. 테마 컴포넌트에서 이를 변경할 수 있는 방법이 있을까요?
조금만 기다려 주시겠어요.
커뮤니티 팀의 관점에서 여러분이 해결하려고 하는 문제가 무엇인지 더 잘 이해하고 싶습니다.
이 커뮤니티는 어떤 종류인가요? 누가 운영하나요? 왜 그 내용을 GitHub에 중복해서 올리길 원하나요?
그들은 어떤 문제를 해결하려고 하는 건가요?
실제로 커뮤니티에 대한 것이 아닙니다. 이것을 제 방식대로(백필(job) 작업도 포함하여) 시도해 보고 있습니다. 이 방식은 각 주제와 게시물을 리포지토리에 마크다운 파일로 저장합니다.
여전히 '비공개’가 무엇을 의미하는지 알 수 없습니다. 모든 사용자에게 표시되는 카테고리만 원하는 건가요, 아니면 익명 사용자에게도 표시되는 카테고리만 원하는 건가요? 아니면 다른 정의를 가지고 계신 건가요?
만약 그렇게 하신다면, 플러그인에서 사용자(또는 가디언 호출)를 전달하여 검색하거나, 단순히 권한을 확인하여 해당 카테고리만 가져올 수 있습니다.
또는 '비공개’가 의견에 따라 달라지는 것이라면, 설정 항목을 추가할 수 있습니다.
그리고 아마도 매일 실행되는 잡(job)에서 이 작업을 수행하고 싶으실 겁니다?
GitHub에 데이터를 푸시하는 경우, 브라우저로 Discourse에 데이터를 푸시하는 복잡한 과정을 거치는 것보다 Discourse가 직접 처리하는 것이 더 나을 것 같습니다. 왜 테마 컴포넌트로 이를 수행해야 하는지, 어떻게 해야 하는지 이해가 되지 않습니다.
제가 말하는 건 #staff 같은 카테고리, 그리고 그룹으로 제한된 다른 카테고리들을 의미합니다. 플러그인으로 가능한 것 같지만, 그러면 TC 설정을 변경할 수 없게 되는 거 아닌가요? 어쨌든 제 원래 질문과는 별개인 것 같습니다.
또 다른 가능한 접근 방식은 플러그인이나 테마 컴포넌트로 구현하는 것보다 이 기능을 더 외부로 분리하는 것입니다.
관련 참고 자료: Discourse Public Data Dump
다시 한번 말씀드리지만, 궁극적으로 도달하고자 하는 최종 결과물 관점에서 접근할수록 조언을 드리는 것이 더 쉬워집니다.
이 링크를 공유해 주셔서 감사합니다:
아직까지 암묵적으로 정의해 오신 기능 명세를 더 명확히 하기 위해 이 링크를 출발점으로 삼을 수 있을 것 같습니다.
제가 현재 이해하고 있는 바로는, 다음을 원하시는 것 같습니다:
현재 검토 중인 설계는 다음과 같습니다:
이렇게 이해한 것이 맞나요?
완전히 정확해요! 여기에서 그 구조의 기본 틀을 만들어 봤습니다.
그걸 위해 설정이 필요하지 않아요. 플러그인이 이미 그 정보를 가지고 있거든요.
제가 이해한 바로는, 이 “private” 카테고리들을 가져오기 위해 Category.where(...) 메서드를 사용하시는 건 맞나요? 하지만 관리자가 (일부) 카테고리를 포함하려고 한다면 어떻게 해야 할까요? 코드에서 정의된 “private” 카테고리들을 상쇄하는 include categories 설정이 필요할까요? 그렇게 하면 역효과가 나는 건 아닌가요?
업데이트: 즉, SiteSettings는 플러그인을 통해 수정할 수 있다는 뜻인가요? TC 설정은 여전히 수정할 수 없다고 생각하는데? Static pages sync: Allowing specific private categories to be synced - #2 by pfaffman 을 해결책으로 표시합니다.
여전히 이 부분이 이해가 되지 않습니다. 네, SiteSetting에 해당 설정을 추가할 수 있고, 플러그인이 그 설정을 읽을 수도 있으며, 심지어 변경할 수도 있습니다. 하지만 위의 시나리오에서 왜 설정을 변경해야 하는 건가요?
이 주제가 어떻게 발전해 왔는지를 고려하여 #dev로 이동합니다.
A, B, C, D, E라는 5개의 카테고리가 있다고 가정해 보겠습니다. 이제 B와 C가 일부 그룹에만 사용 가능하다고 가정해 보겠습니다. 저장소에 업로드할 때 이곳의 비공개 주제가 공유되지 않도록 방지하기 위해, B와 C를 excluded_categories 설정에 추가합니다. #staff 같은 다른 항목들도 함께 추가하는 식이죠.
이제 사이트 관리자가 B의 주제가 공유되는 것에 문제가 없다고 판단하면, C는 설정에 그대로 두면서 B만 설정에서 제거할 수 있습니다.
따라서 excluded_categories는 시작 시점에 “비공개” 카테고리인 B와 C를 추가하도록 변경되어야 합니다. 이게 말이 되는지 잘 모르겠습니다.
기술적으로는 완전히 가능하지만, 이 접근 방식은 지나치게 복잡하다고 생각합니다. 특히 "시작 시점"을 정의하거나 감지하기가 어렵고, 사이트 관리자가 B를 제거한 후 플러그인이 다시 추가하는 상황을 피해야 하기 때문입니다. 또한 새로운 비공개 카테고리가 추가될 때 플러그인이 설정에 해당 항목을 추가해야 하지만, 새로운 카테고리(추가)와 관리자가 이전에 제거한 카테고리(다시 추가하지 않음)를 구별할 수 있어야 합니다.
저는 include_private_categories 설정을 사용하는 것을 권장합니다. 이 설정은 기본적으로 비어 있으며, 플러그인은 모든 공개 카테고리뿐 아니라 include_private_categories에 포함된 카테고리를 처리하면 됩니다. 이렇게 하면 훨씬 덜 골치가 아플 것입니다.
또한 기능적인 관점에서 보면, 어떤 비공개 카테고리가 공유되고 있는지 파악하기가 더 쉬워집니다. (제안하신 방식에서는 머릿속에 카테고리 목록을 떠올린 뒤, 설정에 있는 목록과 비교하여 누락된 항목을 찾아야 합니다.)
이 주제가 실제로 무엇에 관한 것인지 더 잘 설명할 수 있도록 제목도 수정했습니다.
여기서 상상할 수 있는 또 다른 대안 설계는 공개 콘텐츠용과 비공개 콘텐츠용으로 두 개의 별도 저장소를 사용하는 것입니다.
비공개 콘텐츠 저장소 자체는 비공개로 유지할 수 있으며(액세스 권한을 독립적으로 결정할 수 있습니다).