Ein Benutzer hat alle seine Beiträge gelöscht, von denen einer der „About“-Beitrag für eine Kategorie war. Wir haben den Beitrag wiederhergestellt und die Inhaberschaft auf das Systemkonto geändert. Er wird jedoch für einen Administrator immer noch als „gelöscht“ angezeigt und zeigt einen Fehler an, wenn ein Nicht-Administrator den Beitrag besucht:
Ich bin mir nicht sicher, ob das funktionieren würde, aber versuchen Sie, das HTML des Beitrags neu zu erstellen. Sie können dies tun, indem Sie auf die 3 Punkte klicken –\u003e Schraubenschlüssel –\u003e „HTML neu erstellen“.
Wenn Sie die Schaltfläche Alle Beiträge löschen auf der Admin-Seite des Benutzers verwenden, wird das Thema “Über” gelöscht. (In anderen Fällen wird das Eigentum auf @system übertragen)
Sie könnten eine neue Kategorie erstellen und alle Themen dorthin verschieben und die alte Kategorie löschen. Aber das ist eher ein Workaround als eine Lösung.
Ich habe es gerade auf meiner Testseite reproduziert und das Rückgängigmachen hat es sofort wiederhergestellt, daher bin ich mir nicht sicher, was dieses spezielle Problem ist.
Es ist möglich, die topic_id des „Über“-Themas mit der Rails-Konsole auf eine neue zu ändern, aber die „neue Kategorie-Umstellung“ ist möglicherweise eine einfachere Option über die Benutzeroberfläche.
Ich brauche vielleicht eine Schritt-für-Schritt-Anleitung, um sicherzustellen, dass wir dasselbe tun. Es sieht so aus, als ob der Benutzer gelöscht und nicht nur die Beiträge?
Es gibt zwei Probleme, die in Kombination besonders unglücklich sind.
Wenn Sie auf der Admin-Seite des Benutzers “Alle Beiträge löschen” verwenden, wird der Beitrag “Über die Kategorie” gelöscht. (Sie können ihn jedoch wiederherstellen)
Wenn Sie Beiträge gelöscht haben, bei denen der Autor ebenfalls gelöscht wurde, und Sie den Besitz ändern, bevor Sie den Beitrag wiederherstellen, können Sie den Beitrag nicht wiederherstellen. (Als Workaround können Sie das Thema löschen und wiederherstellen. Dadurch wird der erste Beitrag wiederhergestellt)
Wenn Sie also:
einen Testbenutzer und eine Testkategorie erstellen,
den Testbenutzer zum Besitzer des Themas “Über die Kategorie” machen,
alle seine Beiträge von der Admin-Seite des Benutzers löschen,
(optional) ein weiteres Thema erstellen, das dem Testbenutzer gehört,
(optional) beide Themen mit einem anderen Benutzer beantworten,
den Testbenutzer löschen,
den Besitz des “Über”-Themas (und des anderen Themas) ändern,
versuchen, die Beiträge wiederherzustellen,
erhalten Sie einen Fehler, da Sie den Beitrag nicht wiederherstellen können. Nebenbemerkung: Die Antworten in den Themen sind für andere Benutzer sichtbar, aber sie können den ersten Beitrag nicht sehen.
Ja, ich glaube, der Benutzer hat die Kategorie erstellt.
„HTML neu erstellen“ scheint nichts geändert zu haben.
Ich nehme an, wir könnten eine neue Kategorie erstellen und einen „Switcheroo“ machen, aber würde das bedeuten, dass Benutzer, die die ursprüngliche Kategorie abonniert/stummschaltet/was auch immer haben, dies mit der neuen wiederholen müssten?
Ich habe keine Angst vor der Rails-Konsole. Wenn also die Zuweisung einer neuen topic_id der „korrektere“ Weg ist, Dinge zu strukturieren, neige ich dazu, dies zu tun. Aber ich würde eine Anleitung für die spezifischen Befehle schätzen, die ausgeführt werden sollen. Wäre es so etwas wie Category.find(10).topic_id = 723…?
Andererseits:
…vielleicht ist dies ein schnellerer Weg, um das Problem zu lösen? (Obwohl ich im Menü des Schraubenschlüsselsymbols nur „Thema archivieren“ und nicht „Thema löschen“ sehe…)
Ich habe das nicht so gründlich getestet wie andere hier (danke!!), aber es scheint mir, dass die Lösung für das im ersten Beitrag beschriebene Problem ziemlich straightforward ist.
Das Löschen von “Über”-Themen in der Benutzerverwaltung (durch Site-Moderatoren/Admins) nicht erlauben
Wenn das oben Genannte versucht wird, verhindern und eine informative Fehlermeldung anzeigen. Ich verschiebe dies zu Contribute > Bug, da es ein Bug ist, dass die “Über”-Themen in dem oben genannten Fall gelöscht werden können.
Ich habe gerade einen Testbenutzer erstellt und damit eine Kategorie angelegt, und dann den Benutzer über die Benutzerverwaltung gelöscht. Es erlaubte mir, den Benutzer direkt zu löschen, obwohl er ein Thema hatte. Die Autorenschaft des “Über”-Themas wurde dem Systembenutzer übertragen! Also scheint dieser Anwendungsfall in dieser Hinsicht zumindest ziemlich sicher zu sein.
Ich habe auch den Selbstlöschungsfall ausprobiert (man muss den Benutzer zuerst degradieren, um den Button zum Löschen des Kontos zu sehen). Das Löschen dieses Benutzers übertrug ebenfalls die Themenautorenschaft auf das System. Außerdem sehe ich, dass der Standardwert für delete user self max post count auf 1 gesetzt ist, was bedeutet, dass es standardmäßig nicht möglich ist, dass sich ein Benutzer selbst löscht, wenn er mehr als ein Thema hat. Also sind wir hier sowieso sicher.
Und ich habe das Löschen des Benutzers über die Benutzerverwaltung getestet. Interessanterweise erhielt ich den Button zum Löschen von Beiträgen nicht, solange es nur das eine “Über”-Thema gab. Aber nachdem ich ein zweites Thema erstellt hatte, erhielt ich den Button zum Löschen von Beiträgen. Die Auswahl und Eingabe des langen Bestätigungstexts funktionierte dann – ich war in der Lage, die Beiträge des Benutzers einschließlich des “Über”-Themas zu löschen. Endlich ein Reproduzierungsfall!
Und schließlich konnte ich das “Über”-Thema auch über Massenaktionen löschen. Noch ein Reproduzierungsfall! Oops, jetzt sehe ich, dass ich keinen Reproduzierungsfall für das Löschen von “Über”-Themen über Massenaktionen habe. Es scheitert einfach stillschweigend.
Angesichts des oben Genannten können wir die Fälle des Benutzerverlöschens (über Benutzerverwaltung und Selbstlöschung) ignorieren, da die Autorenschaft an das System übertragen wird.
Ich habe auch versucht, den „Über uns“-Beitrag in ein anderes Thema zu verschieben. Es funktioniert und dann erscheint ein Lösch-Timer, aber das Thema wird nach x Tagen nicht gelöscht. Der Timer verschwindet einfach. Das funktioniert also.
Dies könnte verhindern, dass es in Zukunft geschieht.
Wie kann ich die Situation jetzt wiederherstellen, in der Benutzer eine Fehlerseite sehen, wenn sie versuchen, den „Über uns“-Beitrag für diese Kategorie zu lesen, obwohl der Beitrag dem Benutzer system gehört?
Ich habe noch nichts versucht; ich hoffte, dass jemand mit „Ja, das ist der richtige Befehl“ oder „Nein, tu das nicht, das wird alles ruinieren“ zuerst etwas dazu sagt…
@alxndr Können Sie bestätigen, dass Sie selbst hosten und nicht auf unserem Hosting sind? Wenn Sie auf unserem Hosting sind oder zu unserem Hosting wechseln, können Sie sich an unser Team wenden, um Unterstützung zu erhalten, und einer unserer technischen Mitarbeiter wird Ihnen helfen, dies zu beheben.
Wenn ich in Ihrer Position wäre, würde ich einfach eine neue Kategorie erstellen und alle Themen in die neue Kategorie verschieben. Das scheint am einfachsten zu sein.
Wenn Sie sich entscheiden, mit der Rails-Konsole oder der API zu experimentieren, betreten Sie Neuland. Stellen Sie also sicher, dass Sie zuerst eine vollständige Sicherung Ihrer Website erstellen, falls Sie die Änderung rückgängig machen müssen!
Ha Du scheinst meinem Rat nicht zu trauen, @tobiaseigen
Die Verwendung der API wäre eine sicherere Option als die Rails-Konsole. Es ist nur nicht klar, ob sie dieses spezielle Thema aufgrund der Umstände erfolgreich wiederherstellen würde.
Ich war mir nicht sicher, ob die API funktionieren würde, da ähnliche Versuche in der Benutzeroberfläche blockiert wurden, aber ich scheine einige Erfolge erzielt zu haben ().
In diesem Fall habe ich den Endpunkt verwendet, um den Beitrag wiederherzustellen, anstatt das Thema wiederherzustellen (was die Option „Wiederherstellen“ im Beitrag zu tun versuchte):
Die Schaltfläche „Diesen Beitrag wiederherstellen“ scheint diesen Endpunkt zu verwenden, gibt jedoch einen 403-Fehler zurück, wobei errorThrown leer ist und textStatus: "error" lautet.
Sagen Sie jedoch, dass die Verwendung derselben Route über eine API und nicht über die Web-Benutzeroberfläche funktioniert hat?
Bei meinem Test hat der Undelete-Button versucht, den Topic-Recovery-Endpunkt (/t/TOPIC_ID/recover) zu verwenden und hat einen 403er ausgelöst. Aber es schien zu funktionieren, als ich stattdessen die Post-Recovery-Version verwendet habe.
Ich bin mir nicht sicher, wie ich die ID des einzelnen Beitrags identifizieren kann; die Kategorie-ID ist 10 und ich glaube, die Themen-ID ist 723? Update: Aha, gefunden! Es gibt eine data-post-id im \u003carticle\u003e DOM-Element…
Ich sehe diesen Endpunkt nicht in den API-Dokumenten… sollte es ein PUT sein? mit Daten? Update: ja ein PUT, ohne Daten — es hat funktioniert! Vielen Dank @JammyDodger !!
Du scheinst meinem Rat nicht zu trauen, 
).