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 dies nicht so gründlich getestet wie andere hier (danke!!), aber mir scheint, dass die Lösung für das im ersten Beitrag genannte Problem ziemlich einfach ist.
Löschen von „About“-Themen durch Benutzeradministratoren (durch Website-Moderatoren/Administratoren) nicht zulassen
Wenn das Obige versucht wird, verhindern Sie es und zeigen Sie eine informative Fehlermeldung an. Ich verschiebe dies zu Bug, da es ein Fehler ist, dass die „About“-Themen in diesem Fall gelöscht werden können.
Ich habe gerade einen Testbenutzer erstellt und diesen verwendet, um eine Kategorie zu erstellen, und dann den Benutzer aus der Benutzerverwaltung gelöscht. Es erlaubte mir, den Benutzer direkt zu löschen, obwohl er ein Thema hatte. Die Autorschaft des „About“-Themas wurde dem Systembenutzer übertragen! Dieser Anwendungsfall scheint also in dieser Hinsicht ziemlich sicher zu sein.
Ich habe auch den Fall der Selbstlöschung versucht (ich muss den Benutzer zuerst herabstufen, um den Button „Konto löschen“ zu sehen). Das Löschen dieses Benutzers hat dem System ebenfalls die Autorschaft des Themas übertragen. Außerdem sehe ich, dass der Standardwert für delete user self max post count auf 1 gesetzt ist, was bedeutet, dass ein Benutzer sich standardmäßig nicht selbst löschen kann, wenn er mehr als ein Thema hat. Wir sind hier also sowieso sicher.
Und ich habe versucht, den Benutzer über die Benutzerverwaltung zu löschen. Interessanterweise habe ich, solange nur das eine „About“-Thema vorhanden war, den Button zum Löschen von Beiträgen nicht erhalten. Aber nachdem ich ein zweites Thema erstellt hatte, erhielt ich den Button zum Löschen von Beiträgen. Das Auswählen und Eingeben des langen Textes zur Bestätigung funktionierte dann – ich konnte die Beiträge des Benutzers löschen, einschließlich des „About“-Themas. Endlich ein Reproduktionsfall!
Und schließlich konnte ich das „About“-Thema auch über Massenaktionen löschen. Ein weiterer Reproduktionsfall! Ups, jetzt sehe ich, dass ich keine Reproduktion von Massenaktionen habe, die „About“-Themen löschen. Es schlägt einfach stillschweigend fehl.
Angesichts des Obigen können wir die Fälle der Benutzerlöschung (über die Benutzerverwaltung und Selbstlöschung) ignorieren, da die Autorschaft dem 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, 
).