Friday, January 24, 2025
5 changes · 17.0
Resolved issues and error corrections
This update fixes an error that could appear when opening project settings linked to sales projects. It helps ensure users can access those settings reliably without being blocked by a database-related issue.
Original PR description
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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
This fixes an internal automated check so it correctly handles a specific coding pattern used by developers. It helps prevent false alarms or missed issues during development, improving reliability without changing customer-facing features.
Original PR description
This commit add support for comprenhension expression on assign node
When an invoice is paid through multiple payments, small tax rounding adjustments are now recorded in the correct cash basis tax journal on the final payment. This prevents those balancing entries from being placed in the exchange difference journal, keeping accounting records clearer and more accurate.
Original PR description
If you pay an invoice with multiple payments some roundings are made for the taxes. On the last payment, the error from those roundings are put on a move to make sure that the exact amount of the invoice is paid. That move was put on the wrong journal. It was put in the 'Exchange Difference' journal instead of the 'Cash Basis Taxes'. opw-4460696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how WhatsApp templates are linked to their parent conversation or record. It prevents messages created from templates from being associated with the wrong item, improving message history accuracy for users.
Original PR description
Since whatsapp templates are posted on a specific model, the current parent computation becomes incorrect when it comes to templates, because of incorrect domain, in particular `model` and `res_is` parts of it. task-4210393 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
Purchase orders will no longer show activity log entries for tiny rounding differences in the untaxed amount. This keeps the chatter cleaner when users make unrelated updates, such as changing an expected arrival date.
Original PR description
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002`…
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmetic and its limitations. So what I did is checking if the new value is different than the old one then update the field. Steps to reproduce: 1. Create a PO 2. Add a product with price 261,462.02 3. Save 4. Change the expected arrival date 5. Save See the chatter. take a loot at the chatter.  opw-4315116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr