もちろん、@Osama さん、小さめのタスクです。テストとパフォーマンスにはご注意ください。topic_query は非常に複雑になります。
優先度は低く、緊急性はまったくありません。
「いいね！」 4
私はここでやり取りされている内容を読み、この発言（このアプローチが決定され、実装されたことを示唆するもの）まで追って読んでいます。しかし、ピンを外して再度ピン付けすることによる順序の入れ替えは観察されていません。
何か明らかな見落としがあるのでしょうか？
追記：実際には、この操作はトピックが「クローズ」されているかどうかの影響をまだ受けていることに気づきました。そのため、トピックを開くことで問題が解決したようです。
ケニー、私の提案は依然として @Osama のリストに残っています。今後 2 週間ほどでこれを整理します。
「いいね！」 2
皆様、こんにちは。コミュニティの更新後、この変更にお気づきになった方もいらっしゃるかと思います。私たちの利用ケースでは、この新しい動作は非常に最適とは言えません。管理者セクションの設定を通じて、以前の動作に戻すオプションを設けることは可能でしょうか？
Discourse をもっと長く使っていたら、これはバグとして報告したかもしれません。この変更は「以前の挙動は望ましくない」という前提に基づいて行われていますが、管理者や一般ユーザーが慣れ親しんだ挙動を削除しており、それが望ましいかどうかは人それぞれです。
さらに、この機能の説明からは「管理者が順序をより細かく制御できるようにする」ことが目的であるように感じられますが、ピン留めの順序を変更できるのがピン留め解除と再ピン留めだけという点で、完全とは言い難い印象を受けます。
ピン留めの順序は、カテゴリレベルの設定として実装すべきだと考えます。bumped_at と pinned_at のどちらを基準にするかを選択できるオプションを設け、既存の管理者に影響を与えない比較的単純な変更として、デフォルトは bumped_at にするのが良いでしょう（ただし、多言語化の観点からは簡単ではないことは承知しています）。
長期的には、fixed category positions を使用したカテゴリの並べ替え UI と同様に、ピン留めの順序を並べ替えられる UI を備えた「ピン留め位置を固定する」チェックボックスを実装すべきだと考えています。
「いいね！」 3
100% 同意です。当社の場合、この最新の更新により悪影響が出ています。API を介してエンゲージメントに基づきトピックを動的にグローバルにピン留めまたはピン留め解除しているためです。現在、ユーザーは他のユーザーが最後に返信したピン留めトピックを確認できなくなりました。ピン留めセクション全体が動的ではなく静的になったためです。
「いいね！」 1
今回の変更により、コミュニティのエンゲージメントがすでに急激に低下しています。この機能に関する設定を設け、必要に応じて以前の動作に戻すことは可能でしょうか？それとも、この変更をコアからパッチで修正する必要があるのでしょうか？
このトピックは10日後に自動的に閉鎖されました。新しい返信は許可されていません。