Tuesday, July 14, 2026
11 changes · 19.0
Resolved issues and error corrections
Restaurant preparation tickets for direct sale orders now show a meaningful order reference instead of the generic "Direct sale" label. This helps kitchen staff identify and track orders more reliably when no table or custom order name is assigned.
Original PR description
In restaurant mode, a direct sale order (no table, no floating order name) has no display name yet when it is sent to the preparation printer. `getName()` returns "Direct sale" in that case, which appeared as the order name on the preparation ticket. Add a `preparationName` getter on `PosOrder` that, for direct sale orders, falls back to `floatingOrderName || pos_reference` so the ticket always shows a meaningful reference. For non-direct-sale orders the getter delegates to `getName()` unchanged. Task-6327397 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
This fixes an email display issue so images embedded in messages render properly for Outlook users. It helps ensure recipients see emails as intended, reducing confusion from broken or incorrectly displayed visuals.
Original PR description
Backport the changes from `b9370ea6b70ca3020c73a6940d70ff0cf954f69f` into `mail/convert_inline` to ensure Outlook-compatible image rendering. opw-3776054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269628 Forward-Port-Of: odoo/odoo#269436
This change fixes an internal time off test that could fail when run in future-dated test environments. By keeping the test date fixed, results stay consistent and help maintain release reliability without changing business features.
Original PR description
Problem ------------------------ test_department_accrual_allocation was failing due to the allocation being calculated as 26 days instead of 21 in faketime builds set to 2027. This was because the accrual plan was set to accrue 21 days per year and carry over 5 days from the previous year. Since the allocation was created on Jan 1st 2026, all 2027 builds were calculating the allocation to have 5 extra days. Solution ---------------------- Added freeze_time for 2026-03-01 to ensure the date stays the same. runbot-939344 task-6344033 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#274154 Forward-Port-Of: odoo/odoo#272728
Shipping charges added to sales orders now display their unit price with the same currency precision as the subtotal. This avoids confusing extra decimal places when delivery margins are applied, making order totals clearer for sales users and customers.
Original PR description
**Steps to reproduce:** 1. Install Sales and EasyPost modules and enable delivery methods in the Settings. 2. Configure a new delivery method in [Sales -> Configuration -> Delivery Methods], choose provider as EasyPost and set the API keys. 3. Set any margin % on the delivery method. 4. Add the shipping line to a sale order via "Add shipping". **Issue:** Unit Price displays at a 4dp precision while Subtotal correctly displays at a 2dp precision **Why this happens:** `_apply_margins()` returns a float from margin arithmetic calculation with no currency rounding applied. `rate_shipment()` writes this unrounded value directly to res['price'], which becomes the delivery line's price_unit. opw-6355318
Attendance reports and views now use consistent wording for extra hours. The old labels "Difference" and "Balance" are replaced with "Worked Extra Hours" and "Validated Extra Hours", making it easier for users to understand overtime figures.
Original PR description
The reporting labels "Difference" and "Balance" are confusing because "Difference" tracks system-qualified overtime while "Balance" represents accepted overtime hours. There is also a lack of consistency across views. This commit renames these fields to "Worked Extra Hours" and "Validated Extra Hours" to harmonize the naming everywhere task-6352142 Description of the issue/feature this PR addresses: Confusing and inconsistent naming for extra hours Current behavior before PR: - Reporting uses "Difference" and "Balance". - Views use inconsistent labels. Desired behavior after PR is merged: Labels are consistently named "Worked Extra Hours" and "Validated Extra Hours" everywhere. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274328 Forward-Port-Of: odoo/odoo#273631
Invoice PDFs now respect layouts that place the customer invoicing address on the left, even when the customer also has a delivery address and the Customer Address option is not enabled. This prevents confusing or inconsistent invoice formatting for businesses using left-address document templates.
Original PR description
Issue: On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left. Steps to reproduce: - Create a customer - Add a Delivery address to the customer - Ensure "Customer Address" is not set in the settings - Choose a layout with the address on the left (bubble, wave, ...) - Create an invoice to the customer - print the PDF Current behavior: - Customer address is on the right Expected behavior: - Customer address is on the left Cause: Address is displayed on the right if there is an information bloc . The information bloc was set to an empty div. Therefore, as it is set, address was displayed on the right. opw-6334130 Forward-Port-Of: odoo/odoo#273418
Projects linked to rental orders now show a Sales Orders count that matches the regular sales orders opened by the button. Rental orders remain available through their separate Rental Orders action, reducing confusion without hiding any records.
Original PR description
**Problem:** On a project linked to rental orders, the "Sales Orders" smart button shows a count larger than the number of orders it opens. **Steps to reproduce:** 1. Link a project to several sale…
**Problem:** On a project linked to rental orders, the "Sales Orders" smart button shows a count larger than the number of orders it opens. **Steps to reproduce:** 1. Link a project to several sale orders, some of them rental orders (e.g. 1 regular + 2 rental). 2. Open the project form: the "Sales Orders" smart button counts all of them (3). 3. Click the button. **Current behavior:** Only the non-rental orders open (1), so the count (3) does not match what is shown. **Expected behavior:** The count matches the orders the button opens (non-rental only). **Cause of the issue:** `sale_renting_project` separates the two: the "Sales Orders" action filters out rental orders (`_get_sale_orders_domain` adds `is_rental_order = False`) while rental orders get their own "Rental Orders" embedded action. But `sale_order_count` still counts every order linked to the project, rental ones included, so the button's number no longer reflects what its action opens. **Fix:** The count has to follow the same non-rental scope as the action it triggers, otherwise the button is misleading. Rental orders remain reachable through the dedicated "Rental Orders" embedded action, so excluding them from this count hides nothing. opw-6321302
When creating a project from a template, the system now matches original and copied tasks in the right order before applying scheduling calculations. This prevents dates from being copied or adjusted against the wrong task, improving reliability when using project templates.
Original PR description
Currently, `action_create_from_template` loops over both the copied and original tasks to perform the necessary datetime calculations, however, by simply zipping self.task_ids and project.task_ids, nothing guarantees the tasks are properly aligned in the loop. This can result in the original_task and copied_task being completely different. To fix this, we can sort the two recordsets by stage and sequence, which will guarantee the tasks are aligned after zipping. (provided a task was not dropped somehow) opw-6353533
This change removes a reference to an employee group that does not exist in the Belgian payroll fleet setup. It helps prevent configuration errors and keeps access rules aligned with the available system groups.
Original PR description
The group hr_group_user does not exist and shouldn't be linked to these fields. task-6369268 Forward-Port-Of: odoo/enterprise#123238
The planning kanban card now shows allocated time in a simpler, consistent format such as (4h30). Removing the percentage from this spot fixes uneven spacing and makes schedule information easier to read at a glance.
Original PR description
Currently, the allocated hours and allocated percentage are misaligned in the planning kanban card, causing them to appear uneven or have inconsistent spacing. This fix removes the allocated percentage and formats the allocated hours to display like (4h30). task-5085363 Forward-Port-Of: odoo/enterprise#98776
Payroll pay schedule options now appear in the user's selected language across the main payroll app and multiple country-specific payroll modules. This fixes untranslated labels on employee payroll forms, improving usability for non-English users.
Original PR description
Issue: ---------------------------------------- The values of the field `schedule_pay` aren't translated. Steps to reproduce: ---------------------------------------- - Switch the language to French - Open an employee form, "Paie" tab - The selection in the "Salaire" tab is not translated to French Cause: ---------------------------------------- When the selection values were moved to a method in 7a123d71925b25f26ba0a8abff0c4a159147bdd0. The strings were not declared as translatable. opw-6359395