ここに、追加の検証を追加したいコードがあります。
（コードとユースケースを簡略化）
# スタッフ以外がトピックのカテゴリを変更できないようにする
PostRevisor.track_topic_field(:category_id) do |tc, category_id|
if tc.guardian.is_staff?
tc.record_change('category_id', tc.topic.category_id, category_id)
tc.topic.category_id = category_id
else
tc.topic.errors[:base] << "この種類のトピックではカテゴリを変更できません"
end
end
これにより、スタッフ以外によるカテゴリの変更は防止されますが、エラーが上位に伝達されません。
これは以前は機能していました。
ただし、このプラグインはその後アーカイブされました。
この要件は、APIによってサポートされるべきではないでしょうか？
あなたは私よりもこの種のことに詳しいと思いますが、Railsはこれを上に伝える必要はないと思います。なぜなら、Emberはユーザーが選択すべきではないカテゴリを選択できないようにすると予想されるからです。ですから、フロントエンドが、ユーザーがそうするべきでない場合にカテゴリを変更できないようにして、PostRevisorがこの不快な状況に直面しないようにしていることを確認してみてはどうでしょうか？
はい、承知いたしました。それは考慮すべき点です。
APIエンドで制限してから、フロントエンドで制限するのが良いプラクティスです。つまり、不正なアクションを防ぐためにフロントエンドだけに頼るべきではありません。
さらに、フロントエンドはActive Recordのエラーを伝えるべきです。
そのため、APIでこれを実行することは重要です。
同意します。Railsにそれを強制させたいのです。
要件を強制していて変更を拒否していると思っていましたが、フロントエンドに十分なエラーを提供していなかっただけでした。
はい、おっしゃる通りです。
カテゴリの変更を防ごうとしているだけで、UIはメタデータをすべて変更するか、まったく変更しないように設計されているため、あまり役に立ちません。
そのため、エラーがバブルアップされると非常に便利です。
.gjsテンプレートの堅牢性により、このような変更は現在非常に困難になっています。
このテンプレートはまだhbsですが、明らかな理由からオーバーライドしたくありません。
CSSハックを試してみます。
また、あなたは私よりもその点については得意ですが、カテゴリセレクターを非表示にすることは可能だと思いますそれは機能しないようです。
したがって、カテゴリシリアライザーをハックして、カテゴリを送信しないようにするのが良いかもしれません。ただし、トピックを作成するときではなく、編集するときにのみハックする方法を見つける必要があるため、これは難しいでしょう。
「ハック」が機能しました 
:
それでも、サーバーからの詳細で合理的な応答、特にActive Recordを活用した応答が欲しいです。
私もこの動作に遭遇し、途方に暮れていました。まだフロントエンドがないため、開発とテストはすべてAPIリクエスト経由で行っています。そのため、成功のように見える応答を受け取ったときは混乱しました。ガードが完全に機能していないと思っていましたが、デバッガーを最小限にまとめて、ステッパーを苦労して通過しました。
編集：
ふむ…環境を完全に再起動することにしました。すると、API応答でエラーメッセージが返されるようになりました。