alxndr
(Alexander)
2024 年 5 月 27 日午前 6:17
1
ユーザーがすべての投稿を削除し、そのうちの1つがカテゴリの「about」投稿でした。投稿を復元し、所有権をシステムアカウントに変更しましたが、管理者にとってはまだ「削除済み」と表示され、管理権限のないユーザーが投稿にアクセスするとエラーが表示されます。
問題の投稿(エラーが発生するもの):About the Music category - Music - KGLW.net Forum
カテゴリ:Music - KGLW.net Forum
これを修正する方法はありますか?
(このシナリオを回避するために、すべてのカテゴリの「about」投稿をシステムアカウントに割り当てるべきでしょうか?)
「いいね!」 3
こんにちは。
これが機能するかどうかわかりませんが、投稿のHTMLを再構築してみてください。3つのドットをクリックし、レンチをクリックして、「HTMLの再構築」を選択してください。
「いいね!」 1
それがどのようにして削除されたのか、まだ完全には明らかになっていません。なぜなら、「About」トピックは削除できないことになっているからです。
どのようにしてそうなったのか、もう少し詳しく教えていただけますか?彼らがそのカテゴリを作成したのでしょうか?
「いいね!」 4
Moin
2024 年 5 月 27 日午後 12:05
4
ユーザー管理ページですべての投稿を削除 ボタンを使用すると、トピックに関する情報が削除されます。(それ以外の場合は、所有権が @system に移行されます)
Alexander:
これを修正する方法はありますか?
新しいカテゴリを作成し、すべてのトピックをそこに移動してから、古いカテゴリを削除することができます。しかし、それは修正というよりは回避策です。
それは残念な回避策ですね。
テストサイトで再現したところ、削除を取り消すとすぐに元に戻ったので、この特定の問題が何であるかはわかりません。
Railsコンソールを使用して、アバウト・トピックのトピックIDを新しいものにスワップすることは可能ですが、「新しいカテゴリのスワップ」はUI経由の方が簡単なオプションかもしれません。
「いいね!」 2
Moin
2024 年 5 月 27 日午後 12:53
6
問題は、投稿を削除解除する前に所有権をシステムに変更した場合に発生します。
「いいね!」 2
手順を追って説明していただけますでしょうか。ユーザーが削除されたのではなく、投稿のみが削除されたように見えます。
「いいね!」 3
Moin
2024 年 5 月 27 日午後 3:10
8
特に残念な組み合わせの2つの問題があります。
ユーザー管理ページで「すべての投稿を削除」を使用すると、「カテゴリについて」の投稿が削除されます。(ただし、元に戻すことは可能です)
作成者が削除された投稿を削除し、投稿を元に戻す前に所有権を変更した場合、投稿を元に戻すことはできません。(回避策として、トピックを削除して元に戻すことができます。これにより、最初の投稿が元に戻ります)
したがって、以下を行うと:
テストユーザーとテストカテゴリを作成します。
テストユーザーを「カテゴリについて」トピックの所有者にします。
ユーザー管理ページからすべての投稿を削除します。
(オプション)別のトピックをテストユーザーが所有するように作成します。
(オプション)別のユーザーを使用して両方のトピックに返信します。
テストユーザーを削除します。
「カテゴリについて」トピック(および他のトピック)の所有権を変更します。
投稿を元に戻そうとします。
投稿を元に戻すことができないため、エラーが発生します。補足:トピック内の返信は他のユーザーには表示されますが、最初の投稿は表示されません。
回避策2は、「カテゴリについて」トピックは削除できないため、機能しません。
「いいね!」 6
alxndr
(Alexander)
2024 年 5 月 27 日午後 8:49
9
はい、ユーザーがカテゴリを作成したと信じています。
「HTMLの再構築」は何も変更されていないようです。
新しいカテゴリを作成して入れ替えることもできると思いますが、それは元のカテゴリを購読/ミュートなどしたユーザーが新しいカテゴリでやり直す必要があることを意味しますか?
私はRailsコンソールを恐れていないので、新しいtopic_idを割り当てることが物事を構造化するより「正しい」方法であれば、私はそれを行うことに傾いています。しかし、実行する特定のコマンドについて少し手助けしていただけると幸いです。それは Category.find(10).topic_id = 723 のようなものですか…?
一方で:
…これはより迅速な解決策かもしれませんか?(ただし、レンチアイコンメニューには「トピックを削除」ではなく「トピックをアーカイブ」しか見当たりません…)
これほど徹底的にテストしたわけではありませんが(ありがとうございます!!)、最初の投稿で述べられた問題に対する修正は非常に簡単だと思われます。
ユーザー管理で「about」トピックの削除を許可しない(サイトモデレーター/管理者による)
上記が試みられた場合、それを阻止し、情報提供のエラーメッセージを表示します。上記の場合、「about」トピックが削除できるのはバグであるため、Bug に移動します。
テストユーザーを作成し、それを使用してカテゴリを作成し、次にユーザー管理からユーザーを削除しました。ユーザーがトピックを持っていても、ユーザーを直接削除することができました。「about」トピックの作成者はシステムユーザーに引き継がれました!したがって、少なくともそのユースケースはこの点ではかなり安全なようです。
自己削除のケースも試しました(アカウント削除ボタンを表示するには、まずユーザーを降格させる必要があります)。そのユーザーを削除した場合も、トピックの作成者はシステムに引き継がれました。また、delete user self max post count のデフォルトは 1 に設定されており、デフォルトではユーザーが 1 つ以上のトピックを持っている場合、自分で削除することはできないことがわかりました。いずれにしても、この点では安全です。
そして、ユーザー管理からユーザーを削除するテストを行いました。興味深いことに、その「about」トピックが 1 つだけ存在する場合、投稿削除ボタンは表示されませんでした。しかし、2 つ目のトピックを作成した後、投稿削除ボタンが表示されました。それを選択し、確認のために長いテキストを入力すると、機能しました。ユーザーの投稿(「about」トピックを含む)を削除することができました。ついに再現しました!
そして最後に、一括操作を使用して「about」トピックを削除することもできました。これも再現しました! おっと、一括操作で「About」トピックを削除する再現はできません。サイレントに失敗するだけです。
上記を考慮すると、作成者はシステムに引き継がれるため、ユーザー削除(ユーザー管理および自己削除による)のケースは無視できます。
「いいね!」 1
Moin
2024 年 6 月 4 日午後 8:51
12
また、about投稿を別のトピックに移動しようとしました。それは機能し、削除タイマーが表示されますが、x日後にトピックは削除されません。タイマーは消えるだけです。したがって、これは正常に機能します。
「いいね!」 1
alxndr
(Alexander)
2024 年 6 月 5 日午前 1:15
15
これにより、将来的に同様の事態が発生するのを防ぐことができるかもしれません。
とはいえ、現在、ユーザーがこのカテゴリの「About」投稿を読もうとするとエラーページが表示される状況を、投稿がsystemユーザーによって所有されているにもかかわらず、どのように回復させればよいでしょうか?
JammyDodger:
@alxndr さん、状況は解決しましたか?
まだ何も試していません。「はい、それが正しいコマンドです」または「いいえ、それを実行するとすべて台無しになります」という回答を誰かがくれるのを待っていました…
「いいね!」 2
以前試した時のフォーマットはこれだと思います。
Category.where(id: CAT_ID).update(topic_id: NEW TOPIC_ID)
元のトピックをAPIで復元することも可能かどうか気になっています。
@alxndr セルフホスティングで、当社のホスティングではないことを確認していただけますか?当社のホスティングをご利用中、または当社のホスティングに切り替える場合は、当社のチームにサポートを依頼していただければ、当社の技術担当者が修正をお手伝いします。
もし私があなたの立場なら、新しいカテゴリを作成し、すべてのトピックを新しいカテゴリに移動します。それが最も簡単な方法だと思われます。
RailsコンソールやAPIを試すことにした場合、それは未知の領域ですので、変更を元に戻す必要がある場合に備えて、必ず事前にサイトの完全バックアップを行ってください!
「いいね!」 1
ハ 私のアドバイスを信用していないようですね @tobiaseigen
APIを使用することは、railsコンソールよりも安全な選択肢ですが、状況によってはこの特定のトピックを正常に復元できるかどうかは不明です。
APIが機能するかどうか確信が持てませんでした。UIで同様のことを試したところブロックされたためですが、ある程度の成功を収めることができたようです ( ).
この場合、トピックを復元するのではなく(投稿の復元オプションが試みていたこと)、投稿を復元するエンドポイントを使用しました。
/posts/POST_ID/recover
「いいね!」 4
alxndr
(Alexander)
2024 年 6 月 5 日午後 5:49
20
「この投稿を復元」ボタンは、このエンドポイントを使用しているようですが、403エラーが返され、errorThrownは空で、textStatus: "error"となります。
しかし、Web UXではなくAPI経由で同じルートを使用すると機能したということでしょうか?
テストから、復元ボタンはトピック復元エンドポイント (/t/TOPIC_ID/recover) を使用しようとして 403 エラーが発生していましたが、代わりに投稿復元バージョンを使用したところ、問題なく動作しました。
確認していただけますでしょうか。
「いいね!」 2
alxndr
(Alexander)
2024 年 6 月 5 日午後 11:44
22
JammyDodger:
念のため再確認していただけますか?
ああ、明確にしてくれてありがとう、あなたの言う通りです。
個々の投稿のIDを特定する方法がわかりません。カテゴリIDは10で、トピックIDは723だと思いますか?
更新: ああ、見つけました! article DOM要素に data-post-id があります…
APIドキュメント にこのエンドポイントが見当たりません… PUTリクエストであるべきですか?何かデータを含める必要がありますか?
更新: はい、PUTリクエストで、データなしで実行できました! @JammyDodger さん、ありがとうございました!!
「いいね!」 2