The delete user action is found under different top level buttons depending on the type of flag. It would be nice if the Delete button always had a delete user sub action.
And btw, URLs are added to the screened list if you delete from a manually flagged review, just not from user posted too fast reviews.
개인 메시지에서 게시물을 플래그(신고)하는 것과 관련하여 몇 가지 이상한 일이 발생했습니다. 해당 메시지에는 두 명(저와 온보딩 중인 신규 관리자)이 참여하고 있었습니다. 플래그 기능을 테스트하던 중, 그녀가 자신의 게시물을 플래그를 했습니다. 그 결과, 우리 둘 다 메시지가 스팸으로 플래그되었으므로 수정해야 한다는 알림을 받았고, 게시물을 직접 통해 플래그 조치를 되돌릴 수 없었습니다. 또한 검토 대기열에도 표시되지 않았습니다.
게시물이 숨겨진 상태에서 게시물 관리자 톱니바퀴 아이콘을 선택했지만, 게시물 콘텐츠 뒤에 가려져 있어 사용할 수 없었습니다. 스크린샷을 참조하세요.
게시물을 편집했을 때에만 숨김이 해제되었습니다.
즉, 여러 가지 문제가 있습니다:
여기서 이루어진 개선 사항들을 정말 마음에 들어하고 있어요. 드디어 생각을 정리하고 이에 대한 피드백을 조금 쌓을 수 있는 기회가 생겼거든요:
이 때문에 약간 모호한 부분이 있어요.추가해야 할 또 다른 기능: 재신고된 항목이 게시물의 내용이 편집되거나 어떤 방식으로든 변경되지 않는 한 검토 대기열에 다시 표시되지 않도록 하는 것입니다. 이렇게 하면 새로운 신고 항목이 자동으로 무시되며, 해당 게시물을 알리거나 숨길 수 없게 됩니다.
여기서 의도는, 어딘가의 어떤 관리자가 이미 해당 신고를 확인하고 처리했다는 점이며, 같은 유형의 새로운 항목들도 동일한 방식으로 처리될 것이라는 것입니다.
위 사항에 대해 한 가지 주의할 점은, 새로운 신고를 자동으로 해결하는 대신 무시하는 것이 아마도 더 적절할 수 있습니다. 신고가 실제로 처리된 방식(예: 동의)과 동일한 방식으로 검토 가능 항목을 자동으로 해결하면, 관리자가 '동의 + 유지’로 해결한 항목에 대해 반복적으로 신고함으로써 신고 점수를 부풀리는 신고 트롤(flag griefer)에게 의도치 않은 이점을 줄 수 있기 때문입니다.
좋은 지적입니다. 이어서 말씀드리면, 저는 정기적으로 게시물을 승인한 후 Akismet에 의해 스팸으로 플래그가 지정되는 경우가 있습니다. 이런 일은 일어나지 않아야 합니다.
아, 그렇네 - 필요한 경우 플러그인이 여전히 위의 제안을 덮어쓸 수 있는 기능을 가져야 할 것 같긴 하지만, 이 경우 Akismet이 그렇게 해서는 안 된다는 데에는 동의해. 이건 아마도 Akismet 플러그인 쪽의 문제일 수 있지만, 아주 좋은 지적이야.
이것은 플러그인 문제입니다. 수정 사항을 배포하겠습니다.
이미 이 부분에 대해 조사를 시작했습니다. 자동 해결하는 대신 새로운 신고를 무시해야 한다는 데 동의합니다. 검토된 게시물을 다시 신고하려는 시도가 있을 때 오류 메시지를 표시하는 방안을 고려하고 있습니다.
또한, 동일한 이유로 게시물을 다시 신고할 수 있도록 하기 전에 사용자가 약 24시간 정도 기다려야 한다고 생각했습니다.
모든 최신 대기 항목이 ‘전체 보기’ 메뉴에 있으므로, ‘리뷰’ 탭은 ‘주제별 그룹화’ 메뉴가 아니라 해당 메뉴로 리디렉션해야 합니다.
리뷰 가능한 기본 주제가 설정되어 있나요? 이 설정은 모든 항목이 기본값이어야 하는 대신 주제를 기본값으로 지정하게 됩니다.
Discourse 2.4.0.beta11 Release Notes 에 따르면:
의심스러운 사용자는 검토 대기열로 이동
의심스러운 사용자(게시물 1개와 주제 1개 미만만 열람했으나 자기소개는 작성한 사용자)는 이제 검토 대기열로 이동됩니다. 대부분의 사용자는 자기소개를 작성하기 전에 사이트를 둘러보기 때문에, 이러한 사용자는 스팸일 가능성이 높습니다.
우리는 이 기능이 작동하지 않습니다. 새로운 의심스러운 사용자는 /admin/users/list/suspect 페이지에 정상적으로 표시되지만, 검토 대기열에는 표시되지 않습니다. 이는 특정 설정에 따라 달라지는 것인가요?
예, 이 기능은 의심 사용자 승인 설정(기본적으로 비활성화됨)에 따라 동작합니다.
좋아요, 이제 잘 작동합니다 (이런 정보는 릴리스 노트에 추가하는 것이 좋을 것 같습니다).
다만 검토 과정을 더 빠르게 진행할 수 있도록 작은 요청이 하나 있습니다. 웹사이트 필드를 링크로 연결해 주실 수 있을까요? 현재는 복사/붙여넣기를 해야 해서 작업 속도가 많이 느려집니다.
추가하신 사용자 필드인 것 같습니다. 불행히도 해당 필드가 URL인지 아닌지는 알 수 있는 방법이 없습니다.
‘Website’ 필드요? 그건 커스텀 필드가 아니에요 (메타에서도 마찬가지예요). 나머지 두 개는 커스텀 필드긴 한데, 저는 그걸 핫링크로 사용할 필요가 없어요.
표준 웹사이트 필드가 핫(hot) 상태여야 한다는 것은 당연합니다. 클릭 수 추적이 가능하면 좋겠습니다.
테마 컴포넌트를 통해 사용자 정의 필드를 클릭 가능하게 만들 수 있어야 한다고 생각합니다.
더블클릭, Ctrl+C, Ctrl+T, Ctrl+V, Enter
실수했어요! 메타에서 확인해 보니 제가 봤던 사용자는 웹사이트가 없었네요. 게다가 바로 아래에 있는 다른 사용자 필드 때문에 혼란을 겪었습니다. 검토를 더 쉽게 하기 위해 웹사이트 링크를 여기에 달아 두겠습니다:
이 문제를 좀 더 생각해 본 결과, 24시간 쿨링오프 기간은 작은 사이트에는 괜찮은 것 같지만, 큰 사이트에서는 사용자가 여전히 관리자들을 압도할 수 있다는 점이 걱정됩니다.
플래그를 무시할 수 있는 기간(윈도우)을 변수로 만들거나, 최소한 플러그인을 통해 설정할 수 있도록 하는 것은 어떨까요? 관리자들의 부담을 줄일 수 있는 어떤 조치라도 긍정적인 결과라고 생각합니다.
또 다른 별개의 문제: 매우 신뢰도가 높은 사용자는 단일 플래그로 게시물을 숨길 수 있는 권한을 가진 것으로 인해 ‘관리자’ 권한을 가진 것으로 인식될 수 있습니다. 단일 커뮤니티 멤버가 검열자 역할을 하지 않도록, 과거의 게시물 숨김 최소 플래그 수를 옵션으로 유지하는 것이 여전히 바람직할 수 있습니다.
네, 여러 차례 논의 끝에 최소 개수 복구에 대해 반대하지 않습니다. 다만 @featheredtoast님의 고객이 먼저 다른 조정 사항들을 시도해 보고, 이것이 실제로 도움이 될지 확신을 가졌는지 확인하고 싶습니다.
@Roman 24시간 창을 설정 가능하도록 할 수 있을까요?
여기서 완료되었습니다:
high_trust_flaggers_auto_hide_posts 설정을 통해 활성화하거나 비활성화할 수 있습니다.
cooldown_hours_until_reflag 설정(기본값 24시간)을 사용하여 구성할 수 있습니다.
