Monday, May 27, 2024
3 changes · master
Code cleanup and technical improvements
This draft refactors click interactions across automated tours and tests for accounting, reporting, approvals, documents, and spreadsheet workflows. It is marked as aborted and points to a replacement pull request, so there is no direct business-facing change expected from this draft.
Original PR description
Aborted => refer to https://github.com/odoo/enterprise/pull/63176
This refactoring prepares Odoo's automated web tours to use clearer, more consistent test steps. It reduces ambiguity in internal test behavior and helps future maintenance without changing end-user features.
Original PR description
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities. - `isCheck: true` => Checks that the element is in the DOM. The latter can…
Currently, in tour_compiler, to check that an element is actually
present in the DOM in a step, there are 2 possibilities.
- `isCheck: true` => Checks that the element is in the DOM.
The latter can be disabled.
- `run() {}` => Checks that the element is in the DOM (because this
is what is done by default). However, if the element is disabled,
the step will be aborted.
In the codebase, we can see a lot of `run() {} //it's a check` and
`isCheck:true`. However, the behavior is not exactly the same.
What's more, there are 2 ways to do "the same thing".
In order to clarify the turns API, it was decided to no longer put an
action (step.run) by default. (Previously, the default action was
the "click" action).
From then on, it is no longer necessary to stipulate
`step.isCheck: true` nor `run() {}`.
The corollary is that now, you must explicitly write `run: click`, if
you want the click action to be triggered on the target.
This commit sets the stage for making this change.This change standardizes how self-ordering POS modules share related order data with the frontend. It supports reuse of the same frontend model structure across POS self-order, preparation display, IoT, and online payment flows, reducing future maintenance work with minimal direct user impact.
Original PR description
*:pos_online_payment_self_order_preparation_display, pos_self_order_iot, pos_self_order_preparation_display Like in `point_of_sale` we introduce related_models in `pos_self_order` to handle relation between models in the frontend. This will allow to use the same frontend models in all pos related models. Related: https://github.com/odoo/odoo/pull/164793