# 사전 시드된 사이트 피드백 카테고리 - 보안 규칙 수정 허용
**URL:** https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033
**Category:** Feature
**Created:** [7월 17, 2020, 12:57오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033 "2020-07-17T12:57:56Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [7월 17, 2020, 12:57오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/1 "2020-07-17T12:57:56Z")
사전 시드된 Site Feedback 카테고리에서 편집 시 보안 탭에 경고가 표시됩니다.
> 경고: 이 카테고리는 사전 시드된 카테고리이며 보안 설정을 편집할 수 없습니다. 이 카테고리를 사용하지 않으려면 재사용하는 대신 삭제하십시오.
Staff 카테고리의 보안 규칙을 잠가 두는 데에는 상당한 이유가 있을 수 있다는 점은 이해합니다. 하지만 사전 시드된 ‘Lounge’ 카테고리의 보안 규칙은 잠겨 있지 않습니다. ‘Site Feedback’ 카테고리도 Lounge와 마찬가지로 보안 규칙을 편집할 수 있도록 처리되어야 한다고 생각합니다.
Site Feedback 카테고리의 보안 설정을 편집할 수 있을 경우 발생할 수 있는 불리한 영향이 있는지는 잘 모르겠습니다. 해당 카테고리의 다른 옵션들은 잠겨 있지 않은 것으로 보입니다.
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [7월 17, 2020, 3:08오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/2 "2020-07-17T15:08:07Z")
> [@markersocial](#):
>
> 사이트 피드백 카테고리의 보안 설정을 편집할 수 있는 기능의 불리한 영향이 있는지를 놓치고 있는 건지 확실하지 않습니다. 해당 카테고리의 다른 옵션들은 잠겨 있지 않은 것으로 보입니다.
저도 이 카테고리를 다른 보안 설정으로 마이그레이션하려는 중입니다. 한두 번의 클릭으로 설정을 쉽게 변경할 수 있는 방법이 있기를 바랍니다. 👍
` 모든 사용자가… 생성 / 답변 / 보기`
---
### Author:  [@JimPas](https://meta.discourse.org/u/JimPas)
#### Post date: [7월 17, 2020, 5:31오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/3 "2020-07-17T17:31:51Z")
> [@markersocial](#):
>
> 하지만 사전에 시드된 ‘Lounge’ 카테고리의 보안 규칙은 잠금되어 있지 않습니다. ‘Site Feedback’ 카테고리도 Lounge와 마찬가지로 보안 규칙을 수정할 수 있도록 처리해야 한다고 생각합니다.
Lounge는 사용자가 TL3 등급을 달성해야만 접근할 수 있도록 설정되어 있습니다. Lounge는 커뮤니티에 적극적으로 참여하는 사용자에게 일종의 ‘특권’이나 ‘보상’입니다. 이 유형의 카테고리에 대한 접근 자격을 변경하고 싶다면, 원하는 보안 허용 범위를 가진 새로운 카테고리를 단순히 생성하면 되지 않을까요?
Site Feedback의 경우, 사용자가 신규이고 더 높은 TL 등급을 달성하지 못했다고 해서 커뮤니티에 유익한 제안을 하지 못할 것이라고 생각하시나요? 그것은 마치 “신규 사용자라면, 당신의 의견을 듣고 싶지 않다”는 말과 비슷하게 들립니다. 🤨
직접 시도해 본 적은 없지만, 선호하는 보안 설정을 가진 새로운 카테고리를 생성한 후, 모든 게시물을 해당 새 카테고리로 _이동_하고, 원래 카테고리를 삭제하는 것이 가능할 _수도_ 있습니다. 단, 이름을 `site-feedback`과 다르게 변경하는 것을 꼭 확인하세요.
이전에 이 주제에 대해 논의가 이루어진 적이 있습니다(사전 시드된 카테고리의 보안 설정을 변경하려는 시도). 그렇다면 왜 요구 사항에 맞는 새로운 카테고리를 생성하고 사전 시드된 카테고리를 삭제하지 않나요?
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [7월 17, 2020, 6:48오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/4 "2020-07-17T18:48:38Z")
네, @JimPas 님의 말씀도 타당합니다. 삭제 후 재생성하는 것이 해결책이 된다는 점도 맞습니다. 저는 이것이 큰 문제가 된다고 생각하지는 않지만, 해당 카테고리의 보안 설정을 편집할 수 있도록 하는 것이 더 이상적인 기본값이 될 수 있다고 봅니다.
많은 경우 새 사용자의 피드백 게시를 허용하는 것이 이상적일 것입니다. 다만, 모든 커뮤니티에서 해당 카테고리의 보안 설정이 잠긴 상태로 기본값으로 제공되는 것은 다소 주관적(opinionated)이라고 생각합니다. 보안 설정을 잠금으로써 유연성이 감소되는 데서 얻을 수 있는 이점은 크게 보이지 않습니다.
몇 가지 더 구체적인 이유를 들면 다음과 같습니다:
- 보안 잠금의 이유 중 하나는, 적어도 제시된 메시지에 따르면, 카테고리의 용도 변경을 방지하기 위함입니다. 하지만 관리자는 카테고리 이름과 슬러그를 자유롭게 변경할 수 있으므로, 어쩌면 무지하게 해당 카테고리를 원하는 대로 용도 변경할 수 있습니다(보안 설정 옵션을 편집할 수는 없지만).
- 일부 관리자는 로그인하지 않은 사용자와 웹 크롤러에게는 사이트 피드백 카테고리를 숨기되, 모든 로그인한 사용자(신규 사용자 포함)는 피드백을 보고 게시할 수 있도록 원할 수 있습니다.
- 일부 경우 관리자는 더 구체적인 사이트 피드백 하위 카테고리를 생성하고, 상위 카테고리에서의 게시를 금지하여 사용자가 피드백을 적절한 하위 카테고리에 선택하도록 하여 주제 구성을 개선하고 싶어할 수 있습니다. 보안 설정을 편집하지 않고서는 이것이 불가능하다고 생각합니다.
- 관리자는 우회책으로 카테고리를 삭제하고 새 카테고리를 생성할 수 있습니다. 하지만 이미 운영 중인 포럼에서는 이것이 이상적이지 않을 수 있습니다. 새 카테고리는 기존 ID와 URL이 달라져 해당 카테고리에 대한 기존 정적 링크와 외부 링크가 깨질 수 있습니다. 그래도 Permalinks 옵션을 이용해 기존 카테고리를 리디렉션하는 우회 솔루션을 사용할 수는 있습니다.
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [7월 17, 2020, 7:01오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/5 "2020-07-17T19:01:45Z")
> [@markersocial](#):
>
> 일부 관리자는 로그인하지 않은 사용자 및 웹 크롤러에게는 사이트 피드백 카테고리를 숨기되, 모든 로그인한 사용자(신규 사용자 포함)는 피드백을 보고 게시할 수 있도록 원할 수 있습니다.
저희에게도 정확히 같은 문제입니다. 최근 몇 달간 저희 Discourse 개발은 매우 활발했지만, 사람들은 이제 이를 의도된 용도(메일링 리스트 대체)로 사용하려고 하고 있습니다. 포럼의 설정 및 유지 관리와 관련된 해결된 게시물이 매우 많은데, 일반 사용자는 이에 전혀 관심이 없습니다.
> [@markersocial](#):
>
> 신규 사용자의 피드백 게시 허용
저희에는 미분류(uncategorized)인 기본 카테고리가 있으며, 피드백을 주고 싶을 때 단순히 `@staff`를 태그하도록 모든 사용자를 장려하고 있습니다. 심지어 사용자가 새 주제를 작성하기 직전에 표시되는 설명란에도 이 내용을 포함하고 있습니다. 또한 "포럼 문제를 여기에서 보고하세요"라는 전용 주제도 있어, 해당 스레드에서 요청한 기능이 업데이트 및 추가되었는지 전달하고 사용자 의견을 장려하고 있습니다.
> [@markersocial](#):
>
> 관리자는 우회책으로 카테고리를 삭제하고 새 카테고리를 만들 수 있습니다. 그러나 이미 운영 중인 포럼에는 이상적이지 않을 수 있습니다.
그렇습니다. 이 데이터에 대한 접근을 제한하는 문제가 아닙니다. 제 집에 들어온다면 건축 도면이나 청구서 등을 바닥이나 테이블 위에 여기저기 흩어 놓지 않겠죠. 사람들이 그런 정보를 원한다면 다른 방식으로 찾을 수 있을 것입니다… 예를 들어 스태프 그룹이나 유사한 곳에서는 사용자가 옵트아웃과 마찬가지로 더 자동으로 옵트인할 수 있습니다.
이는 일상적인 사용과 실험적 기능을 테스트하기를 명시적으로 선호하는 사람들 사이의 균형 문제입니다.
> [@JimPas](#):
>
> “새로운 사용자라면, 당신들의 의견을 듣고 싶지 않다.”
저희 포럼에서는 그런 태도가 아니라, 커뮤니티 사용자가 실제로 일을 처리하려고 할 때 언제쯤 골조(스캐폴딩)를 숨기거나 대규모 공사 가시성을 제한해야 하는지에 대한 문제입니다. 🙂
---
### Author:  [@JimPas](https://meta.discourse.org/u/JimPas)
#### Post date: [7월 17, 2020, 9:50오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/6 "2020-07-17T21:50:15Z")
> [@markersocial](#):
>
> 일부 경우 관리자 사이트 피드백 하위 카테고리를 더 구체적으로 생성하고, 상위 카테고리에서의 게시를 허용하지 않을 수 있습니다. 이렇게 하면 사용자가 피드백을 위한 적절한 하위 카테고리를 선택해야 하며, 이를 통해 주제 구성을 개선할 수 있습니다.
저희 포럼에는 _사이트 피드백_ 카테고리와 \*메타(META)\*라는 카테고리가 있습니다. 🙂 메타 카테고리에서는 사용자들이 자신이 경험한 구체적인 문제에 대해 새로운 주제를 생성할 수 있습니다. 문제가 해결되면 해당 주제는 '해결됨’으로 표시됩니다. 사이트 피드백 카테고리는 처음 생성되었을 때와 동일하게 유지되고 있습니다. 다만, 저희 포럼은 현재 폐쇄된 다른 포럼에서 7년 이상 서로를 ‘알고 지낸’ 소수의 회원들로 구성되어 있다는 점을 참고해 주시기 바랍니다.
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [7월 29, 2020, 3:14오전 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/7 "2020-07-29T03:14:32Z")
저희 포럼에는 다음과 같은 구성이 있습니다:
- `About` 카테고리: 예전에는 Meta라고 불렸지만, 포럼 내에 자신을 Meta라고 칭하는 그룹이 있어 혼란을 줄이기 위해 해당 카테고리 이름을 그들에게 양보했습니다. 큰 문제는 아니지만, 볼 이유가 없는 비로그인 사용자에게 이 `About` 카테고리를 숨기는 것이 좋을 것 같습니다. 또한, 단순히 공개 그룹으로만 접근을 제한하는 것도 합리적일 수 있습니다.
- `Staff` 카테고리: 포럼을 지저분하게 만드는 것을 원치 않는 임의의 통합 및 기술 관련 게시글을 올리는 곳입니다. 스태프 노트(staff notes) 기능을 아직 사용해 보지 않아, 이 카테고리가 그 역할을 대신하고 있습니다.
대부분의 토론이 기본 토론 장소인 uncategorized(분류 없음)에서 이루어지는 것을 알게 되었습니다. 사람들은 태그를 많이 즐기고 있지만, 아무나 태그를 만들 수 있도록 너무 느슨하게 관리하고 있는 것 같습니다.
> [@markersocial](#):
>
> 일부 관리자들은 비로그인 사용자 및 웹 크롤러에게는 사이트 피드백 카테고리를 숨기되, 모든 로그인 사용자(신규 사용자 포함)에게는 피드백을 보고 게시할 수 있도록 허용하기를 원할 수 있습니다.
이것이 제 주요 이유입니다. 로그인조차 하지 않은 사람들은 포럼의 설정에 관심이 없을 가능성이 높습니다. 그들은 그저 일반적인 토론 등을 보고 싶어 할 뿐입니다.
---
### Author:  [@JimPas](https://meta.discourse.org/u/JimPas)
#### Post date: [7월 29, 2020, 4:43오전 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/8 "2020-07-29T04:43:18Z")
> [@sunjam](#):
>
> 하지만 사람들이 이제 이를 의도된 용도(메일링 리스트 대체)로 사용하려고 하고 있습니다. 포럼의 설정 및 유지보수와 관련된 해결된 게시글이 매우 많으며, 일반 사용자는 이런 것에 전혀 관심이 없습니다.
사이트 피드백 카테고리에서 게시물을 받지 않기를 원하는 사용자는 언제든지 설정에서 해당 카테고리를 음소거할 수 있습니다. 그러면 원치 않는 게시물을 보거나 최신(Latest) 탭에서 해당 카테고리 전체를 보는 것을 방지할 수 있습니다. 가끔 확인하고 싶다면 카테고리 목록을 아래로 스크롤하여 그곳에서 진입하면 됩니다.
하지만 @markersocial님의 원래 질문(사이트 피드백 카테고리의 보안 규칙 수정 허용)에서 약간 벗어났다고 생각합니다.
(카테고리의 다양한 용도에 대한 이 논의는 계속되면 좋겠습니다.)
> [@markersocial](#):
>
> 일부 경우 관리자는 더 구체적인 사이트 피드백 하위 카테고리를 생성하고, 사용자가 주제 조직을 개선하기 위해 적절한 하위 카테고리를 선택하도록 상위 카테고리에서의 게시를 금지하기를 원할 수 있습니다.
왜 사용자가 자신의 특정 피드백에 특화된 새로운 주제를 사이트 피드백 카테고리에 생성하지 않나요? 저희 사이트 피드백 카테고리에는 사용자가 생성한 여러 주제가 있습니다. 이는 더 많은 제안함(suggest box)이자 질문을 위한 공간입니다. 사용자가 문제를 경험하면, "Meta"라는 적절한 제목의 트러블슈팅(문제 해결) 카테고리에 게시합니다. 🙂
제안하신 이유에 대한 간단한 해결책은 다음과 같습니다.
- "피드백"이라는 제목의 카테고리를 생성하고,
- 사용자가 주제를 생성할 수 있도록 원하는 하위 카테고리를 생성하며,
- 아무도 게시할 수 없도록 메인 카테고리를 설정하는 것입니다.
하지만… 그런 설정을 하면 사용자가 하위 카테고리에서 게시하는 것도 막히게 될까요?
저는 아직 시도해 본 적이 없습니다. 흥미로운 실험인 것 같지만, 저는 곧 잠자리에 들려고 합니다. 내일 시도해 볼 수도 있겠네요 - 팀 멤버 중 누군가가 여기 들어와 이것이 작동하는지 여부에 대한 설명을 해주지 않는다면요.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [7월 29, 2020, 8:05오전 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/9 "2020-07-29T08:05:52Z")
JimPas 님, 감사합니다 🙂
그래서 제가 생각하기에 핵심 질문은 _ **모든 설치 환경에서 사전 생성된 사이트 피드백 카테고리의 보안 설정을 잠가 두는 것이 어떤 이점이 있는가** _ 입니다.
솔직히 그 이점을 잘 생각해 내지 못하겠습니다. 제거해도 단점이 없는 다소 불필요한 장벽처럼 보입니다. 새 설치 환경에서는 기본적으로 권장 보안 설정을 적용하되, 그 외의 사용 사례를 위해 유연성을 허용하는 것이 좋습니다. 기본적으로 Lounge 사전 생성 카테고리처럼 작동하게 하면 됩니다.
제안하신 것처럼 카테고리를 삭제하고 다시 생성하는 우회 방법이 있으므로 큰 문제는 아닙니다 👍 . 다만, 포럼이 성장하면서 나중에 이 설정을 수정하려는 오래된 포럼의 경우, 카테고리 URL이 변경되므로 약간 덜 우아한 해결책이 될 수 있습니다(이를 돕기 위해 관리자 \> 사용자 정의 \> 영구 링크를 사용할 수 있습니다).
네, 맞습니다. 사용자들은 자신의 피드백에 특화된 주제를 사이트 피드백 카테고리에 생성할 수 있습니다. 다만, 포럼이 다양한 브랜드의 일부로 여러 사용자 대상 사이트/앱 및 제품을 포함하고 있는 경우와 같은 특정 사용 사례에서는 각 주제에 대해 하위 카테고리를 사용하는 것을 강제하는 것이 유용할 수 있습니다.
* * *
몇 가지 예시 (이들은 하위 카테고리 사용을 강제하지는 않습니다):
[https://community.cloudflare.com/c/feedback/25](https://community.cloudflare.com/c/feedback/25)
> **[Feedback](https://community.brave.app/c/feedback/79)**
>
> Post feedback on Brave, Brave Rewards and Community here. Please be constructive!
* * *
일부 피드백은 회사의 주요 제품 및 그 특정 분류된 측면에 관한 것이거나, 포럼 자체에 관한 것이 될 수 있습니다. 이 포럼 자체에는 블로그를 위한 [사이트 피드백 하위 카테고리](https://meta.discourse.org/c/site-feedback/blog/13)가 있으며, 여기에는 다른 태그 그룹이 할당되어 있습니다.
> [@JimPas](#):
>
> 하지만… 그 설정이 하위 카테고리에서의 사용자 게시를 방지하게 될까요?
이와 관련하여, 저는 이전에 몇몇 카테고리에 이 방법을 사용했습니다(부모 카테고리에서 게시를 허용하지 않지만 하위 카테고리에서는 게시를 허용). 하위 카테고리의 보안 규칙은 부모 카테고리의 보안 규칙에 영향을 받지 않습니다. 따라서 네, 이것이 확실히 해결책입니다. 👍
---
### Author:  [@JimPas](https://meta.discourse.org/u/JimPas)
#### Post date: [7월 29, 2020, 5:13오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/10 "2020-07-29T17:13:48Z")
> [@markersocial](#):
>
> 하위 카테고리의 보안 규칙은 상위 카테고리의 보안 규칙에 영향을 받지 않습니다. 네, 이것이 확실히 해결책입니다.
감사합니다. 이것을 확인해 볼 필요가 없게 되어 다행입니다. 오늘 3살 손녀가 예상치 못한 방문을 해서 저랑 놀아달라고만 해서 거의 5시간을 낭비했어요. 🙄 🥰 😆
드디어 제 포럼을 확인해 볼 수 있겠네요. 🙂
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [7월 30, 2020, 11:10오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/11 "2020-07-30T23:10:17Z")
> [@markersocial](#):
>
> 따라서 제가 보기에 핵심 질문은, _ **모든 설치 환경에서 사전 시드된 사이트 피드백 카테고리의 보안 설정을 잠가 두는 것이 어떤 이점이 있는가** _입니다.
>
> 솔직히 그 이점을 생각해 내기 어렵습니다. 제거했을 때 단점이 없는데, 불필요한 장벽처럼 느껴집니다.
이는 기술적 한계에 대한 우회 조치입니다. 만약 우리가 (Discourse) 기본 설정을 업데이트하거나 카테고리의 번역된 이름을 변경하게 된다면, 사람들이 시드된 카테고리를 “일반” 카테고리로 전용한 후 어느 날 기본값이 업데이트되면서 카테고리가 갑자기 바뀌게 되어 큰 혼란을 야기할 수 있습니다. _(네, 실제로 이런 일이发生过 있습니다. 그래서 이러한 제한이 존재합니다.)_
보안 설정을 수정하지 못하도록 하는 것은 해당 카테고리가 특별하며 기본값 업데이트의 대상임을 상기시켜 주는 역할을 합니다.
자동 업데이트 기능이 이 카테고리들을 특별하게 만드는 **유일한** 이유이기 때문에, 도움말 텍스트에서는 카테고리를 전용하는 대신 카테고리를 완전히 삭제하고 새 카테고리를 만들 것을 권고합니다.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [7월 31, 2020, 10:17오전 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/12 "2020-07-31T10:17:53Z")
아, 그 말이 맞네요. 설명해 주셔서 감사합니다 @riking.
카테고리를 다른 용도로 사용하는 것이 매우 해롭다면(저는 그런 것을 권장하지 않습니다), 카테고리 이름 변경 설정에 경고를 표시하는 것이 더 합리적일까요? 보안 규칙은 그러한 잠재적 문제와 직접적으로 강하게 관련되어 보이지 않습니다.
몇 가지 점을 강조하겠습니다:
- Lounge(라운지) 카테고리는 동일한 자동 업데이트 대상에 속하지만, 보안 설정은 수정 가능합니다.
- Site Feedback(사이트 피드백)은 보안 규칙 잠금 기능을 거의 인지하지 못한 채 제목과 슬러그를 변경하여 다른 용도로 사용할 수 있습니다. 이 카테고리는 새로운 “일반” 카테고리와 동일한 기본 보안 규칙을 가지고 있습니다.
- 잠금 기능은 로그인한 사용자에게만 카테고리를 표시하거나 특정 신뢰 수준으로 제한하는 것과 같이 비교적 간단한 변경 사항까지도 방지합니다.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [7월 31, 2020, 12:49오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/13 "2020-07-31T12:49:10Z")
제가 아는 한, lounge(라운지)는 일반적인 카테고리이며, ACL과 신뢰 수준 기반 접근 방식을 보여주는 데만 사용되는 것 같습니다.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [7월 31, 2020, 1:37오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/14 "2020-07-31T13:37:11Z")
@Stephen - ‘site\_settings’ 테이블에서 postgres에 라운지 카테고리가 참조되고 있는 것을 확인했습니다. 이것이 얼마나 의미 있는지는 정확히 확신하지 못하지만, 유사하게 처리되는 것 같습니다. 테스트 인스턴스에서 ‘meta\_category\_id’(사이트 피드백 카테고리)를 수정해 보니 재빌드 시 사이트 피드백 카테고리에 영향을 미쳤습니다.
---
### Author:  [@sunjam](https://meta.discourse.org/u/sunjam)
#### Post date: [7월 31, 2020, 3:25오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/15 "2020-07-31T15:25:04Z")
@markersocial Pre-Seeded에서 새 맞춤 카테고리로 100개 이상의 주제를 마이그레이션할 때, 각 주제를 개별적으로 옮기는 것 외에 추천하는 방법이 있나요?
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [7월 31, 2020, 3:38오후 UTC](https://meta.discourse.org/t/pre-seeded-site-feedback-category-allow-modifying-security-rules/158033/16 "2020-07-31T15:38:30Z")
@sunjam 해결책입니다: [Bulk move many topics from one category to another - #2](https://meta.discourse.org/t/bulk-move-many-topics-from-one-category-to-another/38704/2?u=markersocial)
방금 테스트 인스턴스에서 테스트해 보았으며 잘 작동했습니다. 다만 테스트한 토픽의 수는 많지 않았습니다.
서버에 SSH로 접속한 후 다음 명령어를 사용하세요(이 예제에서는 카테고리 2의 모든 토픽이 카테고리 1으로 이동하므로, 필요에 따라 해당 번호를 교체하세요):
```
cd /var/discourse
./launcher enter app
rails c
Topic.where(category_id: 2).update_all(category_id: 1)
```
카테고리 ID는 카테고리 URL 끝에 있는 숫자에서 확인할 수 있습니다.
수정: 유일한 문제는 ‘이 카테고리에 대하여’ 포스트도 함께 이동한다는 점이며, 관리자 UI에서 이를 되돌리거나 삭제하는 것이 불가능해 보입니다. 목록에서 제외(unlisted)할 수는 있지만, 이로 인해 문제가 생기는지는 확실하지 않습니다. 잠시만 기다려 주시면 곧 업데이트하겠습니다.
수정 2: ‘이 카테고리에 대하여’ 토픽을 올바른 카테고리로 되돌리기 위해 다음 명령어를 사용하세요(여기서 토픽 ID는 1, 이동하려는 대상 카테고리는 2입니다). 방금 테스트해 보았으며 잘 작동했습니다:
```
Topic.where(id: 1).update_all(category_id: 2)
```
토픽 ID도 카테고리 ID와 마찬가지로 토픽 URL 끝에서 확인할 수 있습니다.