Daily updates from Odoo
Sunday, July 27, 2025
13 changes
3 changes
Resolved issues and error corrections
This fixes confusing behavior in an internal web testing tool so freezing time no longer unexpectedly toggles on or off. The change makes automated tests easier to understand and helps prevent subtle test failures or false confidence during development.
Original PR description
The freezeTime utility function had a very strange behaviour: if it is called without an argument, it would toggle the current value. This means that if i read a test that calls freezeTime, i actually do not know if the time is frozen after that function call. This could be a problem in many subtle situations. For example, if a test is using freezeTime, and then later, someone add a `beforeEach(freezeTime)` in that suite without removing the existing freezeTime, then weirdly, the test would no longer be "protected". This commit simplifies the behaviour of freezeTime to make sure we know what we are doing in all cases. 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 Forward-Port-Of: odoo/odoo#220536
Very small negative values that round to zero are now displayed as 0.00 instead of -0.00. This avoids confusing users and keeps financial or formatted number displays clearer and more consistent.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#219913Tiny negative amounts that round to zero now display as 0.00 instead of -0.00 in Luxembourg electronic reports. This prevents confusing or misleading values in report output while keeping the underlying amounts unchanged.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953
Forward-Port-Of: odoo/enterprise#909926 changes
Resolved issues and error corrections
Imported sales orders in Point of Sale now keep the tax position set on the original sales order, even when it differs from the customer's default tax setup. This helps ensure the right taxes are applied at checkout and reduces billing corrections.
Original PR description
When a sales order is imported into the PoS, the tax position does not match if the sales order has a different tax position than the one assigned to the partner. This commit ensures that the tax position will always be the one assigned to the sales order and not that of the partner. taskId: 4963118 Forward-Port-Of: odoo/odoo#220522 Forward-Port-Of: odoo/odoo#219869
Point of Sale now checks whether an order has already been sent for preparation before printing, and synchronizes the order status after printing. This prevents multiple devices from printing the same preparation ticket, reducing confusion and duplicate work in restaurants or shops.
Original PR description
Before this change, when a device sent an order in preparation via the ticket printer, this could result in the same order being printed by multiple devices, as the order was not synchronized after it was sent. The error is a bit tricky, because if the user had installed a preparation screen, the order was sent to the preparation screen via syncAllOrders. In this case, the order was correctly synchronized and the other devices were informed of the changes. This commit adds two things. - We check the server before sending the order to preparation to make sure it has not already been sent. - Even when the user does not have a preparation display, the order will be synchronized after being sent to a printer. Forward-Port-Of: odoo/odoo#220706 Forward-Port-Of: odoo/odoo#220535
Very small negative amounts that round to zero now display as positive zero, such as "0.00" instead of "-0.00". This avoids confusing or misleading values in documents, tax calculations, and user-facing number displays.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#219913This fix makes Odoo's internal test time-freezing tool behave predictably instead of switching state unexpectedly when called without details. It reduces the risk of confusing or unreliable automated tests, helping developers catch issues more consistently before release.
Original PR description
The freezeTime utility function had a very strange behaviour: if it is called without an argument, it would toggle the current value. This means that if i read a test that calls freezeTime, i actually do not know if the time is frozen after that function call. This could be a problem in many subtle situations. For example, if a test is using freezeTime, and then later, someone add a `beforeEach(freezeTime)` in that suite without removing the existing freezeTime, then weirdly, the test would no longer be "protected". This commit simplifies the behaviour of freezeTime to make sure we know what we are doing in all cases. 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 Forward-Port-Of: odoo/odoo#220536
This fix prevents the same point-of-sale preparation order from being printed by multiple devices. The system now checks whether an order was already sent and synchronizes the order status after printing, reducing duplicate work and confusion for staff.
Original PR description
*: pos_urban_piper_enhancements Before this change, when a device sent an order in preparation via the ticket printer, this could result in the same order being printed by multiple devices, as the order was not synchronized after it was sent. The error is a bit tricky, because if the user had installed a preparation screen, the order was sent to the preparation screen via syncAllOrders. In this case, the order was correctly synchronized and the other devices were informed of the changes. This commit adds two things. - We check the server before sending the order to preparation to make sure it has not already been sent. - Even when the user does not have a preparation display, the order will be synchronized after being sent to a printer. Forward-Port-Of: odoo/enterprise#91090 Forward-Port-Of: odoo/enterprise#91006
Very small negative amounts in Luxembourg reporting are now shown as zero when rounded to two decimals. This prevents confusing values like "-0.00" from appearing in report output and improves clarity for users reviewing financial figures.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953
Forward-Port-Of: odoo/enterprise#909924 changes
Resolved issues and error corrections
Odoo now handles employee attendances that cross midnight by splitting them into separate daily work entries. This prevents conflicting work entries when overnight shifts are followed by same-day attendances, improving payroll and attendance accuracy.
Original PR description
Steps to reproduce the issue: 0. Set work_entry_source to "attendance" on the running contract of the employee. 1. Create an attendance for yesterday 23:00:00 UTC to today 06:00:00 UTC. 2. Create an…
Steps to reproduce the issue: 0. Set work_entry_source to "attendance" on the running contract of the employee. 1. Create an attendance for yesterday 23:00:00 UTC to today 06:00:00 UTC. 2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC. Current behavior before PR: Odoo will create a conflicting work entry with the one created in step 1, because the logic recreates all work entries in a timeframe between the start date at 00:00:00 and end date at 23:59:59. The first entry started before this timeframe, so the recreated work entry does not align with the existing one, causing a conflict. Desired behavior after PR is merged: The work entries now span a single day at a time. If an attendance starts at night and ends the next morning, two entries will be created: one from the start time to end of day, and another from the start of the next day to the end time. opw-4869604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90938 Forward-Port-Of: odoo/enterprise#90588
Users with approved temporary exceptions can now reset qualifying tax closing entries without being incorrectly blocked by the standard tax lock date. The change also applies the full set of effective lock rules, including stricter hard locks and parent company locks, reducing incorrect errors while preserving financial controls.
Original PR description
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to…
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction. Root Cause: The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored. Fix: Replaced the direct lock date check with _get_lock_date_violations(), which: - Correctly considers user-specific temporary lock date exceptions. - Returns violations based on effective lock rules (including hard lock). - Provides a more generic error message. Steps to reproduce: - Use a tax report with carryover values (e.g. Belgian VAT return, line 81). - Post a refund using a tax that maps to the carryover (e.g. 21% M). - Generate a closing entry. - Set the company’s tax_lock_date to a date covering the refund. - Grant a temporary lock date exception to the user, covering the same date. - Try to reset the closing entry → Lock date error is raised (incorrectly). opw-4715100 Forward-Port-Of: odoo/enterprise#89762 Forward-Port-Of: odoo/enterprise#85337
This fixes a test setup issue for Indian point-of-sale reporting caused by a field being defined in the wrong edition. It helps keep automated validation stable and prevents avoidable build failures for the affected localization module.
Original PR description
This problem was introduced with [1](https://github.com/odoo/odoo/pull/205481) and [2](https://github.com/odoo/enterprise/pull/83201) Community PR : [219436](https://github.com/odoo/odoo/pull/219436) This breaks the `TestInPosBase` class in Single App Test build with an invalid field `l10n_in_gst_efiling_feature`. Runbot - [229837](https://runbot.odoo.com/odoo/error/229837)
Orderline-specific customer notes are now included on preparation displays in Point of Sale. This helps kitchen or preparation staff see customer requests tied to individual items, reducing missed instructions and order errors.
Original PR description
In this commit: ----------- Orderline-specific customer notes are now included in the preparation display order. <img width="336" height="250" alt="line-customer-note" src="https://github.com/user-attachments/assets/0dc0dd3f-0c14-45ed-9d86-c75f197a2334" /> Task-4879140 Related: https://github.com/odoo/odoo/pull/215761