Server-tools: [RFC] context_onchange: ключ контекста для внесения изменений

Вам необходимо определить начальное поле (поля), которое будет запускать остальные изменения.

Привет @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'})

Причина, по которой я спрашиваю, заключается в том, что я вижу невероятно непоследовательное применение этой логики.

Нет, я не говорю, что это уже происходит. Я говорю о том, что вам нужно каким-то образом указать, какое значение (а) поля (а) запускает цепочку изменений. Что-то вроде:

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

О, интересно, я думал просто использовать ключи, которые присутствуют в самих данных. В основном просто переопределите методы create и write , а затем выполните замену, если ключи есть.

Ваш дизайн позволит разработчику фактически ограничить внесение изменений или инициировать их вручную, даже если данные не содержат ключа. Это почти похоже на ситуацию "почему бы и не то и другое"?

Есть ли у вас какие-нибудь подсказки, есть ли какой-то центральный механизм идентификации onchange, на который мы можем ссылаться для этого? Я просмотрел базовую модель и не смог найти ничего выделяющегося. @

Представьте, что вы передаете в заказ на продажу следующие значения: partner_id и fiscal_position_id . Я вижу несколько проблем:

1. Не указывая, что partner_id является инициирующим, вы можете сначала вызвать _onchange_fiscal_position_id а затем _onchange_partner_id , что не является правильным порядком.
2. Я думаю, вы не рассматриваете каскадные изменения. _onchange_partner_id изменяет fiscal_position_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

Хорошо, это потрясающе, спасибо @lmignon , не знаю, как я это пропустил!

Я действительно думаю, что теперь, когда я смотрю на нее, это лучшая реализация. По моей идее, мы добавляем накладные расходы на оператор if в каждое создание / запись, но в этом мы этого не делаем. Оба требуют примерно одинакового количества кода для использования, так что абсолютный победитель.

Я думаю, что, может быть, я собираюсь немного подправить ReadMe по другому. Я думаю, что слово play сбило меня с толку.