Monday, May 19, 2025
31 changes
4 changes
Resolved issues and error corrections
The restaurant preparation display now handles combo orders and cancelled order lines correctly. This prevents orders from getting stuck or showing errors, helping kitchen staff keep preparation workflows moving smoothly.
Original PR description
Issue 1: === Steps to reproduce: ------- - Install `pos_restaurant`. - Open a restaurant session and the preparation display. - Open any table and add two combo items. - Press the order button and go…
Issue 1: === Steps to reproduce: ------- - Install `pos_restaurant`. - Open a restaurant session and the preparation display. - Open any table and add two combo items. - Press the order button and go to the preparation display. Issue: ------- - The combo items do not appear, and the stage cannot be changed. Cause: ------- - The combo parent order line does not have an `id`. - Since there are two combo parents, the `t-foreach` encounters multiple lines with the same `undefined` id. Fix: ------- - Use `orderline_index` instead of `orderline.id`.. Issue 2: === Steps to reproduce: ------- - Install `pos_restaurant`. - Open a restaurant session and the preparation display. - Open any table and add an order line. - Press the order button so the line appears in the preparation display. - Remove the line and press order again to cancel it. - Go to the preparation display. - Click on the cancelled order line. - A traceback appears. Issue: ------- - You are unable to strike out the cancelled order line. Cause: ------- - When all quantities of a prep line are cancelled, there are no corresponding `pos_order_line_id` available. - The code attempts to compute `order_completion_seconds` using `max()` on an empty list, which raises a `ValueError`. Fix: ------- - Added a guard condition to ensure `completion_time` is only computed when there is `pos_order_line_id`. - This prevents calling `max()` on an empty sequence and avoids the traceback when clicking cancelled lines in the preparation display. Task: 4800284
The itsme identity verification dialog now appears correctly again during document signing. This restores an important signing flow that had stopped working after an earlier internal change.
Original PR description
Since https://github.com/odoo/enterprise/pull/81766 the itsme dialog was not working anymore. Some methods have been moved from SignablePDFIframe to the Document component. As a result, some overrides were not called anymore. taskid: 4770756
Bank reconciliation now uses the remaining open amount on invoices instead of the original balance. This helps match later bank statement lines correctly after a partial payment has already been reconciled.
Original PR description
This commit will replace some occurrence of the balance for the amount residual and amount currency for the amount residual currency. In this example: Invoice of 100$ A first statement line of 20 A second statement line of 100 We do the reconciliation between the invoice and the first statement line. The invoice will be partially reconciled. Before this commit since we used the balance we wouldn't take this reconciliation into account when doing the reconciliation between the remaining amount of the invoice and the second statement line. no task id
This update fixes several issues in the manufacturing shop floor experience after the redesign. Operators now see clearer navigation, correct production quantities, better employee status ordering, and more reliable quality check and timer behavior, reducing confusion during daily production work.
Original PR description
Some follow-up items to fix after the shop floor redesign from [1]. Please refer to the individual commits for details about the different fixes. [1] https://github.com/odoo/enterprise/pull/80469 task-4731403
21 changes
Resolved issues and error corrections
Shipping and invoicing addresses now have clearer spacing when shown together on several business reports. This makes printed and shared documents easier to read and helps avoid confusion between delivery and billing details.
Original PR description
*: account,l10n_hu_edi,l10n_sa,purchase,purchase_stock,sale When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. The `:` character is inconsistent with other reports, but will be removed in the master forward port to avoid overriding stable translation. task-4730464 Enterprise PR: https://github.com/odoo/enterprise/pull/84281 | Issue solved in this PR | |--------| | | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores access to the Attendance app for users who can manage employee records but are not attendance administrators. It corrects a missing permission update so attendance officers can perform their expected work without being blocked.
Original PR description
Attendance module was inaccessible for users that had access to employee records, but were not attendance admins. This was due to [this](https://github.com/odoo/odoo/pull/205031/commits/ef423640c4e2402509eafc6aa8696e33dacf51ea) backported change that did not also backport the access right change for the attendance_manager_id field. opw-4750765
The online shop checkout flow was adjusted so customers are always sent to the main checkout step first, even when extra invoicing information may be needed. This prevents routing issues caused by related Enterprise changes and keeps the purchase process consistent.
Original PR description
- Remove _get_extra_billing_info_route method, as it is unnecessary. The user should always be redirected to the checkout step first, regardless of the existence of an invoicing info step. Enterprise PR: https://github.com/odoo/enterprise/pull/85094 opw-4738797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Time Off reporting where selecting a leave record could incorrectly open an allocation record instead. The report now keeps leave and allocation data aligned, helping users review time off details accurately.
Original PR description
### Steps to reproduce: - Navigate to Time off app -> Reporting -> By type - Access any leave record - Notice it will open an allocation record form ### Cause: This is happening as the query we are using to fetch hr.leave.report is not ordered correctly when it comes to fetching the columns. https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L51-L53 https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L68-L70 in those two sub-queries the order of fetching the allocation_id and leave_id is not the same which cause that leave_id column will be always null and every id value -either leave_id or allocation_id- will be stored in allocation_id column. ### Fix: Since columns' order matter when fetching sub-queries we unified the order in both queries. opw-4723952
This fixes an issue where generated foreign VAT taxes could miss required transition accounts in multi-VAT company setups. It helps ensure cash basis taxes are created consistently, company settings are updated correctly, and related accounts can be reconciled for smoother accounting operations.
Original PR description
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to…
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes => Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't). This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we declare them in in the csv. When creating those 0% taxes, the transition account had to be mapped. Since Belgium does not have any cash basis taxe, we relied on the first account used in the tax repartition of the tax to convert. However, those 0% taxes obviously had no account there (since they're 0% anyway), so we ended up not entering this condition https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L970 and mapping the transition account to None. Because of that, we did not create any equivalent for that account, for any of the taxes using it. This commit solves that by sorting the tax templates to first treat those with accounts in their tax repartition. We also fix here the fact that instantiating such cash basis taxes did not enable the "cash basis" setting on the company ; which didn't make any sense, and caused an error message when trying to edit the settings afterwards.
Automatic checkout now accounts for scheduled lunch breaks when determining the end of a workday. This prevents employees from being checked out too early and helps recorded hours match expected schedule hours, including two-week calendar setups.
Original PR description
**Issue** For example, in the case of a working schedule from 8:00 to 17:00 with a 1 hour lunch period, 8 hours of work are expected. By taking the lunch interval into account, the auto check out will happen at 17:00 if the company's tolerance in the attendance's setting is set at 0. Previously, it would happen at 16:00, resulting in only 7 worked hours for the attendance while the user may expect the attendance's worked hours to match the expected working hours of the schedule. **Solution** - include lunch attendances (not taken into account by `duration_hours`) in the total time that needs to be exceeded before an `hr.attendance` is automatically checked out. Note that this solution manages the case where `hr.attendance` are outside lunch periods (e.g. 8-12 and 13-17, but no attendance between 12-13). Though in that case, the automatic check out will be delayed by at least 1h. Note: a change was also made to account for 2 weeks calendars. opw-4402321
This fixes an issue where pasting text in the HTML editor could make the page scroll unexpectedly, even when the cursor was already visible. The editor now better detects the selected area and only scrolls when needed, improving editing comfort for users working with long content.
Original PR description
Problem:
In case of programmatic selection change (e.g., on paste), the selection may be set on an invisible range, like:
`setSelection({anchorNode: <div>, anchorOffset: 1});` This case was not properly handled by the `scrollToSelection` function.
Solution:
When encountering an invisible collapsed range, use the `anchorNode`'s closest element to calculate offset and perform scrolling. This prevents unnecessary scrolling when the selection is already inside the viewport and within an element.
Steps to reproduce:
1. Add enough text to make the editable area scrollable.
2. Insert a list (any type).
3. Copy some text and paste it into the last list element. → Even if the selection is in the viewport, it still scrolls
incorrectly.
opw-4745939
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA bug in Point of Sale local storage prevented updates to existing records from being saved properly. This fix ensures changes made while using the local database are retained, improving reliability for store operations.
Original PR description
After commit https://github.com/odoo/odoo/commit/692992a25dc8f583ef70517088ec963a8d30802b, updates to existing records in indexedDB were not properly saved due to incorrect logic. As a result, changes to records were not persisted in the local database. This commit corrects the update logic to ensure that modifications to existing records are correctly saved in indexedDB. opw-4802025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the HTML editor where selecting all content inside a table cell with the mouse did not select the cell itself. This makes table editing more predictable and reduces frustration when working with complex cell content.
Original PR description
### Approach: - When the entire content of a single table cell is selected, store the `ev.clientX` value once the cell content is fully selected. Afterward, if the mouse moves in the direction of the selection (left or right) by a sensitivity threshold of 5px, the entire cell is selected. ### Steps to Reproduce: - Create a table (e.g., using /table). - Add multiple blocks with varying text lengths inside a cell. - Try selecting all the content inside the cell using the mouse. - Observe that the cell does not get selected. ### Description of the issue/feature this PR addresses: - The cell does not get selected when all content inside the cell is selected with the mouse. ### Desired behavior after PR is merged: - The entire cell is selected when the content is fully selected. task-4743170 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue on the online shop page where the add-to-cart confirmation pop-up could appear off-screen after a customer scrolled down. Customers now see the confirmation immediately, reducing confusion during shopping.
Original PR description
The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by…
The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications. Steps to Reproduce: - Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop` page - Navigate to the shop page and scroll to the last product - Add the last product to the cart - The pop-up does not appear unless you scroll back up Issue: - The add to cart pop-up is not visible when the user is scrolled down on the page Root cause: - The CSS class `position-absolute` restricts the pop-up to a specific location in the scrollable content Fix: - Replace `position-absolute` with `position-fixed` to keep the pop-up visible regardless of scroll position opw-4686886 Affected version - 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance officers without manager access were incorrectly blocked from opening the Attendance app. This fix updates the access setup so officers can enter the app while still only seeing the employee records they are allowed to manage.
Original PR description
**Problem** Users in the `hr_attendance.group_hr_attendance_officer` group are blocked from opening the Attendance app when they lack the manager role. **Steps to reproduce** - Remove…
**Problem** Users in the `hr_attendance.group_hr_attendance_officer` group are blocked from opening the Attendance app when they lack the manager role. **Steps to reproduce** - Remove `hr_attendance.group_hr_attendance_manager` from your user. - Add `hr_attendance.group_hr_attendance_officer`. - Open the Attendance app: access is denied. **Cause** The method [read_group_employee_id](https://github.com/odoo/odoo/blob/cd428bd75b63f96c67942be5457d0afdb00d29b0/addons/hr_attendance/models/hr_attendance.py#L672) applies a domain on attendance_manager_id, which incorrectly prevents officers from passing the check. **Solution** Switch the group on the attendance_manager_id field in hr_employee.py so that officers aren’t inadvertently blocked. Officers will still be restricted from reading records they don’t manage. 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
The HTML editor color picker now remembers the custom color a user just applied when they move between tabs. This avoids confusion and helps users continue formatting content consistently without reselecting the same color.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Select a text, open color selector. - Switch to custom tab. - Apply any custom color. - Switch to any other tab without closing color selector. - Switch back to the custom color tab. - Selected default color in colorpicker is old one rather than applied one. **Desired behaviour after PR is merged:** Applied custom color should be selected by default when switching back to custom tab. task-4737027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal invitation email template now uses the contact’s partner details instead of relying on incomplete portal user information. This prevents an error when previewing the invite email and ensures the recipient name displays properly.
Original PR description
[FIX] portal: display template for portal invite Steps to reproduce: ---- - Install portal module - Grant a portal access to a contact - Go to the email template (Portal: User Invite) for the contact - Click on Preview -> Traceback Issue: --- The display was based on the user itself referencing to a partner. And there was no name for the portal users. Fix: --- Changed the view so now the different values are based on the partner.Also added the name to this function based on the partner name. opw-4444729
The web code editor can now reopen with the cursor placed where editing previously started. This helps users continue work smoothly after saving or reloading edited content, reducing friction in workflows that require the editor to restart.
Original PR description
Before this commit it was not possible to start the Ace editor (via its owl wrapper codeEditor) with an initial cursor position. After this commit it is now possible to do just that. This comes handy in the use case where: - one makes modification on the edited resource. - saves the result. This could mean that the codeEditor must be restarted from scratch (reloading all the data) - functionally stay on the saved resource at the right position. Note that the onChange call back now received the position at which the edition *started*. 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
Website forms that create project tasks no longer fail when the optional Full Name field is removed and the submitted email is not already known. This prevents errors for visitors using simplified contact forms and helps teams continue receiving task requests reliably.
Original PR description
Scenario: - add a form with studio - change its action to "Create a Task" - delete the field "Full Name" - send the form with an unknown email Result: an error happens Cause: if the email does not find a user, the code expects the partner_name to always be present, even if it is an optional field. Fix: make the code work without partner_name field. opw-4773357
This fix prevents an error when users open accrued expense entries from purchase orders that include down payments. Down payment lines are now handled correctly, so accounting workflows can continue without a traceback.
Original PR description
When user tries to open accrued expense entry in purchase order, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` and ``purchase`` module - Create a new Bill > Add a line > Don't add a product > Save > Purchase matching > Select your bill > Add to PO > Add Down Payment > New PO will be created - Actions > Accrued Expense Entry Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/834eff6e770280e911bb99e2abab4ea42d4ca8ff/addons/account/wizard/accrued_orders.py#L170 Here, when ``is_purchase`` is true, ``is_downpayment`` will not be evaluated. As a result, down payment lines in purchase orders are not excluded. Since down payment lines do not have a ``product_uom``. so ``rounding`` will be 0.0 So, it will lead to the above traceback. sentry-6576645089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a test setup issue in the Indonesian Point of Sale module by using the right user permissions when creating POS records. It helps keep automated nightly checks stable without changing day-to-day business behavior.
Original PR description
- creating pos config and payment method requires pos admin (or sudo) - creating a pos order requires pos user Blows up during nightly single app tests. https://runbot.odoo.com/odoo/error/223001
Cypriot companies invoicing EU businesses with a valid VAT number will now automatically apply a 0% tax rate instead of 19%. This helps invoices comply with EU VAT rules and reduces the need for manual tax corrections.
Original PR description
Current behavior before PR: - When a Cyprian company invoiced another EU company with a valid VAT number, the 19% EU code was applied. But legally, as Cyprus is in the EU, the applicable tax rate should be 0%. Desired behavior after PR is merged: - The tax rate is now automatically 0% when invoicing a EU company Link to task: - https://www.odoo.com/odoo/project/967/tasks/4488340 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now confirm eCommerce orders from the portal when online payment is disabled but online signature is enabled. This restores a missing confirmation path while still preventing signatures from bypassing required online payments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to Sales settings; 2. ensure Online Signature is enabled; 3. disable Online Payment; 4. create an order via eCommerce; 5. go to portal preview. Issue ----- No sign and/or pay button that would allow the customer to confirm their order. Cause ----- Commit 880cd7a516147 disabled signatures for all eCommerce orders, as it could lead to customers getting an email to sign the quote, confirming the order, and triggering delivery without payment. As a consequence, with online payment disabled, there's no longer a way for customers to confirm their order. Solution -------- Disable signatures for eCommerce orders if online payment is enabled. opw-4739013
Guest shoppers using Mexican or Chilean e-invoicing checkout flows are now sent to the normal checkout step after submitting their address. This prevents them from being pushed directly to invoicing details too early, making checkout clearer and less likely to cause confusion or abandonment.
Original PR description
*= mx/cl Steps to reproduce: 1.Set the website's company to Mexico or Chile. 2.As a guest user, add any deliverable product to the cart. 3.In the address form, select Mexico or Chile as the country. 4.Submit the address form. Issue: - The user is redirected directly to the invoicing info step, skipping the checkout step. Cause: - When submitting the address form, if the address type is 'billing' and the invoicing info step is available, the flow redirects there immediately. Fix: - Removed the _get_extra_billing_info_route method, as it is unnecessary. The user should always be redirected to the checkout step first, regardless of the existence of an invoicing info step. See also: - https://github.com/odoo/odoo/pull/209221 opw-4738797
Batch payments now show clearer status information, only validate payments that are actually in process, and record when payments are added to or removed from a batch. SEPA mandate collection and paid invoice counters now include the right payments and hide empty buttons, helping users avoid misleading totals and errors.
Original PR description
* Hide smart buttons when there are no elements and include `in process` payments to the collections smart button. * Consider all payments linked to a mandate as Collections not only the ones have journal entries * Log in the payment chatter the inclusion/exclusion of the payment in a batch. * Validate only in process payments task-4531618