トピックのexternal_idをプログラムで取得する方法

開発
1

皆さん、こんにちは。

プログラムでトピックのremote_idを取得する必要があります。背景としては、api.onPageChangeでスクリプトを実行しており、現在のトピック/カテゴリ/グループの情報を取得し、外部システムにAjax呼び出しを行って、さらにエンティティ固有の情報を取得しています。

(ember?) api.onPageChangeイベントが実行されており、必要な情報はすべて取得できているようですが、remote_idの値だけが取得できません（APIのフィールド名を使用しています）。

現在のコードは以下の通りです。

const topicController = api.container.lookup(“controller:topic”);
if (topicController) {
const thisTopic = topicController.get(“model”);
if (thisTopic) {
console.log(thisTopic.category.id); // 例としてのみ…完璧に動作します。

..さまざまなフィールドを取得でき、すべて正常に動作しています..Remote IDを取得する方法が見つかりません（しかし、それは必要です）。現在のページのURLに.jsonを追加するJSON呼び出しを使用して取得できることはわかっていますが、それは非効率的のように思えます..それとも間違っていますか、そのアプローチを使用すべきですか？他に何かガイダンスはありますか？

よろしくお願いします！

「いいね！」 1
2

確認ですが、お探しのフィールド名は remote_id でよろしいでしょうか？ Discourse でそのフィールドが使用されているとは認識していません。

「いいね！」 4
3

うわー.. すみません @simon （質問を見てくれてありがとう）.. API の通り、「external_id」が正しい名前です。

私が実際に正しい名前（external_id）を確認していたと思いますが、ここで質問をまとめる際にそれを誤って記憶していたようです。しかし、確認する必要があることは確かです。今はできませんが、今日の後半にここで報告します。

改めて、ありがとうございます！

「いいね！」 1
4

えっと…正しい（external_id）ではなく、間違ったフィールド/値を探していました。時間を無駄にさせてすみません…慰めになるかわかりませんが、まず自分の時間をたくさん無駄にしました :frowning: :slight_smile:

悪いニュースは、Emberモデルのどこにもexternal_idが見つからないことです。Emberには慣れていないので、ただ手探りで探しているだけです。他の非常に役立つTopic情報はたくさん見つかるのですが、external_idだけは見つかりません（Topicモデルをコンソールにログ出力し、あちこち探しました）。

何かヒントはありますか、@simon またはどなたか？ 再度感謝します。

「いいね！」 1
5

external_id は SingleSignOnRecord モデルのプロパティです。これは、DiscourseConnect を使用して外部サイト経由で Discourse にユーザーをログインさせる際に、ユーザーを外部サイトにリンクするために使用されます。もしこれをお探しの場合、Topic では利用できません。私の知る限り、Discourse はフロントエンドでは CurrentUser の external_id のみを返します。したがって、トピックの作成者の external_id を取得しようとしている場合、それは難しいかもしれません。

何を達成しようとしているのか、もう少し詳しく教えていただければ、誰かが手助けできるかもしれません。あなたがやろうとしていることよりも簡単なアプローチがあるかもしれません。

問題ありません。それが私たちのいる理由です :slight_smile:

「いいね！」 4
6

ありがとうございます。

Discourse のインスタンスを複数実行し、その上に（Discourse ではない）全体的な管理/調整システムをバックグラウンドで実行することを想定しています。トピックは次の 2 つの方法のいずれかで Discourse に追加されます。ユーザーが通常の Discourse トピック作成メカニズムを通じて追加するか、管理/調整システムが API を介して追加します。

API を介してトピックが作成される場合、通常はタスクまたは同様のワークフロー項目を表し、既に独自の非 Discourse ID があります。これを「外部 ID」と呼びましょう。

ユーザーが Discourse 内でトピックを作成する場合、Webhook をトリガーして Azure 関数を作成し、中央システム内にスタブのようなクローンを作成します（これにより、Discourse メッセージがコンテンツ、タスクなどのより広いストリームに接続されます）。したがって、ここでも Discourse トピックは間接的に一意の「外部 ID」を持つことになります。これを API を介してトピックに更新することを提案します。

各トピックがロードされると、Ajax を使用して中央システムから非 Discourse 中心の情報を取得し、トピック画面に表示するカスタム Discourse テーマコンポーネントがあります。

Discourse トピック ID を使用して Ajax 呼び出しのパラメータを設定し、一致するデータを見つけることもできますが、それを行うために「外部 ID」を使用する方が効率的です（ルックアップなどを回避するなど、複数の理由でよりクリーンです）。

「外部 ID」をカスタムフィールドに簡単に保存できます。他のデータ用に既に 1 つ持っています。しかし、Topics API には、まさに必要としているように見える「external_id」フィールドがあり、さまざまな理由でそれを使用したいと考えています。このやや重要なフィールドをレポート、エクスポート、将来の検索などに組み込みやすくなります。

Discourse API Docs のスクリーンショットを参照してください。

image
image1046×762 106 KB

これはかなり新しいフィールドだと思います。フォーラムでのアドバイスのほとんどは、現在必要としているものではない User external_id フィールドに関連しています。上記のように、トピックの Ember モデルを取得し（カスタムテーマコンポーネント内で）、それを通じてトピックに関するほぼすべての情報を取得できます…ただし、external_id フィールドは取得できません。

（上記と同様に、このサイトのどこかから借用したこのコードを使用してトピックを取得しています。現時点ではどこにあるかはわかりません。

            const topicController = api.container.lookup("controller:topic");
            if (topicController) {
                const thisTopic = topicController.get("model");

したがって、リクエストは、トピック固有の external_id フィールドがモデル（「thisTopic」）のどこかに埋め込まれているか、それともこれらの概念を誤解しており、カスタムフィールドを使用してこの外部 ID を保存すべきか（そのアプローチが機能すること、そしてどのように機能するかはわかっています！…単に、それが利用可能であれば、その明確さと将来性のある使用を好みます）ということです。

繰り返しになりますが、助けてくれてありがとう、感謝しています！

「いいね！」 1
7

以前は全く気づきませんでした。数年前に WordPress の投稿 ID を Discourse のトピックに関連付けるための同様のものを探していました。

トピックの external_id は、トピックに external_id がある場合にのみクライアント上のプロパティとして返されます。そのため、トピックにそれがない場合、null 値は取得されません。これは external_id を持つトピックで機能しています。

<script type="text/discourse-plugin" version="0.11.0">
api.onPageChange (() => {
    const c = api.container.lookup("controller:topic");
    if (c) {
        const m = c.get("model");
        if (m && m.hasOwnProperty('external_id')) {
        console.log("the external_id is ", m.external_id);
        }
    }
});
</script>
「いいね！」 3
8

そして、あっという間に「不可能」が「素晴らしい」に変わりました :slight_smile: .. 素晴らしい、これは私にとってゲームチェンジャーです。モデルが可変であるとは思いもよりませんでしたが、理にかなっています。

@simon さん、エレガントなコードスニペットも含めて、本当にありがとうございます！

「いいね！」 2