Server-tools: [RFC] context_onchange：onchangesを実行するためのコンテキストキー

残りのonchangesをトリガーする開始フィールドを定義する必要があります。

こんにちは@lasley 、

アイデアとそれを書いてくれてありがとう！
これが価値のある状況がいくつかあります（前述のOdoo V11の販売設定など）。
これに目を光らせてください。

@ pedrobaeza-フィールドが定義されている限り、これはバックエンドですでに発生していると言っていますか？ onchangeのすべてのフィールドを定義する必要があるのでしょうか？

基本的に次の場合：

@api.onchange('a_field', 'b_field')

それで

model.create({'a_field': 'a', 'b_field': 'b'})

動作しますが、動作しません：

model.create({'a_field': 'a'})
# OR
model.create({'b_field': 'b'})

私が尋ねる理由は、このロジックの信じられないほど一貫性のないアプリケーションを見ているからです。

いいえ、私はそれがすでに起こっていると言っているのではありません。 私が言っていることは、onchangesのチェーンを開始するフィールド値をなんとかして指定する必要があるということです。 何かのようなもの：

record.with_context(do_onchange=['field_a', 'field_b']).write(data)

興味深いことに、データ自体に存在するキーを使用することだけを考えていました。 基本的には、 create writeメソッドと

あなたのデザインは、開発者が実際にonchangesを制限したり、データにキーが含まれていなくても手動でトリガーしたりできるようにします。 これはほとんど「なぜ両方ではない」状況のように思えますか？

このためにリンクできる中央の変更識別メカニズムがあるかどうか、何か手がかりはありますか？ ベースモデルを検索しましたが、目立つものは見つかりませんでした。 @

受注で次の値を渡すと想像してください： partner_idおよびfiscal_position_id 。 いくつかの問題があります。

1. partner_idが開始元であることを指定しない場合、最初に_onchange_fiscal_position_idを呼び出し、次に_onchange_partner_idを呼び出すことができますが、これは正しい順序ではありません。
2. カスケードオンチェンジを検討していないと思います。 _onchange_partner_idはfiscal_position_id _onchange_partner_id変更するため、 _onchange_fiscal_position_id後に呼び出す必要があります。
3. 特定のfiscal_position_idを渡す場合、それはその特定の位置が必要なためですか？ 次に、値get on first onchangeをオーバーライドして、連続するonchangesに渡す必要があります。 それともオーバーライドしますか？

@lasleyアドオンを拡張できます 'onchange_helper' https://github.com/OCA/server-tools/tree/10.0/onchange_helper

ウェルプこれは素晴らしいですありがとう

私がそれを見ると、これは実際にはより良い実装だと思います。 私の考えでは、作成/書き込みごとにifステートメントのオーバーヘッドを追加していますが、これでは追加しません。 どちらも使用するためにほぼ同じ量のコードを必要とするので、絶対に明確な勝者です。

でも、もう一方のReadMeを少し修正するつもりかもしれません。 playという言葉が私を失望させたものだと思います。