Monday, May 19, 2025
18 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
2 changes
Resolved issues and error corrections
This fix ensures project planning correctly identifies overlapping tasks when filters include related information. It helps prevent scheduling conflicts from being missed and improves the reliability of planning calculations and related tests.
Original PR description
The query that determines overlapping tasks is making two different Query objects: the first one for the main task and the second one for overlapping tasks. The second query is joined into the first…
12 changes
Resolved issues and error corrections
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 query that determines overlapping tasks is making two different Query objects: the first one for the main task and the second one for overlapping tasks. The second query is joined into the first one, injecting the second one's where clause as join condition, but that composition does not work if the second query has extra joins. Those extra joins come from related fields that may occur from the domain. The fix consists in recomposing the query with a join condition that does not depend on a dynamic domain, and injecting the domain in the where clause of the main query. With this strategy, the joins that appear because of the related fields in the domain are part of the main query, and are no longer lost by the composition. Note also that the test test_same_user_overlap_with_allocated_hours_less_than_workable_hours was actually broken, because the field allocated_hours wasn't flushed when doing the SQL query. The new query flushes the field, and the test has been fixed. odoo/odoo#207404
Manufacturing orders no longer automatically mark components or byproducts as picked just because the production quantity is changed. This keeps inventory consumption and byproduct production aligned with explicit user actions or final production completion, reducing unintended stock updates.
Original PR description
When the quantity being produced in a MO is updated, the consumption of components and the production of byproducts were automatically picked. However, this behavior should only occur when the user manually picks it or when the production is completed. This commit fixes the issue and updates some tests to reflect the intended behavior. task: 4314900
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
A 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
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
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
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