Daily updates from Odoo
Tuesday, July 23, 2019
7 changes · master
Resolved issues and error corrections
This fix prevents Point of Sale errors when a customer's fiscal position removes a tax, and ensures taxes are recalculated correctly when switching to a customer without special tax rules. This helps cashiers avoid checkout disruptions and reduces the risk of applying the wrong tax to orders.
Original PR description
This commit fixes the following faulty behaviors: 1. There is a traceback in the pos ui when the selected customer has fiscal position that maps a tax to nothing. To prevent this behavior, we avoid…
This commit fixes the following faulty behaviors: 1. There is a traceback in the pos ui when the selected customer has fiscal position that maps a tax to nothing. To prevent this behavior, we avoid to add the undefined tax destination. 2. When you change the customer in pos ui from someone who has fiscal position to someone without, the tax in the order remains to be based on the previous customer. The tax should change to original tax of the product or to the tax mapped by the default fiscal position of the session. To avoid this behavior, we now set the default fiscal position on the order when a customer has no fiscal position. **To reproduce:** **Issue 1. Error when `product1` is selected for `partner1`** *Steps:* 1. create fiscal position `fpos` that maps `tax1` to nothing 2. assign `fpos` to `partner1` 3. activate fiscal position per order in pos.config and add `fpos` 4. assign `tax1` to `product1` (should be available in pos) 5. open new pos session 6. select `product1` 7. issue: error when selecting `partner1` as customer *Reason.* In `_map_tax_fiscal_position`, `tax=undefined` is pushed to `taxes`. **Issue 2. Tax for `partner1` is active in `partner2` even if `partner2` has no fiscal position.** *Steps:* 1. create fiscal position `fpos` that maps `tax1` to `tax2` 2. assign `fpos` to `partner1` 3. activate fiscal position per order in pos.config and add `fpos` 4. assign `tax1` to `product1` 5. open new pos session 6. select `product1` -> tax should be `tax1` since no customer 7. select `partner1` -> tax changed to `tax2` because of `fpos` in `partner1` 8. issue: select new customer without fiscal position -> tax should be `product1`'s original tax because no fiscal position, but tax from previous customer is not changed. *Reason.* If the newly selected customer has no fiscal position, order.fiscal_position is not updated so it takes the old fiscal position. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Installing a demo chart of accounts from the web interface now uses the correct demo company information instead of selecting from the user's allowed companies. This prevents critical installation errors and makes web-based demo company setup behave consistently with command-line installs.
Original PR description
If we try to install a chart of account from the demo to a new demo company: * When using CLI with -i module works perfectly * When installing from web interface (example runbot) it was failing and throwing a critical error. This was because was not taking into account the information in the demo data to load the chart of account of a specific company, insted it was using any of the users allowed companies. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes SMS chatter behavior so empty SMS notifications no longer show unnecessary popovers or tooltips. It also improves related SMS sending, composer messages, and number-format handling so users get clearer feedback and smoother updates.
Original PR description
PURPOSE Improve SMS UX integration SPECIFICATION Fix recent SMS merge: do not display tooltip / popover about SMS information in chatter if there was no recipients linked to the SMS message. LINKS Task 1922187
When users create or edit sales, expenses, and related analytic records, unit choices are now limited to the product's relevant category. This prevents incorrect unit selections after reopening records and helps keep orders and expenses consistent.
Original PR description
Enforce the domain of the UOM not by an onchange but by a domain. Example of an issue if the domain is enforced by an onchange: - create an order - add an order line - select the product - select an…
Enforce the domain of the UOM not by an onchange but by a domain. Example of an issue if the domain is enforced by an onchange: - create an order - add an order line - select the product - select an uom > the uom presented are the one from the product category. -Save - edit - select an uom > all UOM are presented even the ones of other categories This commit enforce this new logic at most places. Description of the issue/feature this PR addresses: Display only category's uom Current behavior before PR: At the time of editing a sale order line, it displays all category's uom. Desired behavior after PR is merged: At the time of creating or editing a sale order line, it displays only related category's uom. Task: https://www.odoo.com/web#id=2003959&action=333&active_id=809&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.35c17fb973d768886a273c818f42ea02 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates French payroll configuration data to use the correct payroll type reference. It helps ensure employee payroll structures for executive and non-executive staff load and work as expected.
Subscription lines now consistently show only units of measure that match the selected product category, both when creating and editing records. This prevents users from accidentally selecting an incompatible unit and helps keep subscription data accurate.
Original PR description
Enforce the domain of the UOM not by an onchange but by a domain. Example of an issue if the domain is enforced by an onchange: - create a subscription - add subscription line - select the product - select an uom > the uom presented are the one from the product category. - save - edit - select an uom > all UOM are presented even the ones of other categories This commit enforce this new logic at most places. task - 2003959 Description of the issue/feature this PR addresses: Display only category's uom Current behavior before PR: At the time of editing a sale subscription line, it displays all category's uom. Desired behavior after PR is merged: At the time of creating or editing a subscription line, it displays only related category's uom. Task: https://www.odoo.com/web#id=2003959&action=333&active_id=809&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.35c17fb973d768886a273c818f42ea02
This fixes an internal payroll accounting test that could sometimes cancel the wrong payslip because it relied on an unpredictable order. The change makes test results more consistent, helping reduce false failures during development and release checks.
Original PR description
In the test_04_hr_payslip we were depending on the order of the One2many slip_ids, but the order of the recordset is not guaranteed. This lead to non deterministic errors where the wrong payslip was cancelled.