Feedback on the new Review Queue (2019)

리뷰 큐에서 스팸 사용자를 삭제할 때 웹훅을 통해 중앙 데이터베이스에서도 해당 사용자를 제거하고 싶습니다. 하지만 웹훅을 이렇게 설정해도 이벤트가 트리거되지 않습니다. 원래 이벤트가 트리거되어야 하는 건가요, 아니면 ‘.. and when its status is updated’ 부분에 대해 오해하고 있는 건가요?

1개의 좋아요

“사용자 삭제” 웹훅이 트리거되나요?

3개의 좋아요

맞습니다. 불행히도 삭제 정보가 전달되지 않고 있으며, 사용자가 삭제되고 IP가 차단된 경우에만 특정 조치를 취하고 싶습니다.

1개의 좋아요

기본적으로 이미지가 자동으로 숨겨지도록 해 주셨으면 합니다. 특히 TL0 사용자의 신고된 게시물에 대해 그렇습니다. 각 커뮤니티의 기준에 따라 부적절한 이미지를 확인하고 조치할 필요는 있지만, 사무실 환경이나 아이들과 함께 재택근무를 하는 경우(저는 자주 그런 상황입니다)에는 이미지를 숨겨 주는 기능이 유용할 것입니다.

6개의 좋아요

검토 대기열 점수를 우회하도록 하는 API는 점수가 주기적으로 재계산되기 때문에 시간 경과에 따라 여전히 충분하지 않습니다. 검토 가능 항목이 생성될 시점에 대기열이 처리되지 않으면, модератор들이 해당 항목을 검토하기 전에 '강제’된 항목이 높은 필터가 적용된 목록에서 사라질 수 있습니다.

아마도 여기에서 점수 쿼리에 조인되는 검토 가능 항목에 대해 강제 검토(force-review)를 부울 값으로 가져야 할 것입니다.

5개의 좋아요

TL0 사용자의 이미지는 기본적으로 흐리게 처리됩니다. 이는 blur_tl0_flagged_posts_media 설정을 통해 비활성화할 수 있습니다.

이 부분도 구현되었습니다. force_review 플래그가 true로 설정되면, 최소 가시성 임계값 점수를 충족하지 못하더라도 대기 중인 reviewable이 큐에 표시됩니다.

8개의 좋아요

@Roman - 아직 이 문제에 대해 회신을 드리지 못한 점 죄송합니다. 여전히 도움이 될 수 있다면, 로그를 확보하여 일부 레코드(개인 식별 정보 제거됨)를 추출했습니다. 현재 2.6.0beta3 버전을 실행 중입니다. 모든 정수 범위 초과(integer out of range) 오류는 동일한 유형의 레코드에 대해 발생하는 것 같습니다.

2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR:  integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT:  INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
1개의 좋아요

검토 대상 목록 중 이미 검토가 완료된 항목들을 확인할 수 있는 방법도 있으면 좋을 것 같습니다. 플래그를 처리한 모더레이터별로 필터링할 수 있는 기능 말입니다. 과거에 처리된 플래그를 볼 때 “담당자” 필터를 사용하는 것은 “처리자” 필터를 찾는 것과 의미적으로 매우 유사해 보이지만, 실제로는 다릅니다.

해결된 플래그/검토 대상에 대해 “담당자” 필터를 사용할 때 플래그를 처리한 사람을 조회해야 하는지, 아니면 별도의 필터로 분리해야 하는지 어떻게 생각하시나요?

4개의 좋아요

이건 정말 좋은 제안인 것 같아요, @Roman. 목록에 추가해 주시겠어요?

5개의 좋아요

웹훅과 API를 사용해 새로운 주제를 검토 대기열(Review Queue)에 등록하고, 관리자가 해당 주제가 규정을 준수하는지 확인할 수 있도록 하고 있습니다. 현재는 API를 통해 새 주제의 첫 번째 게시물을 플래그 처리하고 있습니다. 이 방식은 작동은 하지만, 사용자의 관리자 이력을 볼 때 부정적으로 비칠 수 있습니다. 사용자가 불리해 보이지 않는 다른 방법이 있을까요?

1개의 좋아요

신뢰 수준에 따라 새 주제를 승인하는 approve new topics unless trust level을 사용할 수 없는 이유가 있나요? 이 기능은 Discourse에 기본적으로 내장되어 있습니다.

2개의 좋아요

많은 사용 사례에서 그것이 작동할 것이라는 데 동의합니다. 우리는 여러 태그 그룹에서 태그를 요구해야 하는데, 이는 Discourse에서 지원되지 않습니다. 우리는 승인 없이 새 주제를 허용하되, 시간이 허락하는 대로 태그가 올바른지 확인하기를 원합니다.

제가 제안하는 것은 검토 대기열에 임의의 항목을 배치하는 방법입니다. 현재 지원되는 유형은 세 가지입니다: 플래그된 게시물, 대기 중인 게시물, 사용자. 우리는 우리가 원하는 것에 가장 가까운 것이기 때문에 플래그된 게시물을 전용으로 사용하고 있지만, API를 통해서만 가능하더라도 검토 대기열에 “태그 검토” 항목을 배치할 수 있다면 좋겠습니다.

1개의 좋아요

원하시는 작업을 수행하는 쉬운 방법은 없습니다.

가장 좋은 방법은 새로운 검토 가능 유형을 추가하는 플러그인을 만든 다음, 이를 생성하기 위한某种의 엔드포인트를 만드는 것입니다.

1개의 좋아요

이 대화상자를 비활성화하는 방법이 있을까요? 우리는 거의 전적으로 스팸을 거부하고 있으며, 이 기능은 우리의 워크플로우에 클릭 한 번만 추가할 뿐입니다:

3개의 좋아요

같은 문제에 대해 여기에도 게시했습니다: Account rejection email - #11 by simon.

3개의 좋아요

거절 이유가 스팸인 경우, 이 다이얼로그는 확실히 필요하지 않습니다 @sam @Roman ..

2개의 좋아요

API를 통해 “User” 유형의 검토 대상(reviewable)을 검토 대기열에 추가하는 방법이 있나요? 아니면 새 사용자를 생성하는 코드에서만 접근 가능한가요?

제 사용 사례는 정책 준수를 확인하기 위해 모드가 모든 사용자 업데이트를 검토하는 것입니다. 따라서 user_updated 웹후크를 사용하고 있으며, 업데이트된 사용자를 검토 대기열에 추가하고자 합니다.

수동으로 게시물을 플래그 처리하고 네트워크 트래픽을 관찰함으로써 게시물을 플래그 처리하는 방법(/post_actions…)을 역설계할 수 있었습니다. 하지만 사용자의 경우 동일한 방법을 적용하는 법을 모르겠습니다. 아마도 /user_actions…와 유사한 구조일 것 같습니다.

1개의 좋아요

현재 API를 통해 이 작업을 수행할 방법이 없습니다. 사용자의 업데이트를 가로채서 검토 가능한 항목을 생성하는 플러그인을 추가해야 할 것 같습니다.

2개의 좋아요

2개의 게시물이 새로운 주제로 분리되었습니다: Responding to post approvals

안녕하세요. 이 글은 검토 대기열에 대한 건설적인 비판으로 의도한 것입니다.

“거부 / 승인” 버튼이 모호하지 않도록(“게시물을 승인하는 건지, 플래그를 승인하는 건지?”) 몇 가지 개선이 이루어졌다는 것을 알고 있습니다. 하지만 여전히 해당 상태에는 이중적인 의미가 있어, 이미 처리된 항목 목록을 검토할 때 상태 필터와 오른쪽 상단의 상태가 실제로는 아무 의미도 없어 꽤 혼란스럽습니다. 몇 가지 예를 들어 보겠습니다:

입력 속도가 너무 빠르다는 이유로 플래그가 걸린 게시물 승인 → 게시물 승인됨 → 상태: 승인됨

부적절한 게시물의 플래그 승인 → 게시물 거부됨 → 상태: 승인됨

프로필 스팸으로 사용자 거부 → 사용자 정지됨 → 상태: 거부됨

게시물의 플래그 거부 → 게시물 유지됨 → 상태: 거부됨

따라서 다음과 같은 상태를 구별할 필요가 있어 보이며, 일부 항목에는 두 가지가 모두 적용될 수 있습니다:

  • 사용자/게시물 승인
  • 사용자/게시물 거부
    ---
  • 조정(중재) 승인
  • 조정(중재) 거부

사용자 프로필 스팸머의 경우, 공유 IP 범위를 사용하는 경우가 많아 정당한 사용자도 같은 범위를 사용할 수 있으므로, 계정을 삭제하고 이메일을 차단하되 IP 주소는 차단하지 않는 옵션을 제공해 주시면 좋겠습니다.

1개의 좋아요