좋은 지적입니다! 일반 사용자로서 제 자신의 토픽을 삭제하려고 하면, 실제로 토픽이 닫히기는 하지만 삭제됨을 알리는 작은 액션 게시글이 생성되지 않습니다(이 동작은 코드에서 여기에서 수행됩니다). 삭제 대상으로 표시했던 토픽을 복구해도 역시 작은 액션 게시글이 생성되지 않습니다. 이 동작 자체는 저에게는 문제가 없어 보입니다.
여기서 변수인 것 같아 보이는 부분은 модератор(관리자)들입니다. 그들이 무엇을 하고 있으며, 왜 그렇게 하는지 알아봐야 할 것 같습니다.
@Fabby 님, Configuring VPN using nmcli - Network - Manjaro Linux Forum 에 제가 볼 수 없는 수정 사항이 있습니다. 수정의 성격을 확인해 주시겠습니까? “(작성자에 의해 토픽 삭제됨)” 상황이었나요?
그 게시글이 #support에서 #network 카테고리로 재분류된 것만 볼 수 있습니다…
관리자 활동 기록에는 다른 내용이 없고, 사용자 노트도 없으며… 다만 관리자가 게시글을 "열어"야 했다는 것뿐입니다. (다시 여는 것이 아니라, 그냥 열림)
여전히 발생하고 있으며, 발견할 때마다 계속 추적하고 있습니다. 다음에는 복구하지 않고 삭제된 항목에 대해 알려드리는 것이 좋을까요?
원하시면 관리자로 승격해 드릴 수 있으니, 직접 상황을 확인해 보실 수 있습니다…
저희 관리자가 이를 닫지 않았다고 확신합니다.
포럼을 지켜본 결과, 원포스터가 원본 게시글을 삭제한 것과 관련이 있는 것 같습니다. 시스템이 어떤 이유로 나중에야 게시글을 삭제하거나 숨기는 것 같습니다. 시스템 기록 없이 스레드가 잠금 상태로 표시되어 혼란을 초래하고 있습니다.
이 문제의 원인이 무엇인지, 그리고 잠긴 스레드가 고신뢰도(TL4) 사용자만 볼 수 있는지 확실하지 않습니다. 제가 관찰해 온 패턴입니다.
디버깅에 도움이 되길 바랍니다!
수정: 또한 이 잠긴 OP(원포스터) 게시글들에는 답글이 하나도 없다는 점도 확인했습니다. 따라서 게시글이 생성된 직후 짧은 시간 내에 삭제되었을 것입니다.
사용자가 자신의 주제를 삭제한 경우라면, 이는 버그가 아니라고 생각합니다. 답변이 없는 한 자신의 주제를 '삭제’할 수 있습니다. 이는 OP(게시자)가 아닌 자신의 다른 게시물에 휴지통 아이콘을 사용하는 것과 유사한 방식으로 작동합니다(먼저 텍스트가 '저자 삭제됨’으로 대체되고, 24시간 후 게시물이 숨겨집니다).
일반 사용자이고 스태프/모더레이터/관리자 등이 아니라면, 게시물 아래에 작은 액션(버튼)이 표시되지 않습니다.
방금 try.discourse.org에서 만든 예시입니다(다만 데모 사이트는 하루가 끝나면 초기화되므로, 이 글을 읽을 때는 이미 사라져 있을 수 있습니다 
)
https://try.discourse.org/t/deleted-topic-deleted-topic/1403
지금 몇 시인지 모르겠네요 (제가 그 글을 읽었을 때 이미 9시간 이상 지난 글이었거든요), 하지만 제 화면에는 이렇게 보입니다:
어제 제가 직접 확인했을 때는 응답이 있는 상태였기 때문에, 확실히 "그것"이 아닙니다
저는 영국 시간(BST)을 사용하고 있지만, 데모 사이트의 일일 리셋이 언제 이루어지는지 확신이 없었습니다. 어차피 24시간 후면 해당 주제가 사라졌을 테니, 스크린샷을 찍어두는 것이 나았을지도 모르겠네요.
하지만 결국 그 주제의 이전 내용에서 이미 언급된 것을 반복한 것이었으니, 제 실수였습니다.
잘 해결하시길 바랍니다. 
이 문제를 제대로 파헤치려면 더 많은 정보가 필요합니다. 몇 가지 더 시도해 볼 의향은 있지만, 현재로서는 참고할 자료가 별로 없습니다. 익명 사용자로 토픽을 살펴보는 것만으로는 이 시점에서 유용한 정보를 얻기 어렵다고 생각합니다. Marketplace 채널에서 로그, 사이트 설정, 데이터베이스를 직접 확인해 문제를 파악할 수 있는 사람을 찾아보시는 것이 좋을 것 같습니다.
@littleviolette 님의 사이트에서 수정 이력이 숨겨져 있나요? 이 토픽의 OP(원문)에 있는 스크린샷을 보면, 내용이 모두 남아 있고 타임스탬프 옆에 수정 아이콘이 없으므로 본인이 삭제한 토픽으로 보이지 않습니다. 만약 본인이 삭제했다면 “작성자 삭제”라는 표시와 수정 이력이 표시되어야 합니다.
@Fabby 님, 현재로서는 Fabby 님과 littleviolette 님이 동일한 문제를 겪고 있는지 확실하지 않습니다. littleviolette 님의 답변 중 일부에 따라 몇 가지 제안을 검토하지 않기로 하셨던 부분이 있었기 때문에, 다시 돌아가서 질문드리고 싶습니다. 다음 인용문에 대한 후속 조치가 있나요:
또한 API를 사용하시거나 다른 서비스와 연동 기능을 실행하고 계신지도 알고 싶습니다.
두 분 모두 이 토픽이 시작된 이후로 관찰하신 모든 것을 바탕으로 문제의 핵심을 다시 요약해 주시면 감사하겠습니다. 모든 내용을 따라가기 조금 어려워지고 있어서, 테스트할 때 참고할 수 있는 요약이 있으면 정말 좋습니다.
Taylor님,
현재 2.8.0.beta4 버전을 실행 중이며, 문제가 여전히 발생하고 있습니다.
오늘의 플러그인 목록:
| 이름 | 버전 | 활성화 여부 | |
|---|---|---|---|
| Discourse-auto-deactivate | 비활성 사용자를 자동으로 비활성화하여 다시 로그인하려면 이메일을 재확인하도록 합니다 | 0.0.1 | 예 |
| discourse-chat-integration 이 플러그인은 | Discourse를 여러 채팅 제공업체와 통합합니다 | 0.1 | 예 |
| discourse-fingerprint | 관리자가 인터넷 트롤을 대응하는 데 도움이 되도록 사용자 지문을 계산합니다. | 2 | 예 |
| discourse-push-notifications | Chrome 및 FireFox 푸시 알림을 통합하는 플러그인 | 0.3.0 | 예 |
| discourse-solved 답변에 해결됨 버튼을 추가합 | 니다 | 0.1 | 예 |
| discourse-user-notes | 스태프가 사용자에게 메모를 첨부할 수 있는 기능을 제공합니다 | 0.0.2 | 예 |
| docker_managerdocker_manager | Discourse 이미지용 Docker 매니저 | 0.1 | 예 |
| procourse-installer | 다른 Discourse 플러그인을 발견하고 설치하기 위한 Discourse 플러그인. | 0.1 | 예 |
| retort | Discourse용 리액션 플러그인 | 1.2.3 | 예 |
| styleguide | Discourse에서 위젯이 어떻게 스타일링되는지 미리 보기 | 0.2 | 아니오 |
첫 게시물에 대한 무제한 편집 활성화: 문제가 여전히 발생하고 있습니다
해당 시간대에 대해 필터링하면 아무것도 볼 수 없습니다: 시스템, discobot, 모더레이터 활동이 없습니다. (discobot을 필터에서 제외할 수 있으면 좋겠습니다!)
이 말의 의미를 이해하지 못하겠습니다: 문제 정의와 위의 요약을 게시하고 로그, 사이트 설정, 데이터베이스를 깊이 조사하여 실제로 무슨 일이 일어나고 있는지 파악할 수 있는 사람을 요청하는 주제를 거기에 올리는 것인가요???
Discourse에 우리가 스스로 이 문제를 조사할 수 있도록 해주는 기술 정보(HTML / Wiki / PDF 매뉴얼; 동영상은 안 됩니다!)가 있습니까? 여기에는 Nerd(네드)와 Geek(기크)들이 다수 있으며(대문자로 강조), 저희 모더레이터 팀에는 PostgreSQL, 네트워킹, 가상화, 개발자, *nix 엔지니어링, Windows 전문가들이 있습니다…
데이터베이스의 topics 테이블을 살펴보면 토픽이 닫힌 정확한 시점을 파악할 수 있을 것입니다(예: updated_at 컬럼을 검사하는 것). 과거로 돌아가 확인할 수 있도록 토픽 테이블의 내용을 주기적으로 덤프하는 스크립트를 실행하는 것도 좋은 방법입니다. Postgresql 복제 로그를 설정해 두었다면 이를 활용할 수도 있습니다.
이후 이를 유발한 원인이 무엇인지 찾아야 합니다. 이는 Sidekiq 작업(해당 시간대에 어떤 작업이 실행되었는지 확인하기 위해 Sidekiq 작업 큐를 검사해야 함), 사용자 작업(production.log 또는 nginx 로그 파일을 검사해야 함), 또는 API를 호출하는 외부 행위자(API 클라이언트, Zapier 등; 이 역시 production.log 또는 nginx 로그 파일에서 찾을 수 있음)일 수 있습니다.
Richard,
제가 Discourse에 대해 아는 것은 다음과 같습니다:
여기서 좀 혼란스럽네요.
앞서 말씀하신 것처럼
이렇게 하시면 제가 말씀드린 내용을 파악할 수 있지 않을까요?
어쨌든, 저는 그런 문서를 가지고 있지 않습니다. 그리고 그렇게까지 손을 잡아줘야 한다면, Taylor의 제안을 따르고 결국 Marketplace 게시판에 게시하시는 것이 좋겠습니다. "owner(소유자)"라는 역할은 없으며, 시스템 수준의 접근 권한(즉, Discourse 외부, 시스템 자체에서)이 필요합니다.
감사합니다. 이제 더 명확해졌어요. 이 대화의 요약을 지역 모더레이터 게시판에 올리고 어떤 반응이 나올지 지켜볼게요.
@tshenry ,
다시 연락 주셔서 감사드리며, 답변이 늦은 점 사과드립니다. 지금까지 확인한 사항은 다음과 같습니다:
원본 게시글 생성: 2021년 8월 26일 오후 6:34
시스템에 의해 원본 게시글 삭제: 2021년 8월 27일 오후 6:41
원본 게시글 생성: 2021년 7월 31일 오후 5:48
시스템에 의해 원본 게시글 삭제: 2021년 8월 1일 오후 6:02
오늘 이 스레드의 OP에 게시한 토픽의 스크린샷 예시는 다음과 같습니다:
우리 포럼 설정에 관해:
solved topics auto close hours(해결된 토픽 자동 종료 시간)가 설정되어 있지 않습니다.2.8.0.beta6 버전을 실행 중이며, 2일 전에 업데이트했습니다. 최근 이러한 비정상적인 자동 종료 동작에 대한 보고는 없었습니다. 다시 확인되면 보고드리겠습니다.도움 주셔서 감사합니다!
보고드립니다:
최근 같은 작성자가 작성한 두 개의 스레드가 시스템 기록 없이 자동 종료된 것을 발견했습니다. 즉시 해당 작성자에게 연락하여 게시글을 삭제했는지 확인했고, 작성자는 그렇다고 답했습니다. 해당 카테고리는 자동 종료 타이머가 설정되어 있지 않은 상태였습니다.
이 문제는 작성자가 첫 번째 게시글을 삭제한 것과 관련이 있을 것으로 추정됩니다. 다만, 이번에는 스레드를 다시 열었을 때 원래 게시글이 24시간 후에도 삭제되지 않았습니다. 이유를 정확히 알 수는 없지만, 문제 해결이 가능한 분들을 위해 이 정보가 도움이 되길 바랍니다.
감사합니다!
@tshenry 디버깅에 도움이 될 수 있으니 참고해 주세요. 이 문제는 저희 discourse.group 포럼에서도 두 번 발생했습니다. 이상하게 잠겨 있는 주제(이미 다시 열림)에 대한 링크입니다: https://igraph.discourse.group/t/how-should-i-do-for-reducing-graph-object-memory-usage/909
이 문제에 대해 Discourse Meta에서 질문을 남겼습니다:
수정: 게시글을 작성한 사용자가 해당 글을 삭제하려고 할 때 이러한 현상이 발생하는 것 같습니다. 삭제된 게시글은 외부 시청자에게 잠겨 있는 것으로 표시되며, 실제로 삭제된 것이 아니라 단순히 잠겼다는 안내는 없습니다. 다행히도 게시글을 작성한 사람은 삭제를 취소함으로써 이를 "잠금 해제"할 수 있습니다. 자세한 내용은 위에 링크된 주제를 참고하세요.
오, 정말 유망해 보이네요! 요즘 다른 일들로 정신이 없었어서 다시 깊이 파고들 기회가 없었습니다. 이번 주에 다시 한번 시도해 볼게요. 여러분이 공유해 주신 훌륭한 정보 덕분에 개발팀에 전달할 확실한 재현 단계를 만들 수 있기를 희망합니다.
이 문제를 해결하는 데 도움을 주신 모든 분들께 감사드립니다!
수정: 이번 주에는 시간이 부족했지만, 다음 주에는 최우선으로 처리할 예정입니다.
안녕하세요 @IAmGav 
이 문제를 재현하기 위해 취하신 모든 단계를 확인해 주시겠어요? 지금은 아무리 사소한 디테일도 중요해요! try.discourse.org에서 여러 번, 여러 가지 방법으로 트리거를 시도해 보았지만 성공하지 못했습니다. 혹시 거기서 재현이 가능할까요?
사용자 측에서 시도해 본 주요 사항은 다음과 같습니다:
지금까지 모든 경우에서 게시글에 편집 이력이 표시되고, 내용이 "(주제 작성자가 삭제함)"으로 대체되었습니다.
관리자 측 상황을 파악하기 위해 @szhorvat와도 연락 중이며, 흥미로운 사이트 설정 구성이 있는지 확인해 보고 있습니다.
try.discourse에서 시도해 봤고, 예상한 대로 동작했습니다.
어젯밤 테스트용으로 만든 사이트에서도 시도해 봤는데, 이那里도 잘 작동했습니다.
그러니까 그 사이트 쪽에 문제가 있는 것 같습니다.
사이트에서 문제를 재현하기 위해 수행한 단계를 나열합니다.
이렇게 간단합니다.
