Auf meiner Seite gibt es ein Thema, das jemand (nennen wir ihn X) gepostet und dann wegen fehlerhafter Informationen gelöscht hat. Ich habe es wiederhergestellt und X gebeten, eine Korrektur unter ihren ursprünglichen Beitrag zu setzen.
Seitdem wird das Thema immer wieder gelöscht. Ich habe es bereits zweimal wiederhergestellt, und es sah zunächst in Ordnung aus, doch nach einiger Zeit erscheint es erneut als gelöscht.
Was läuft da schief?
Ist es möglich, dass der betreffende Benutzer ihn immer wieder löscht? Ich hatte schon Benutzer, die lieber Beiträge löschen, als sich der „Peinlichkeit
Überprüfen Sie Ihr Protokoll (admin/logs/staff_action_logs), um festzustellen, ob der Benutzer sie löscht. Das Protokoll zeigt die Beiträge an, die sowohl bearbeitet als auch gelöscht wurden – und von wem sie gelöscht wurden. Sie können auch auf das Informations-Symbol klicken, um weitere Details zu erhalten.
Einige Benutzer haben ihre Meinung geändert, einen Beitrag aus diesem und vielen anderen Gründen zu behalten. Manchmal ist es einfach eine dieser Situationen, in denen man fühlt, es sei besser, das zu vergessen, was man sagen wollte. Manchmal muss man ihren Grund einfach akzeptieren, auch wenn keiner genannt wird. 
Benutzer können Themen oder Beiträge jedoch nicht sofort löschen. Sie können lediglich eine 24-stündige anstehende Löschung auslösen, die als öffentliches Anliegen im Thema oder Beitrag angezeigt wird, wie folgt:
(Beitrag vom Autor zurückgezogen, wird in 24 Stunden gelöscht, sofern nicht gemeldet)
Darüber hinaus können Sie dies nur für Themen tun, wenn sie keine Antworten haben und das Thema nicht älter als 1 Tag ist.
Das passiert bei uns auch, wenn ein Thema vom System gelöscht wird, das heißt 24 Stunden nachdem ein Beitrag vom Autor gelöscht wurde, kann er nicht wiederhergestellt werden; selbst wenn wir ihn wiederherstellen, wird er nach 30 Minuten automatisch erneut gelöscht.
Ich habe mit dem Benutzer gesprochen und soweit ich das verstehe, löschen sie es nicht ständig. Sie waren tatsächlich überrascht darüber, da sie mich ursprünglich auf das Problem aufmerksam gemacht haben.
So sehen meine Logs aus:
(Danke an @JimPas für den Hinweis!)
Habt ihr Ideen? Gibt es weitere Daten, die ich bereitstellen kann, um bei der Fehlersuche zu helfen? Es scheint, als hätte @Pad_Pors etwas Ähnliches erlebt.
Hat jemand danach eine Lösung dafür gefunden? Wir erleben dasselbe.
Ein Nutzer hat einen Beitrag erstellt und gelöscht, bat um dessen Wiederherstellung, und jetzt löscht das System ihn ständig (das gesamte Thema, da es der erste Beitrag ist).
Wir könnten den Inhalt in ein neues Thema verschieben, aber dann würden alle, die der ursprünglichen URL folgen, auf eine „Seite nicht gefunden“-Seite geleitet.
Können wir das am Montag reproduzieren, @tshenry?
Hallo @AstonJ,
könntest du die Schritte zur Reproduktion bestätigen? Das ist mein aktueller Testablauf, aber ich möchte sicherstellen, dass er für dich korrekt klingt:
Falls ich etwas anders machen sollte, lass es mich bitte wissen.
Hallo Taylor – das Thema wurde bereits im April erstellt, aber es scheint folgendes passiert zu sein:
Hmm. Ich bin mir nicht ganz sicher, was im ersten Schritt genau passiert, aber wenn das Endergebnis ist, dass ein Benutzer ein Thema erstellt hat, scheint Schritt 2 unmöglich zu sein. Wenn ich als normaler Benutzer ein Thema erstelle, eine Antwort darauf schreibe und dann versuche, meinen ersten (Themen-)Beitrag zu löschen, wird der erste Beitrag nicht zur Löschung markiert – das ist so vorgesehen.
In meinem Fall war es so:
Ich bin mir nicht sicher, welche Zeiträume dabei eine Rolle spielen.
Ich kann bestätigen, dass mir das schon mehrfach passiert ist.
Soweit ich das beurteilen kann, haben Mitarbeiter keine „Wiederherstellen“-Schaltfläche für Themen normaler Benutzer, wenn diese zur Löschung geplant wurden. Nur der ursprüngliche Absender kann den Beitrag während der Wartezeit wiederherstellen. Wenn du sagst, du hast es wiederhergestellt, meinst du das nach der automatischen Löschung?
Ah ja, sorry Taylor! Ich vermute mal, sie haben den ersten Beitrag gelöscht und dann einen zweiten erstellt – was meiner Erinnerung nach möglich ist.
Das habe ich herausgefunden:
delete_removed_posts_after auf 1 geändert)Was passiert: Wenn ein Benutzer seinen eigenen Themenbeitrag löscht, wird eine Eigenschaft namens user_deleted auf true gesetzt. Es gibt einen Hintergrundjob namens DestroyOldDeletionStubs, der alle 30 Minuten ausgeführt wird. Dieser Job führt die Funktion PostDestroyer.destroy_stubs aus, die die Datenbank durchsucht und alle Beiträge löscht, bei denen user_deleted auf true gesetzt ist und deren „Lösch-Timer“ abgelaufen ist.
Das Problem: Wenn Mitarbeiter den Beitrag wiederherstellen, wird user_deleted nie auf false gesetzt. Daher wird der Beitrag beim nächsten Lauf von DestroyOldDeletionStubs erneut gelöscht.
Die Lösung: Ich bin mir ziemlich sicher, dass wir der Funktion staff_recovered eine Logik hinzufügen müssen, die user_deleted auf false setzt (user_recovered macht dies bereits). Siehe discourse/lib/post_destroyer.rb at main · discourse/discourse · GitHub
Die schnelle Lösung: Stellen Sie den Themenbeitrag wieder her und notieren Sie sich die Beitrags-ID. Gehen Sie dann zu Ihrer Rails-Konsole und führen Sie folgenden Befehl aus:
Post.find_by_id(BEITRAGS_ID).update(user_deleted: false)
Die Beitrags-ID lässt sich leicht finden, indem man .json an das Ende einer Themen-URL anhängt. Als Beispiel: https://meta.discourse.org/t/topic-keeps-getting-deleted/128013.json. Die Beitrags-ID des Themas ist 632362.
Aha, wir sollten @eviltrout beheben.
Tolle Detektivarbeit, @tshenry!
Gute Arbeit, Taylor 
Für alle anderen, die das oben genannte benötigen, musst du den Beitrag/das Thema zuerst wiederherstellen, sonst gibt find nil zurück.
Ich erlebe das Problem nach wie vor. Hat die Arbeit, user_deleted auf false zu setzen, bereits Fortschritte gemacht?
Gibt es eine schnelle Lösung oder einen Workaround für gehostete Instanzen?
Ich würde Folgendes vorschlagen: