Daily updates from Odoo
Thursday, May 23, 2019
5 changes · master
Enhancements to existing features
This change lets Odoo tests run even when demo data has not been loaded. It supports better testing practices by allowing tests that create their own data to run in leaner environments.
Original PR description
As most of the tests are using demo data, a check is performed to verify that they are loaded. A best practice is to write tests that does not depend on demo data but with this check, it's not possible to launch them without demo data. With this commit, the check is removed, allowing to launch test even without demo data loaded.
This change updates how Odoo handles unsaved records while users edit forms, making related field updates more consistent and reducing special-case behavior behind the scenes. It affects several business areas such as accounting, HR leave, mail, manufacturing, products, and website events, helping prevent errors during on-screen changes before records are saved.
Original PR description
Using new records in onchange() simplifies code: the environment flag `in_onchange` is gone, and all special cases correspond to new records. The expression `record._origin` is now available on *all* records, and returns the *actual* record corresponding to `record`.
This change adds a safeguard test for accounting reconciliation to ensure write-offs keep debit and credit amounts on the correct side. It helps prevent future changes from introducing errors in financial reconciliation results.
Original PR description
Test that there is no conversion of debit/credit when creating a writeoff with the method process_move_lines of the model 'account.reconciliation.widget'. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kit orders now use the routes of their individual components instead of the kit product itself, making fulfillment behavior more accurate. Availability and delivered quantities are calculated from component stock and processed quantities, so sales teams get clearer warnings and more reliable delivery status for kits, including complex cases like backorders, returns, nested kits, and different units of measure.
Original PR description
**Before this PR:** - The routes applied when a kit was ordered was the ones set on the kit. - The quantities available when a kit was ordered was 0 even if enough components were available - The…
**Before this PR:**
- The routes applied when a kit was ordered was the ones set on the kit.
- The quantities available when a kit was ordered was 0 even if enough components were available
- The quantities delivered when a kit was ordered were correct only if all move from the picking of its sale order were done. So the quantities delivered were correct only if all components were fully delivered.
**After this PR:**
- The routes of each components of the kits are applied independently and the routes set on the kit itself are ignored
- A 'next activity' is logged when a kit as the route 'Manufacture' set
- The number of kits available is computed based on the quantities available of the components needed to make the kit.
- The number of kits delivered is computed based on how many kits it's possible to make with the components already processed.
- Some test case are added the check the flows when kits are ordered.
Those test case make sure that:
* Delivered quantities are accurate if :
- kits in kit
- backorders are made
- returns are made
- returns of returns are made
- Multiple differents UoMs are setted on the components of a kit
* Available quantities are accurate if:
- Kits in kit
- Multiple differents UoMs are setted on the components of a kit
TaskID : 1863856
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update simplifies how draft form changes are handled before records are saved, reducing special-case behavior behind the scenes. It helps make field updates more consistent in Field Service, Manufacturing Work Orders, and Subscriptions without introducing major user-facing changes.
Original PR description
Using new records in onchange() simplifies code: the environment flag `in_onchange` is gone, and all special cases correspond to new records. The expression `record._origin` is now available on *all* records, and returns the *actual* record corresponding to `record`.