Server-tools: [RFC] context_onchange: Context key to perform onchanges

You need to define the starting field(s) that will trigger the rest of the onchanges.

Hi @lasley,

Thanks a lot for the idea and writing it out!
There are some situations where this can be valueable (such as the sales settings in Odoo V11 as we discussed).
Keeping an eye out on this one.

@pedrobaeza - you're saying this happens already in the backend as long as the fields are defined? Is it maybe that all of the fields in the onchange need to be defined?

Basically if:

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

Then

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

Would work, but not:

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

The reason I ask is that I'm seeing incredibly inconsistent application of this logic.

No, I'm not saying that it's already happening. What I'm saying that you need to specify somehow which is the field(s) value(s) that start the chain of onchanges. Something like:

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

Oh interesting, I was thinking of just using the keys that are present in the data itself. Basically just override the create and write methods, then perform the onchange if the keys are there.

Your design would allow the developer to actually restrict the onchanges, or trigger them manually even if the data doesn't contain the key. This almost seems like a "why not both" situation?

Do you have any clue if there is some sort of central onchange identification mechanism we can link to for this? I searched through base model and wasn't able to find anything that stood out. @

Imagine you pass following values on a sale order: partner_id and fiscal_position_id. I see several problems:

1. Not specifying that partner_id is the initiating one, you can call first _onchange_fiscal_position_id and then _onchange_partner_id, which is not the correct order.
2. I think you are not considering cascading onchanges. _onchange_partner_id modifies fiscal_position_id, so you should call after _onchange_fiscal_position_id.
3. If you are passing a specific fiscal_position_id, is it because you want that specific position? Then you should override the value get on first onchange for passing it to the consecutive onchanges. Or do you want to override it?

@lasley you could extend the addon 'onchange_helper' https://github.com/OCA/server-tools/tree/10.0/onchange_helper

Welp this is awesome thank you @lmignon, not sure how I missed it!

I actually think this is a better implementation now that I look at it. With my idea, we're adding the overhead of an if statement in each create/write, but with this one we don't. Both require about the same amount of code for usage as well, so absolutely a clear winner.

I think maybe I'm going to touch up the ReadMe a bit on the other one though. I think the word play is what was throwing me off.