현재 플래그는 생성 후 편집이 허용되지 않습니다.
플래그가 사용된 후에는 삭제하거나 의미를 변경할 수 없어야 한다는 점은 이해하고 있습니다.
커스텀 플래그 편집이 계획되어 있지만 아직 구현되지 않은 것인가요?
현재 플래그는 생성 후 편집이 허용되지 않습니다.
플래그가 사용된 후에는 삭제하거나 의미를 변경할 수 없어야 한다는 점은 이해하고 있습니다.
커스텀 플래그 편집이 계획되어 있지만 아직 구현되지 않은 것인가요?
웹 인터페이스에 이 옵션을 꼭 추가해야 합니다.
이 기능이 이동되었으므로 명확히 하겠습니다. 제가 말씀드린 것은 Edit가 아니라, 콘솔 레일즈를 사용하지 않고 플래그로 자동 감추기를 트리거할 수 있는 옵션입니다.
현재 커스텀 플래그는 생성 후에도 수정이 가능하도록 설계되어 있습니다. 그러나 한 번 사용된 후에는 더 이상 수정할 수 없습니다. 대신 비활성화하고 다른 플래그로 교체할 수 있습니다.
플래그 편집 페이지에는 다음과 같은 안내 메시지가 표시됩니다:
커스텀 플래그가 한 번 사용된 후에는 비활성화만 가능하며, 수정이나 삭제는 할 수 없습니다.
추가 편집이 허용되지 않는 이유를 좀 더 자세히 설명해 주실 수 있나요?
설명 내용을 수정하는 것(예: 명확성을 위해)은 어떤 동작에도 해를 끼치지 않아야 합니다.
투표와 유사할 가능성이 높습니다
이러한 유형의 문제에 대해 두 가지 다른 관점이 있는 것 같습니다: a) 히스토리를 변경하지 않는다 b) 작동할 때까지 해킹(개선)한다.
일관성이 핵심입니다. 현재 이 동작을 변경할 계획은 없습니다. 따라서 이미 사용 중인 사용자 지정 플래그 중 하나를 변경해야 한다면, 해당 프롬프트의 안내에 따라 플래그를 비활성화한 후 새 플래그를 생성해야 합니다.
대부분의 사이트는 플래그에 대한 변경이 전혀 필요하지 않으며, 변경이 필요한 경우에도 플래그가 사용되기 시작하면 거의 변경되지 않거나 아예 변경되지 않는 것이 전제됩니다.
알겠습니다. 그러면 콘솔을 사용해서 텍스트를 수정하겠습니다.
저희는 사용자가 메시지를 보낸 작성자에게 연락하고 싶을 때 공개적으로(대부분은 이메일을 통해) 답변하지 않도록 교육하기 위해 "개인 정보 공유"라는 플래그를 사용하고 있습니다.
이 과정에서 텍스트를 수정해야 합니다.
하지만
의 경우, 플래그 사유 50개 제한은 그렇게 많지 않습니다.
플래그를 선택한 후 추가 세부 정보를 입력할 수 있는 옵션을 사용하는 것은 어떨까요? ‘기타’ 플래그와 유사한 방식입니다.
그렇다면 개인 메시지를 플래깅하여 포럼을 정리하는 데 도움을 주는 모든 사람이 교육받지 않은 사용자를 위해 교육용 텍스트를 작성해야 하게 되며, 이는 현실적으로 불가능합니다.
이것이 오픈소스의 힘입니다! ![]()
하지만 그렇게 하면 전적으로 본인 책임이 되며, 저희로부터 지원을 받는 것이 더 어려워질 수 있습니다. 이미 알고 계실 것입니다. 이미 사용된 플래그는 콘솔을 통해 변경하는 대신 비활성화하고 새로운 플래그를 만드는 것을 권장합니다.
이것은 숨겨진 설정이며 증가시킬 수 있습니다. 이 제한에 부딪히는 저희 호스팅 사용자는 저희에게 연락하여 한도를 높여달라고 요청할 수 있습니다. 또한 고객님들이 커스텀 플래그를 어떻게 사용하시는지, 그리고 왜 그렇게 많은 변경이 필요한지에 대해 의견을 들려주시면 저희에게도 매우 흥미로운 자료가 될 것입니다!
그러면 커스텀 플래깅을 확장하기 위해 플러그인이나 다른 무언가가 필요한 것 같네요.
아니면, 추가 작업으로 모드가 PM을 보내는 템플릿 플러그인을 사용하는 것도 방법일 수 있습니다.
또는 대안으로, PM을 위한 커스텀 자동화 스크립트를 만드는 것도 생각해볼 수 있겠네요.
저는 이 제한 사항이 더 고급화된 공개 프로젝트 워크플로우에서 Discourse 소프트웨어를 사용할 때 상당한 제약이 된다고 생각합니다. 더 구체적인 규칙을 설정하되, 해당 규칙에 대해 교육받지 않은 청중에게도 열려 있어야 하는 경우가 많기 때문입니다.
적절한 설명과 관련 도움말 문서 링크를 갖춘 사용자 정의 플래그는 현재 포럼의 기대치와 규칙을 사용자에게 전달하는 가장 쉬운 방법입니다. 방대한 규칙 목록이 담긴 별도의 문서와 달리, 플래그 설명은 정확히 필요할 때 필요한 사람들에게(플래그를 설정하는 사람과 플래그를 받는 사람 모두에게) 표시됩니다. 제가 보기에 플래그는 Discourse의 강력한 기능입니다.
예를 들어, 우리 경우 포럼의 일부 영역에서는 오프톱으로 간주되는 기준이 훨씬 더 엄격하게 정의되어야 하는데, 일반적인 오프톱 플래그만으로는 이를 충족시키기 어렵습니다. (기본적으로 현재 ‘오프톱’ 라벨이 붙은 시스템 플래그가 사용될 때마다 "이건 오프톱이 아닌데요"라는 답변이 돌아오고, 이 특정 제약 조건 하에서 왜 오프톱인지에 대해 개인적인 대화를 나누어야 하는 상황이 발생합니다.)
이러한 경우를 위해 적절한 설명과 워크플로우 문서 링크를 갖춘 "워크플로우에 부합하지 않음"이라는 구체적인 플래그를 만들겠습니다. 설명은 기반이 되는 워크플로우의 진화와 함께 발전해야 하므로, 플래그의 메시지는 반복적으로 조정하고 맞춤화할 것입니다.
하지만 편집이 허용되지 않아 오탈자 수정조차 할 수 없으며, 더 정교한 설명을 추가하는 것은 더더욱 불가능합니다.
"역사를 변경하지 말라"는 우려사항을 이해하지만, 이를 우회하는 방법이 있습니다. 예를 들어 설명 필드만 편집 가능하도록 하거나, 새로운 편집 가능한 “문서/도움말” 필드를 추가하거나, 플래그에 새로운 버전 필드를 추가하여 편집 시 버전을 증가시켜 게시물이 이전 버전의 플래그로 설정되었음을 표시하는 방법 등이 있습니다… 등
P.S. 50개 플래그 제한에 비활성화된 플래그도 포함됩니까? 만약 그렇고, 비활성화된 플래그를 삭제할 수도 없고 편집할 수도 없다면, 플래그는 장기적인 설정에 지속 가능하지 않은 제한된 비재생 가능 자원이 됩니다.
3.5.0beta3에서 FEATURE: allow edit custom flags - Pull Request #32344%EB%A5%BC - discourse/discourse - GitHub 통해 이 문제가 다소 개선되었을 수도 있지만, 실제로 작동하는 것을 확인하지 못했습니다 — 심지어 한 번도 사용해 본 적 없는 플래그에서도 마찬가지입니다.
커스텀 플래그 기능이 도입되기 전에는 site_texts를 사용하여 내장 플래그 중 일부의 의미를 자유롭게 변경해 왔습니다.
… 이러한 제한의 배경에는 타당한 이유가 있다는 점은 이해하지만, 이 제약은 상당히 지나치게 간섭적인(paternalistic) 것으로 느껴집니다.