Server-tools: [RFC] context_onchange: clave de contexto para realizar cambios

Debe definir el (los) campo (s) de inicio que activarán el resto de los cambios.

Hola @lasley ,

¡Muchas gracias por la idea y por escribirla!
Hay algunas situaciones en las que esto puede ser valioso (como la configuración de ventas en Odoo V11 como comentamos).
Manteniendo un ojo en este.

@pedrobaeza : ¿estás diciendo que esto ya sucede en el backend siempre que los campos estén definidos? ¿Es posible que todos los campos del cambio deban definirse?

Básicamente si:

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

Luego

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

Funcionaría, pero no:

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

La razón por la que pregunto es que veo una aplicación increíblemente inconsistente de esta lógica.

No, no digo que ya esté sucediendo. Lo que estoy diciendo es que debe especificar de alguna manera cuáles son los valores de los campos que inician la cadena de cambios. Algo como:

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

Oh, interesante, estaba pensando en usar las claves que están presentes en los datos en sí. Básicamente, simplemente anule los métodos create y write , luego realice el cambio si las claves están allí.

Su diseño permitiría al desarrollador restringir realmente los cambios o activarlos manualmente incluso si los datos no contienen la clave. Esto casi parece una situación de "¿por qué no ambos"?

¿Tiene alguna idea de si existe algún tipo de mecanismo central de identificación de cambios al que podamos vincularnos para esto? Busqué en el modelo base y no pude encontrar nada que se destacara. @

Imagine que pasa los siguientes valores en una orden de venta: partner_id y fiscal_position_id . Veo varios problemas:

1. Sin especificar que partner_id es el que inicia, puede llamar primero _onchange_fiscal_position_id y luego _onchange_partner_id , que no es el orden correcto.
2. Creo que no está considerando la posibilidad de realizar cambios en cascada. _onchange_partner_id modifica fiscal_position_id , por lo que debe llamar después de _onchange_fiscal_position_id .
3. Si está pasando un fiscal_position_id específico, ¿es porque desea ese puesto específico? Luego, debe anular el valor get on first onchange para pasarlo a los onchanges consecutivos. ¿O quieres anularlo?

@lasley , podría extender el complemento 'onchange_helper' https://github.com/OCA/server-tools/tree/10.0/onchange_helper

Bueno, esto es increíble, gracias @lmignon , ¡no estoy seguro de cómo me lo perdí!

De hecho, creo que esta es una mejor implementación ahora que la veo. Con mi idea, estamos agregando la sobrecarga de una declaración if en cada creación / escritura, pero con esta no lo hacemos. Ambos requieren aproximadamente la misma cantidad de código para su uso, por lo que es un claro ganador.

Sin embargo, creo que quizás voy a retocar un poco el archivo Léame en el otro. Creo que la palabra play es lo que me desconcierta.