プラグインでホワイトリストに登録された「孤児」アップロードを安定して追加する方法の追加

開発
1

Discourse には、既存の Discourse モデルやアップロードをサポートするプロパティと厳密には関連付けられていないが、アップロードを保持したい状況がいくつかあります。つまり、「ホワイトリスト登録」された孤児アップロードです。

例えば、カスタムウィザードプラグインを使用して、トピック（厳密には投稿そのものではない）に関連するコンテンツをアップロードしたいという要望があります。

問題は、clean_up_uploads ジョブがすべての孤児アップロードを削除してしまうことです。このジョブの例外は、特定のサイト設定に含まれる URL に限られています。

もちろん、clean_up_uploads を無効にするか、clean_orphan_uploads_grace_period_hours を増やすことも可能です（私が時折そうせざるを得ないこともあります）。しかし、これは理想的ではありません。

もしかすると、私が気づいていないだけで、プラグインから孤児アップロードを「ホワイトリスト登録」する別の方法があるかもしれませんが、もしないのであれば、アップロードのクリーンアップ処理にそのような仕組みを追加するのは素晴らしいことだと思います。

私はこの方向性で PR を準備する用意はありますが、これが他の人にとっても問題として認識されているかどうか気になっています。

2

これは非常にぎこちないですね

reviewables については、@eviltrout が任意のオブジェクトを reviewable にリンクできる汎用メカニズムを導入しました。

アップロードについても同様のシステムに移行するのは、複数の山を動かすような大掛かりな作業になります。ただし、現在のシステムはかなり脆弱なので、動かす価値のある山だと言えます。

現時点での最も簡単な回避策は、:upload のデータ型を持つ非表示のサイト設定を作成し、それをサイト設定テーブルに追加することです。

3

はい、私もそう考えていました。ただ、アップロードごとに異なる設定を作成する必要があるため、サイト設定テーブルの乱用になってしまうという点で、この解決策はあまり気に入っていません。

本格的な解決策が整うまでの応急処置として、plugin_store_row を使用し、plugin_name が whitelisted_orphan_upload_id のような「例外」クエリに追加の例外条項を追加する PR を作成してもよろしいでしょうか？

4

このクエリはすでに非常に遅いので、ここでさらに結合を追加すると、処理が非常に重くなることを心配しています。

確実ではありませんが、まずは core に UploadRefrence(object_id, object_type, upload_id) という新しいテーブルを用意し、そこに結合するところから始めるのはどうでしょうか。少なくともその部分は軽量なので、その後でデータを移すことができます。比較的簡単な移動がいくつかありますが、投稿のアップロードだけは少し厄介でしょう。

これはチームの皆さんに任せたほうが良い作業だと思います。非常に細工が難しい作業です。

@zogstrip と @eviltrout の意見が気になります。

5

Rails の 単一テーブル継承 のことをおっしゃっていますか？レビューアブルには、すべてに共通するコアロジックがある一方で、追加のフィールドも存在するため、これは非常に適したアプローチです。

ただし、このケースでは問題の核心は、アップロード ID が至る所に散らばっており、それらが削除された際にアップロードも削除されていない点にあるようです。

ユーザーがプロフィールからアップロードを削除しても、同じアップロードの SHA1 がアプリ内の他の場所で使用されている可能性があるため、削除するのは安全ではないのでしょうか？もしそうであれば、@sam が提案した UploadReference テーブルという解決策は良いと思います。

もしアップロードがこのような形で共有されていないのであれば、それらのフィールドが NULL になった時点で削除する方が、より良い解決策になるでしょう。

6

まさにそのために UploadReference テーブルが必要なのです :+1:

実際には、Discourse の内部構造を学ぶのに非常に良いタスクだと思います。10 月初旬から @cvx にとって良いタスクになるかもしれません。ペアプログラミングをして開始し、いくつかの「小さな」タスクに適切に分割しましょう。

8

こんにちは！

UploadReference テーブルに大変興味があります。当社は、プラグイン内で多数のアップロードが存在し、それらが孤立したアップロードと見なされる状況にあります。現在の対応策としては、単に clean_up_uploads を無効化するだけです。先日確認したところ、手動で削除する必要がある孤立したアップロードが 10GB も蓄積しており、さらにそれらのうちどのファイルがプラグイン内で参照されているかを特定するスクリプトも必要となります。ここで議論されているような解決策は、私たちにとって非常に役立つでしょう。

David

9

また、話題に関連してですが、一部のケースではアップロードを単に HTML の img タグで参照しています。これにより、これらの投稿の「ベーキング」が中断され、ハイパーリンクなどの他の要素も「調理」されないようです。アップロードは一般的に upload://.png という形式で参照されているようですが、この 文字列はどこで見つけることができますか？アップロード自体には、私の確認限りでは保存されていないようです。

10

これは short url と呼ばれ、その計算方法は Upload モデルで確認できます。

11

ありがとう！よく見ていなかったみたいですね :slight_smile:

12

@angus
OPで提起された懸念に対処するため、最近このPRをマージし、upload_referencesテーブルを追加しました。

13

Custom Wizard プラグインで実装されたことをお知らせします。このシステムを追加していただきありがとうございます！