Daily updates from Odoo
Friday, November 21, 2025
158 changes
10 changes
Resolved issues and error corrections
This fix corrects a configuration error in the Uruguayan e-invoicing stock flow that was causing a build failure. It helps ensure stock-related electronic document processing works as expected and avoids interruptions during deployment and validation.
Original PR description
runbot build error id: 234034 Forward-Port-Of: odoo/enterprise#99920
This fix prevents Odoo from showing an error traceback when the Egyptian e-invoice service rejects a request and returns a response that cannot be read as JSON. Instead, the error is now handled properly, giving users a smoother and more reliable invoicing experience.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update removes duplicate methods in several HR-related components. It helps keep the codebase cleaner and reduces the risk of inconsistent behavior or maintenance issues in these areas.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99927 Forward-Port-Of: odoo/enterprise#99809
This update adjusts Odoo’s internal code checks so they continue to run correctly with the latest pylint and astroid versions. It also fixes a couple of test-related warnings and removes a few false alerts, helping maintainers keep quality checks reliable without affecting normal business use.
Original PR description
- astroid 4 deprecates toplevel exports of nodes, thankfully that was never actually necessary so we can just import that unconditionally - remove support for pre-jammy pylint / astroid, specifically `astroid.nodes` was added in astroid 2.7.0 and `astroid.node_classes` deprecated then and removed in 3.0, this can affect Bullseye users as it shipped with astroid 2.5 - Astroid 4 changes `spec.Finder.find_module` in order to cache it (pylint-dev/astroid#2509), we can just make our method static for all versions as we don't need `self` anyway. - The mail test triggers `function-redefined` (E0102), fix it. - Skip the escpos script thing which triggers a bunch of `undefined-variable` (E0602) false positives. Forward-Port-Of: odoo/odoo#236530 Forward-Port-Of: odoo/odoo#236258
This change improves compatibility with Swedish cash register blackboxes by checking which protocol version they support during setup. As a result, receipts can be registered without triggering an "unknown message type" error on devices that only support the older protocol version.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
This update prevents the restaurant point of sale from creating a new order too early after a payment when preview skipping is enabled. It avoids errors on the floor plan and makes the checkout flow more reliable when using printers and preset selections.
Original PR description
**Steps to reproduce:** - In the config, click the ePos Printer checkbox - Also check Automatic Receipt Printing and Skip Preview Screen - Put a default preset with Name as it's identification - Go…
**Steps to reproduce:** - In the config, click the ePos Printer checkbox - Also check Automatic Receipt Printing and Skip Preview Screen - Put a default preset with Name as it's identification - Go in the restaurant and make a sale, pay for it - When going back to the floor plan, a traceback appears **Why the fix:** This current problem arises because we are trying to access the current order, but we are on the floor plan, so there is no current order yet. The order is undefined, so we try to access *undefined.floating_order_name* and a traceback appears. But the root issue is deeper than this. In the restaurant, the order is initialized when clicking a table, or when we create a floating order. But when the Skip Preview Screen option is enabled, we try to initialize the order right after the last order has been validated, like we do it in the normal PoS. Doing this, we will try to handle the preset selection way too early, as the order is not fully initialized yet, and we will try to access data that have not been set yet. The current error is not the only one we have with this setup, as other errors also arise if we bypass this specific error. To fix this, we are now only initilizing the new order when we click on a table that has no order or when making a floating order. We do not create a new order after the validation of the last one, even if the Skip Preview Screen option is enabled. This is only true in the restaurant, as we keep on initializing a new order after the validation in the regular PoS. Before this commit, we also tried to create a new order when opening the restaurant from the frontend (see image below), which resulted in a traceback. We now only create a new order if the default screen is different from the Floor Screen. <img width="375" height="249" alt="image" src="https://github.com/user-attachments/assets/e38520f6-81e2-471e-a987-98d9426a6493" /> Starting in version 19.0, there is another waiting screen after paying and before going back to the floor plan, which handles things, so the bug is not present anymore. But the traceback we get when opening the register from the frontend is still present in future versions. opw-5131309
This fix stops users from creating the same RFQ more than once when several tabs or users are working on the same approval. It helps avoid duplicate purchase quantities and prevents accidental over-ordering.
Original PR description
**Problem:** It's possible to click the "Create RFQ's" button more than once, as the user may have multiple tabs open or multiple users are viewing the same record. When this happens, the approval will create or add to an RFQ even if it already did, and this causes double the intended product quantities. **Solution:** The "Create RFQ's" button becomes hidden when purchase_order_count > 0 (i.e. there are linked POs) so we can perform this check within the button's method `action_create_purchase_orders` to prevent RFQ generation (or modification). opw-5227493 Forward-Port-Of: odoo/enterprise#99817 Forward-Port-Of: odoo/enterprise#99706
This update corrects how Italian EDI imports handle “Maggiorazione” discounts on vendor bills and credit notes. It prevents the line total from flipping sign or calculating incorrectly, so imported documents show the right amounts.
Original PR description
Since commit #206238, discounts of type "MG" (Maggiorazione) caused the line total amount sign to flip, leading to incorrect calculations of the total amount. **Steps to reproduce:** - Import a vendor bill/credit note XML (Italian EDI). - Include a line with a Maggiorazione discount. - The line total amount currently appears with the wrong sign and/or amount. Ticket [link](https://www.odoo.com/odoo/project.task/5220218) opw-5220218 Forward-Port-Of: odoo/odoo#236300
This update corrects the invoiced quantity on sales orders when a POS order is refunded from the backend. It ensures the sales order stays accurate after refunds, which helps avoid billing and reporting mismatches.
Original PR description
When doing a refund of a POS order linked to a SO in the backend, the qty_invoiced on the SO line is not updated correctly. Steps to reproduce: ------------------- * Create a SO with 1 quantity of any product * Settle the SO in the PoS * Refund the PoS order from the backend not from the PoS interface * Check the qty_invoiced on the SO line > Observation: The qty_invoiced is still 1 Why the fix: ------------ The method _compute_qty_invoiced was not triggered when the refunding order was paid. So we need to add a new dependency on the function. Note: ----------- In the test we need to flush all before doing the payment of the refund, because if we do not do it, the _compute_qty_invoiced method would be called during the payment. But that is not the case outside of the test. This is just to ensure that the test fails correctly without the fix. opw-4991405 Forward-Port-Of: odoo/odoo#236379 Forward-Port-Of: odoo/odoo#231840
This update corrects how product forecast quantities are calculated after stock moves are completed. Forecasts will now reflect the actual quantity received or delivered, instead of incorrectly using the original requested amount, which could show misleading negative or positive values in the past.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234576
14 changes
Resolved issues and error corrections
This fix prevents Odoo from showing an error traceback when the Egyptian ETA service rejects an e-invoice request and returns a response that cannot be parsed as JSON. Instead, Odoo now handles that case gracefully, improving reliability for users downloading e-invoices.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update prevents receipt registration errors with some Swedish black box devices that only support an older communication protocol. The system now checks the device version first and sends only compatible commands, reducing failed transactions at the point of sale.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
This change fixes an issue in the Uruguay electronic invoicing flow linked to stock operations. It prevents a build/runtime error caused by a method being assigned to the wrong field, helping ensure stock transfers work correctly with local e-invoicing rules.
Original PR description
runbot build error id: 234034 Forward-Port-Of: odoo/enterprise#99920
This change prevents errors from appearing when a user opens a partner record after uninstalling one of the e-invoice format modules. It keeps partner data consistent by updating the e-invoice format field during uninstall, avoiding unexpected tracebacks for users.
Original PR description
Before this fix, if you uninstalled this module and navigated to any partner that had a e-invoice format defined by this module, you'd have a traceback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12168 OPW-5172861 Forward-Port-Of: odoo/odoo#234791 Forward-Port-Of: odoo/odoo#232297
This update keeps Odoo compatible with the latest code quality checking tools used in development. It also adjusts a few test and script files so they no longer trigger false warnings, helping maintain smoother automated checks without changing business functionality.
Original PR description
- astroid 4 deprecates toplevel exports of nodes, thankfully that was never actually necessary so we can just import that unconditionally - remove support for pre-jammy pylint / astroid, specifically `astroid.nodes` was added in astroid 2.7.0 and `astroid.node_classes` deprecated then and removed in 3.0, this can affect Bullseye users as it shipped with astroid 2.5 - Astroid 4 changes `spec.Finder.find_module` in order to cache it (pylint-dev/astroid#2509), we can just make our method static for all versions as we don't need `self` anyway. - The mail test triggers `function-redefined` (E0102), fix it. - Skip the escpos script thing which triggers a bunch of `undefined-variable` (E0602) false positives. Forward-Port-Of: odoo/odoo#236530 Forward-Port-Of: odoo/odoo#236258
This update cleans up duplicated methods in a few business modules. It does not change the expected user experience, but it helps keep the codebase more reliable and easier to maintain going forward.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#99927 Forward-Port-Of: odoo/enterprise#99809
This change stops users from creating the same request for quotation more than once when they have multiple tabs open or when several people view the same approval. It prevents duplicate purchase quantities and avoids errors caused by accidentally updating an RFQ that already exists.
Original PR description
**Problem:** It's possible to click the "Create RFQ's" button more than once, as the user may have multiple tabs open or multiple users are viewing the same record. When this happens, the approval will create or add to an RFQ even if it already did, and this causes double the intended product quantities. **Solution:** The "Create RFQ's" button becomes hidden when purchase_order_count > 0 (i.e. there are linked POs) so we can perform this check within the button's method `action_create_purchase_orders` to prevent RFQ generation (or modification). opw-5227493 Forward-Port-Of: odoo/enterprise#99817 Forward-Port-Of: odoo/enterprise#99706
When creating a restaurant booking from the point of sale, all tables chosen on the form are now saved correctly. This fixes an issue where only one selected table could end up attached to the booking, which could cause seating mismatches and confusion for staff.
Original PR description
Currently, when creating a booking from inside a point of sale, if you select multiple tables, only one will be saved. Steps to reproduce: ------------------- * Open the restaurant * Open booking tab…
Currently, when creating a booking from inside a point of sale, if you select multiple tables, only one will be saved. Steps to reproduce: ------------------- * Open the restaurant * Open booking tab * Create a new booking for 3 people * Select 2 tables of 2 capacity * Save > Observation: Only one table resource is saved Why the fix: ------------ By having the context key `default_resource_total_capacity_reserved` we would recompute the resources for the booking. It was recomputed in a way that we just une the minimum resources needed in regards of the resource capacity. For example if we had 3 tables of 2 and we are booking for 3, we wouldn't need the 3rd extra table. In our case the capacity was always set to 2, as the point of sale form actually uses the field `waiting list capacity`. Since most table are usually for at leat 2 people only 1 would be needed. Removing `default_resource_total_capacity_reserved` from the context gives more freedom upon reservation and does not compute resources, it uses those selected on the form. opw-5109501 Community: https://github.com/odoo/odoo/pull/230920
This change fixes the annual corporate tax return so it uses the company’s actual fiscal year dates, even when the fiscal period is longer than one year. As a result, the dashboard now shows the correct annual closing and deadline, avoiding incorrect entries for the wrong year.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432
This update corrects a display issue in the Documents app where some controls could overlap, making the file details area harder to read and use. It also hides an action in the activity view that was no longer functioning, improving overall usability and reducing confusion for users.
Original PR description
This PR addresses the following UI issues in the documents app: - Fix the overlapping of the translate button of name with the file size in `DocumentsDetailsPanel`. - Hide the `DocumentsAction` in activity view as they were not working anymore. Technical ============================ - Set position: relative on .o_field_input_buttons. The .o_field_input_buttons had position: absolute by default, but since .o_documents_details_panel_name uses display: contents, the ancestor context for absolute positioning is lost. Because display: contents makes the parent disappear visually and the children behave as independent elements, the absolute positioning behaves unexpectedly. Setting position: relative on .o_field_input_buttons resolves this by providing a proper positioning context. Task-4792112
This change fixes an issue in the point of sale localization tests that could cause automated checks to fail during builds. It helps keep localization-specific POS features validated reliably, reducing unnecessary runbot failures.
Original PR description
Fix runbot issue runbot-233183 Forward-Port-Of: odoo/enterprise#99832 Forward-Port-Of: odoo/enterprise#99370
This update removes a fragile step from the generic Point of Sale localization test where the PoS was being closed at the end. That closing step was often unstable and slow in larger setups, so removing it makes the test run more reliably and finish faster.
Original PR description
backport of : https://github.com/odoo/odoo/pull/231884 Remove the closing of the PoS in the tour as it is really unstable and fail a lot. It's mostly due to the fact that the PoS take a long time to close with a lost of modules installed. This will also make the tour faster. runbot-233183 Forward-Port-Of: odoo/odoo#236372 Forward-Port-Of: odoo/odoo#234310
This update fixes the calculation of line totals when importing Italian EDI vendor bills or credit notes that include a Maggiorazione (MG) discount. It prevents the amount sign from flipping incorrectly, so totals are now shown and computed correctly.
Original PR description
Since commit #206238, discounts of type "MG" (Maggiorazione) caused the line total amount sign to flip, leading to incorrect calculations of the total amount. **Steps to reproduce:** - Import a vendor bill/credit note XML (Italian EDI). - Include a line with a Maggiorazione discount. - The line total amount currently appears with the wrong sign and/or amount. Ticket [link](https://www.odoo.com/odoo/project.task/5220218) opw-5220218 Forward-Port-Of: odoo/odoo#236300
The stock forecast now uses the actual completed quantity of a transfer instead of the originally planned quantity when a move is marked done. This prevents incorrect negative or leftover quantities from appearing in the forecast after receiving less or more than expected.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234576
4 changes
Resolved issues and error corrections
This update makes the Swedish POS blackbox driver detect which protocol version the device supports before sending commands. As a result, receipts can be registered without triggering "unknown message type" errors on devices that only support the older protocol.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
This update corrects a mistake where a calculated value was linked to the wrong field in the Uruguay electronic stock invoicing flow. It helps prevent build failures and ensures the related stock information is processed correctly.
Original PR description
runbot build error id: 234034 Forward-Port-Of: odoo/enterprise#99920
This update fixes several display issues in the Documents kanban view on mobile. It removes unnecessary spacing, lets folders and documents use the full available width in Recent, and makes it possible to scroll to see all items.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#90647
This update stops users from changing read-only grouped values by dragging items in Gantt views. It reduces the risk of accidental data changes in planning screens, especially when items are grouped by fields that should not be edited.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#99540 Forward-Port-Of: odoo/enterprise#94166
32 changes
Resolved issues and error corrections
Opening the warehouse “To Receive” view could crash when many transfers had many quality checks because too much quality-check data was loaded into memory. This change loads only the needed quality-check information, greatly reducing memory use and improving reliability for high-volume warehouses.
Original PR description
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive"…
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker. This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop. For a specific customer (opw-5025162), this was the case. Benchmarks: | No. stock.picking | avg no. quality checks | peak memory before | peak memory after | | ----------------- | ---------------------- | ------------------ | ----------------- | | 25 | 20 | 2771 mb | 235 mb | opw-5025162 Forward-Port-Of: odoo/enterprise#98304 Forward-Port-Of: odoo/enterprise#95568
Opening the Documents app no longer fails when it contains an upload request linked to a CRM lead that has since been deleted. The document now safely shows no related record name instead of triggering an error, helping users continue working without interruption.
Original PR description
Steps to reproduce: - Install crm and documents - Go to CRM → Activity Types - Set a folder in the Upload Document activity - Create a CRM lead and schedule an upload document activity - Delete the created lead - Open the Documents module Issue: - A traceback occurs because web_read tries to access values_by_id[record.id], as the upload request document remains in the database after its related activity is deleted. Solution: - fix the recompute of res_name and set it to False, avoiding MissingError opw-5080182 Forward-Port-Of: odoo/enterprise#97461
The LinkedIn integration now uses a supported API version after the previous version was discontinued. This helps prevent connection or publishing issues for businesses using LinkedIn social features.
Original PR description
This commit updates the linkedin version header so that we can use the version of the API. Our actual version was recently sunset, needing the change of version to be done. task-5271712 Forward-Port-Of: odoo/enterprise#99759
The Helpdesk timesheet total now displays the correct value when the company uses days or half-days instead of hours. This prevents misleading totals, such as showing 160 days instead of 2.5 days, and helps teams review logged work accurately.
Original PR description
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4.…
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4. Open the team’s settings and observe the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the team’s settings and observe the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------ After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed. Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36 For ex: Consider unit_amount = 20 minutes: **Before** Case 1: Encoding method = Hours/Minutes (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 1 = 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 8 = 160 Days --> INCORRECT **After** Encoding method = Days/Half-days (unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor (20 * 1) / 8 = 2.5 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. **NOTE:** Before this change, when the user opened the timesheet sublist view in debug mode and clicked the View button, it opened the default form view of the `account.analytic.line` model instead of the intended timesheet form view. This allowed editing of the Unit of Measure (product_uom_id) field also. To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41). Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related community PR: https://github.com/odoo/odoo/pull/233803 Forward-Port-Of: odoo/enterprise#98545
This fixes an issue in the Belgian salary contract module where the system tried to use a missing calculation function. It now reads the correct work time rate field, helping salary contract information load reliably.
Original PR description
The function _get_work_time_rate doesn't exist, but the information we need is in the field work_time_rate. Forward-Port-Of: odoo/enterprise#99922
The Sign send wizard no longer tries to read another user's saved signature or initials when it is not needed. This prevents access-rights errors in multi-role signing templates with multiple internal users, making document sending more reliable.
Original PR description
Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions: - sign.template with signature/initials fields and more than one…
Before this commit, The following traceback was encountered when the sign.send.request wizard was opened in the following conditions:
- sign.template with signature/initials fields and more than one role
- more than one sign user (internal user)
```
File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 341, in _compute_only_autofill_readonly
not (item.type_id.name == 'Signature' and request._get_user_signature(user, 'sign_signature')) and
~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/enterprise/sign/wizard/sign_send_request.py", line 323, in _get_user_signature
return user[signature_type]
~~~~^^^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 6680, in __getitem__
return self._fields[key].__get__(self)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/fields.py", line 1646, in __get__
record._check_field_access(self, 'read')
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
File "/home/user/workspace/odoo/src/19.0/odoo/odoo/orm/models.py", line 3426, in _check_field_access
raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.
```
This commit ensure that we don't try to access the signature/initial field of another user when it is not necessary.
task-5271648
Forward-Port-Of: odoo/enterprise#99940Closing or cancelling helpdesk tickets no longer causes an error when SLA working hours have been cleared or disabled. This keeps ticket workflows running smoothly even when teams do not use working hour policies.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 > Forward-Port-Of: odoo/enterprise#98889 Forward-Port-Of: odoo/enterprise#96546
This fix updates the external tax sales test flow so it stays compatible with recent related changes in the core sales experience. It helps ensure optional product sales scenarios continue to work reliably when external tax calculation is enabled.
Original PR description
See Also: - https://github.com/odoo/odoo/pull/227241 Forward-Port-Of: odoo/enterprise#99188
This fixes an error when signing Mexican electronic invoices through SW Sapiens. A stray space in the request data was removed so the service receives the expected information and no longer rejects the request with a null value error.
Original PR description
On Commit 6c4d07f a space was added to the payload lines in the request to sw sapiens, causing the payload to contain information that it should not have and leading to the error “value cannot be null.” <img width="2914" height="1552" alt="image" src="https://github.com/user-attachments/assets/04047f14-fc21-45fd-ae29-b241dfbbed2a" /> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Swedish point-of-sale blackbox integration now checks which protocol version a device supports before sending receipt commands. This prevents errors with older supported devices and helps businesses continue registering receipts reliably.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
The point of sale now loads only draft delivery orders when a session starts, avoiding unnecessary loading of already paid orders. This improves startup performance for businesses using Urban Piper delivery integrations and removes a minor console warning.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700
Forward-Port-Of: odoo/enterprise#99984
Forward-Port-Of: odoo/enterprise#99904This change reverts a previous adjustment that hid section and note lines in journal item tabs because it caused new journal entry lines to calculate debit and credit amounts incorrectly. Restoring the previous behavior helps ensure accounting entries are created accurately during editing.
Original PR description
This reverts commit 17d0e67106a30a46d608331680e5094dbc44e2e0. The commit is reverted because the `journal_line_ids` field is causing issues with onchange methods that rely on cached values. Specifically, the automatic computation of `debit`/`credit` when adding new lines to a journal entry was failing. While `journal_line_ids` (as a subset of `line_ids`) works correctly when the data is stored in the database, its absence during an onchange computation (which relies solely on cache) led to incorrect behavior. no-task Forward-Port-Of: odoo/enterprise#99875
Deferred half-day and hourly leaves now keep their actual duration when moved to the next month. This prevents payroll work entries from incorrectly counting partial leave as a full day, improving payroll accuracy for employees and HR teams.
Original PR description
When deferring half-day or hourly leaves to the next month, the work entry was incorrectly replaced with a full day duration instead of the actual leave duration. Now splits the work entry to match the exact leave hours when necessary. task-5258753 Forward-Port-Of: odoo/enterprise#99415
This fix prevents upgrade failures when creating timesheet entries from helpdesk tickets that do not have their own analytic account set. It preserves the correct project account instead of replacing it with an empty value, helping affected customers complete upgrades successfully.
Original PR description
When creating an analytic line from a helpdesk ticket, we assigned the account_id from the project's account_id during the upgrade. However, in the standard code, the account_id is later overridden and updated from ticket.analytic_account_id, which is null. As a result, the constraint "At least one analytic account must be set" is triggered. see: https://github.com/odoo/enterprise/blob/dcfef2cc462631f376a596a7c85ae483826835ad/helpdesk_timesheet/models/account_analytic_line.py#L119 Multiple upgrade request failed due to this. Forward-Port-Of: odoo/enterprise#99209 Forward-Port-Of: odoo/enterprise#99201
The VoIP test setup was corrected to include complete contact data, preventing a validation error during automated test runs. This improves test reliability without changing the user-facing VoIP experience.
Original PR description
Before this commit, running VoIP tests in HOOT results in this error: > Global OwlError: Invalid props for component 'TabEntry': 'title' is not a string, 'phoneNumber' is not a string This is because one of the test is setup with incomplete data (no phone number). After this commit, test data is correctly set with a phone number, fixing the props validation error. Forward-Port-Of: odoo/enterprise#100057
Fixed an issue where invoices could fail for alternative sales orders created from subscription upsells, even after customer payment succeeded. The alternative order now keeps the correct next invoice date, preventing incorrect deferred date calculations and ensuring invoices are issued as expected.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99919 Forward-Port-Of: odoo/enterprise#98983
The approval process now blocks creating a new request for quotation when one is already linked to the approval. This prevents accidental duplicate purchasing and inflated product quantities when users click the action multiple times or work from multiple tabs.
Original PR description
**Problem:** It's possible to click the "Create RFQ's" button more than once, as the user may have multiple tabs open or multiple users are viewing the same record. When this happens, the approval will create or add to an RFQ even if it already did, and this causes double the intended product quantities. **Solution:** The "Create RFQ's" button becomes hidden when purchase_order_count > 0 (i.e. there are linked POs) so we can perform this check within the button's method `action_create_purchase_orders` to prevent RFQ generation (or modification). opw-5227493 Forward-Port-Of: odoo/enterprise#99817 Forward-Port-Of: odoo/enterprise#99706
This update corrects access to car information in the Belgian salary contract flow. Regular users and applicants can now access the car-related details they need, reducing blocked or incomplete contract salary processes.
Original PR description
Normal users and applicant don't have access to car. Forward-Port-Of: odoo/enterprise#99658
Employees who are not HR officers can now request appraisal feedback without running into access errors. The change lets the appraisal feedback flow read the necessary employee information through the public employee mechanism, keeping the process usable for managers and reviewers.
Original PR description
Since we cannot ask a feedback when we are not an HR officer because we don't have acces to employees and we get an access right error when we try to ask feedback. So we use the hr.public.version mecanism to allow too read the employees without rights. Forward-Port-Of: odoo/enterprise#99947
The Documents sharing wizard now properly applies changes when allowing link access. This ensures users' sharing permission updates are retained, reducing confusion and preventing incorrect access settings.
Original PR description
This commit fix the 'action_allow_link_access' method in 'documents.sharing' model by adding the 'WRITE_VALUE_PREFIX' to the updated fields. Otherwise the changes wasn't taken into account. Task-5220965 Forward-Port-Of: odoo/enterprise#98382
VoIP now checks both the main call and transfer call before marking a call as ended unexpectedly. This prevents transferred calls from being incorrectly flagged, improving call history accuracy for users.
Original PR description
Currently, the check for calls that were ended in a wrong way only assumes that there is one call where there might be two calls in case of transfers. This commit fixes this issue by checking for both session, the main session and the transfer session. Task-5208152
IoT boxes now keep their own last received message position when reconnecting, instead of always being moved to the newest message. This helps prevent missed updates after short connection interruptions while still avoiding old stale messages when a device starts fresh.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236843 Before this commit, if an IoT box subscribed to the websocket we would always force its last message ID to be the latest (so no old messages would be sent). However, in the case of a brief disconnection, this could result in a message being missed. After this commit, we only force the last message ID to be the latest if the IoT box does not provide its own last message ID. This way, we still avoid the issue of stale messages on boot, but allow disconnections to not result in missing a message.
Barcode scans for kit components now update the existing reserved line when a different unreserved serial or lot is scanned, instead of creating a duplicate line. This prevents unnecessary backorder prompts and helps warehouse operators complete deliveries accurately.
Original PR description
### Issue: Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that…
### Issue:
Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.
### Steps to reproduce:
- Create a kit product with a kit BOM:
- 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation
### Cause of the issue:
Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does, the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921
### Fix:
In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.
opw-5100026
Forward-Port-Of: odoo/enterprise#99845
Forward-Port-Of: odoo/enterprise#98589Changing the quantity being produced from the barcode manufacturing flow now correctly updates and consumes the related component quantities. This prevents production orders from leaving required materials unconsumed, improving inventory accuracy for barcode-based manufacturing operations.
Original PR description
Steps to reproduce: 1- Create MO 2- Change the `qty_producing` Issue: `stock.move.lines` are not consumed. Because `qty_producing` is not a computed field therefore it has no inverse. It updates the consumption with an on change method and in Barcode we don't have `move_raw_ids` in the xml, so its not stored or saved. To fix the problem, `set_qty_producing` was called manually to keep the barcode's design clean. Task: 5111357 Forward-Port-Of: odoo/enterprise#98184
The VoIP test setup was adjusted so mobile device behavior is only simulated where it is needed. This prevents unrelated tests from being affected, improving confidence in automated test results without changing customer-facing functionality.
Original PR description
Since [1], mockUserAgent was called at the root of the module. In this case, it applies globally. This commit moves user agent mocking in `keypad.mobile.test.js` into `beforeEach` and switch to the platform-based "android" helper so it only applies to this suite. [1]: https://github.com/odoo/enterprise/commit/b118a5ceb7f0773783ca003c625c9ae3cccdebed
When a stock move quantity is increased, the system now adjusts the existing reserved line instead of creating an extra line without tracking details. This keeps barcode manufacturing stock flows more consistent and reduces confusion in inventory handling.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit correct some tests values because increasing the quantity on a stock move will increase the existing move line quantity instead of creating a new one. Forward-Port-Of: odoo/enterprise#96750
Fixed an issue where rental prices could be calculated from the default start date instead of the customer's selected start date when unavailable days were configured. This prevents customers from being charged for the wrong number of nights after changing rental dates.
Original PR description
**Issue:** Price is wrongly calculated on period Night when we have Unavailability days. **How to reproduce:** Product A with Nightly rental period. Let's say price = 100. If you're testing on a Monday, go to the settings of the Rental app. Select Wednesday as an Unavailable days (= day + 2). The next starting default date will be day +1 but the next ending default date won't be day +2. Default dates: Tuesday -> Thursday (skipping Wednesday) = **2 nights**. Computed price: **200**. OK. Select another day where day + 1 is ok for renting. Example, Thursday. Default dates: Thursday -> Friday = **1 night**. Computed price: **200**. NOK. **Reason:** The price computation is based on the default start date instead of the selected start date. Unavailability days can increase the duration, but from a wrong starting date. Issue introduced in 3e257042a9a0774e297c8fd07e651eda4613b902 Forward-Port-Of: odoo/enterprise#100085
Creating a new salary offer from an employee record no longer fails because required offer information is lost during setup. This prevents an interruption in the HR offer workflow and keeps offer generation reliable for users.
Original PR description
To reproduce: 1-Navigate to an existing employee. 2-Create a new offer for the employee using "Offers" smartbutton. -The issue firstly appeared because of this commit: https://github.com/odoo/enterprise/commit/b251408ddc16f5f76dc0dcf1270bd4a8424c7b3b -The issue appears because the form is not populated with the context data. This is because upon offer generation, the context is overridden by recomputation of payslips that happens in write() in hr.version model. -The issue should have appeared earlier, however it didn't happen by luck because the dependency check in the commit mentioned above was too specific. Proposed solution: -Send a flag in the context to avoid recomputation upon open generation. Task-id:5245134
Updated VoIP test setup to use the browser platform mock in the intended way. This helps keep automated checks reliable and reduces the risk of false test results during future updates.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac", "windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be added to the user agent string.
This commit adapts its usage(s) accordingly.
Forward-Port-Of: odoo/enterprise#100154This update keeps PDF previews working correctly in Documents after a PDF viewer change affected file links. It also keeps Sign form text readable when users or browsers use dark mode.
Original PR description
In the new version of PDF.js (viewer.js) there is these new lines:
```javascript
const queryString = document.location.search.substring(1);
const params = parseQueryString(queryString);
file = params.get("file") ?? AppOptions.get("defaultUrl");
try {
file = new URL(decodeURIComponent(file)).href;
} catch {
file = encodeURIComponent(file).replaceAll("%2F", "/");
}
```
This has an effect in document as the PDF file are not readable anymore
due has URL is not correct anymore.
To avoid malformed URL we removed the options `download=0`.
---
In the Sign app we need tho force the color of cell as now PDF.js
(iframe) enable color scheme:
```css
:root {
color-scheme: light dark;
}
```
So the `fieldtext` value will be white in dark mode, and we don't want
that.
task-5110143Planning analysis reports now only count shifts when they fall within an employee's working hours. This prevents hours from being incorrectly included in a later month when a shift ends after working hours, improving reporting accuracy for timesheets and planning.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
This change avoids saving data into a field that is automatically calculated by the system. It helps prevent hidden data inconsistencies that could cause errors during product barcode lookup operations.
Original PR description
The field all_group_ids is computed from other groups, writing on it creates inconsistencies in the cache and may result in errors when invalidating/flushing.
18 changes
Resolved issues and error corrections
The employee contract template activity view now shows only records with assigned activities, instead of listing every contract template. This makes the Activities view accurate and easier for users to work with.
Original PR description
The contract template’s activity view incorrectly displays all contracts, instead of only those with assigned activities. **Steps to reproduce this issue:** 1) Install the hr module. 2) Open Employees → Employees → Contract Templates. 3) Create multiple contract templates and add an activity to one of them. 4) Open the activities from the Activities (top right corner). **Issue:** You will end up in the all contract templates list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied to the view. But in the contract template, we don't have any search filters for the activities. Therefore, it renders all contract records. **Solution:** Add the activity search filters for the contract template records. opw-5209691 Forward-Port-Of: odoo/odoo#234274
This change fixes an issue where invoices could fail to generate for alternative sales orders created from subscription upsells. The system now carries over the needed billing date so customers who have already paid can receive their invoice without errors.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99919 Forward-Port-Of: odoo/enterprise#98983
This change prevents an error that could appear when opening the Project app after the Databases module has been uninstalled. It restores a safe fallback rule so the app continues to work normally even when that module is no longer present.
Original PR description
Steps to reproduce: ------------------- 1. Install the `databases` module. 2. Uninstall the `databases` module. 3. Open the Project app. Issue: ------ A traceback occurred: ``` ValueError: Invalid…
Steps to reproduce:
-------------------
1. Install the `databases` module.
2. Uninstall the `databases` module.
3. Open the Project app.
Issue:
------
A traceback occurred:
```
ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)
```
Cause:
------
The `databases` module updates the `domain_force` of the project record
rule [project.project_project_manager_rule](https://github.com/odoo/odoo/blob/da0333db5d0a0464e39e41e9409810876c56a275/addons/project/security/project_security.xml#L57-L62) to include the field `database_hosting`.
When the module is uninstalled, the `database_hosting` field is removed,
but the record rule remains (it belongs to the `project` module).
Solution:
---------
Update the record rule domain_force with project [domain_force ](https://github.com/odoo/odoo/blob/da0333db5d0a0464e39e41e9409810876c56a275/addons/project/security/project_security.xml#L60)as a safe fallback domain_force.
opw-5321878This fix ensures combo products show the correct total on the self-order success screen. Previously, the combo parent line was counted twice, which could make the displayed price appear doubled; now the total matches the real amount paid.
Original PR description
Steps to reproduce ------------------ In pos self order, choose a combo product and checkout. Notice that the price shown on the "success" screen is double the combo price. Why it's happening…
Steps to reproduce ------------------ In pos self order, choose a combo product and checkout. Notice that the price shown on the "success" screen is double the combo price. Why it's happening ------------------ When displaying the order price, we sum the `price_subtotal_incl` of all its lines. In a combo order, for each combo product, we have a combo parent line and its children lines. We rely on `price_subtotal_incl` of the combo parent line to be 0, and the price thus will be the sum of `price_subtotal_incl` of the children combo lines. After https://github.com/odoo/odoo/commit/9538698f13d5763b49b00f4c06a1a2afc0d6b39e, we are setting the combo line's `price_subtotal_incl` to the sum of the price of its children, so it's no longer 0 making the calculation wrong, i.e. it's summing twice the price. The Fix ------- We now set the `price_subtotal_incl` to `priceIncl` and not to `displayPrice` anymore. Which makes sure a combo parent line has 0 price. opw-5247554
This change updates the packaging Docker setup to use the currently supported Ubuntu Noble base image instead of Bookworm. It also removes unnecessary wait steps that were masking an underlying issue, which should make the build process cleaner and more reliable.
Original PR description
The Dockerfile used for source package is still using the Bookworm distribution as base image. In order to be consistent with the Odoo supported distribution, let's update to Ubuntu Noble. This commit also removes useless `sleeps` that were hiding a real bug. It should help declutter #228456
Fixed an issue where overnight rental prices could be calculated incorrectly when some days are unavailable. The system now uses the actual chosen rental dates, so customers are charged the correct amount even when default dates need to skip unavailable days.
Original PR description
**Issue:** Price is wrongly calculated on period Night when we have Unavailability days. **How to reproduce:** Product A with Nightly rental period. Let's say price = 100. If you're testing on a Monday, go to the settings of the Rental app. Select Wednesday as an Unavailable days (= day + 2). The next starting default date will be day +1 but the next ending default date won't be day +2. Default dates: Tuesday -> Thursday (skipping Wednesday) = **2 nights**. Computed price: **200**. OK. Select another day where day + 1 is ok for renting. Example, Thursday. Default dates: Thursday -> Friday = **1 night**. Computed price: **200**. NOK. **Reason:** The price computation is based on the default start date instead of the selected start date. Unavailability days can increase the duration, but from a wrong starting date. Issue introduced in 3e257042a9a0774e297c8fd07e651eda4613b902
This update prevents an error that could occur when an employee checks out from attendance. It now correctly handles cases where there are multiple attendance entries for the same day, so checkout works reliably instead of failing.
Original PR description
The system raises an error when a user attempts to checkout through any method. Steps to produce: - Install hr_attendance without demo. - Settings > Under Work Organization > set schedule with 0…
The system raises an error when a user attempts to checkout through any method. Steps to produce: - Install hr_attendance without demo. - Settings > Under Work Organization > set schedule with 0 working hours.([Example]) - Employees > Administrator > under settings > set Overtime Ruleset as `Default Ruleset`. - Now to attendance > kiosk > do checkin - checkout server time. Error: `ValueError: Expected singleton: hr.attendance.overtime.line(171, 172, 173)` Cause: - [Here], the system retrieves the attendance duration for today and assumes it exists in only one record. However, multiple attendance records can exist for the same day. Solution: - This fix updates the logic to compute the sum of all attendance durations for that employee for today, instead of expecting a single record. [Example]: https://drive.google.com/file/d/12cdXOHtE11ytCBotVr6FDszK7xHndbm_/view?usp=sharing [Here]https://github.com/odoo/odoo/blob/e387c4a706a7d24b437e75c3d5970e5786626dc9/addons/hr_attendance/controllers/main.py#L46-L47 sentry-7024592646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the barcode app and quality checks from asking users to handle products that were not actually picked, or lot/serial-controlled items that are not yet fully identified. It makes the quality-check flow match what will really be validated, reducing confusion and avoiding unnecessary steps during receipt processing.
Original PR description
*: {stock_barcode_,}quality_control #### There are two issues addressed in this PR: 1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.…
*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:
1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.
### Steps to reproduce:
- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed
### Expected behavior:
Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.
### Cause of the issue:
Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72
### Fix:
Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590
Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.
Task: 4716252
opw-5010764
Forward-Port-Of: odoo/enterprise#99736
Forward-Port-Of: odoo/enterprise#99565The point of sale integration now checks which version of the Swedish blackbox protocol is supported before sending commands. This prevents receipt registration errors on devices that only support the older protocol version.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448 Forward-Port-Of: odoo/enterprise#99930 Forward-Port-Of: odoo/enterprise#99008
The Point of Sale now opens the product configurator even when a product only has one option, if that option includes a free-text field. This ensures staff can enter customer-specific text for products that require customization instead of being blocked by a missing input screen.
Original PR description
**Steps to reproduce:** - Make a new product, make a single variant with a single value for it - The variant value should have the Free Text checkbox enabled - Go to PoS, click on said product - The product configurator will not be displayed, so there is no way to write on this Free Text field **Why the fix:** Before this commit, we did not display the product configurator if all variant attributes were single choice, because it did not make sense to show it just for the user to click on confirm. But this did not account for the fact that if a Free Text option is enabled, we should still display it, so that the user can write whatever they want on it, even if it is the only option available. We now display the product configurator in all cases where a Free Text field is present, as we need the customer to be able to fill it, even if it is the only available option. opw-5133743 Forward-Port-Of: odoo/odoo#231476
This change prevents browser warning popups from interrupting website test tours when a page redirects or reloads. It also adjusts a few tour selectors so the automated tests run more reliably, reducing delays and false failures.
Original PR description
During page redirection in tours, the browser was showing a warning about unsaved/incomplete data loss. This warning is not relevant in the context of tours. To address this, the expectUnloadPage attribute is added to the tour test. It prevents unnecessary pauses/timeouts caused by the browser’s warning and ensures smooth redirection handling. Additionally, few tour selectors have been corrected to improved. runbot-231587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226102
This change prevents an error that could appear when uninstalling the Databases module. It restores the correct access rule so the uninstall process completes cleanly without leaving behind a broken reference.
Original PR description
Currently an error occurs when user uninstalls the `databases` module. **Steps to replicate:** * Install and uninstall databases **Error:** `ValueError: Invalid field project.project.database_hosting…
Currently an error occurs when user uninstalls the `databases` module.
**Steps to replicate:**
* Install and uninstall databases
**Error:**
`ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)`
**Root cause:**
* This error happens because when the user installs `databases`, record rule [1] is created by the module and it overrides rule [2]. Later, when databases is uninstalled, rule [1] is still there, but it tries to access the field 'database_hosting' [3], which was removed during the uninstall. Since that field no longer exists, it causes an error.
**Solution:**
* Revert the domain back to the one defined in project module.
[1]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/security/databases_security.xml#L43-L46
[2]:
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/project/security/project_security.xml#L57-L62
[3]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/models/project_project.py#L17-L26
sentry-7035410943This fix ensures that when a manufacturing order’s planned output quantity is changed in Barcode, the related material consumption is correctly updated. It prevents mismatches between what operators enter and what is actually consumed, improving accuracy in production tracking.
Original PR description
Steps to reproduce: 1- Create MO 2- Change the `qty_producing` Issue: `stock.move.lines` are not consumed. Because `qty_producing` is not a computed field therefore it has no inverse. It updates the consumption with an on change method and in Barcode we don't have `move_raw_ids` in the xml, so its not stored or saved. To fix the problem, `set_qty_producing` was called manually to keep the barcode's design clean. Task: 5111357
This change prevents users from generating or updating a Request for Quotation more than once from the same approval request. It avoids accidental duplicate quantities when the action is clicked again from another tab or by another user.
Original PR description
**Problem:** It's possible to click the "Create RFQ's" button more than once, as the user may have multiple tabs open or multiple users are viewing the same record. When this happens, the approval will create or add to an RFQ even if it already did, and this causes double the intended product quantities. **Solution:** The "Create RFQ's" button becomes hidden when purchase_order_count > 0 (i.e. there are linked POs) so we can perform this check within the button's method `action_create_purchase_orders` to prevent RFQ generation (or modification). opw-5227493 Forward-Port-Of: odoo/enterprise#99817 Forward-Port-Of: odoo/enterprise#99706
This fix ensures that sales orders linked to a Point of Sale refund update their invoiced quantity correctly in the backend. It prevents cases where the sales order still showed the original invoiced amount after a refund, which could lead to inaccurate reporting and customer/order tracking.
Original PR description
When doing a refund of a POS order linked to a SO in the backend, the qty_invoiced on the SO line is not updated correctly. Steps to reproduce: ------------------- * Create a SO with 1 quantity of any product * Settle the SO in the PoS * Refund the PoS order from the backend not from the PoS interface * Check the qty_invoiced on the SO line > Observation: The qty_invoiced is still 1 Why the fix: ------------ The method _compute_qty_invoiced was not triggered when the refunding order was paid. So we need to add a new dependency on the function. Note: ----------- In the test we need to flush all before doing the payment of the refund, because if we do not do it, the _compute_qty_invoiced method would be called during the payment. But that is not the case outside of the test. This is just to ensure that the test fails correctly without the fix. opw-4991405 Forward-Port-Of: odoo/odoo#236379 Forward-Port-Of: odoo/odoo#231840
This fix corrects how Maggiorazione (MG) discounts are handled when importing Italian EDI vendor bills and credit notes. It prevents the line total from being flipped to the wrong sign, ensuring invoice totals are calculated correctly.
Original PR description
Since commit #206238, discounts of type "MG" (Maggiorazione) caused the line total amount sign to flip, leading to incorrect calculations of the total amount. **Steps to reproduce:** - Import a vendor bill/credit note XML (Italian EDI). - Include a line with a Maggiorazione discount. - The line total amount currently appears with the wrong sign and/or amount. Ticket [link](https://www.odoo.com/odoo/project.task/5220218) opw-5220218 Forward-Port-Of: odoo/odoo#236300
This update fixes a website editor issue where shape previews could stay stuck after moving the mouse away, especially when image hover effects were enabled. It ensures the preview correctly returns to the original image so editors see the right shape and settings while working.
Original PR description
After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape. Steps to see the issue: - Open website and start editing - Drop…
After hover effect has been added back in this [commit], we could see an issue when we had a hover effect and tried to preview a shape. Steps to see the issue: - Open website and start editing - Drop a text-image snippet onto the page. - Then add a hover effect to the snippet image. - Open the image shape selector and hover over the shapes. => Bug: the preview is broken; when the mouse leaves a shape, the original shape is not reset. Same issue with other options when there is a hover effect on an image (e.g. "image Filter"). Current flow is: We are previewing shape -> img src is changed -> `originalImgSrc` in `ImageShapeHoverEffect` interaction is changed -> we revert preview -> img src is reverted, but MutationObserver doesn't change `originalImgSrc` immediately, and when reverting a step, we stop the interaction -> destroy is called and image source is set to `originalImgSrc`, but it is the old one with a shape. We want to update the `src` only if it is currently the one that we set as hovering. [commit]: https://github.com/odoo/odoo/commit/80b5db99a3c26c3dd4fb5c55e04b8813dddb5b8d task-5207382 Forward-Port-Of: odoo/odoo#233381
This fix corrects how amounts are handled when converting between invoices and credit notes with storno enabled. After the change, the values stay on the correct debit or credit side and only their sign changes, which prevents wrong accounting amounts from appearing.
Original PR description
This commit fixes the amounts of move lines when converting from invoice to credit note and vice versa when storno is enabled. Previously, when converting from invoice/credit note, the amounts remained negative and switches from debit/credit. The quantities should remain in same debit/credit position and only change sign as I switch from invoice/credit note. task-5226311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234027
11 changes
Resolved issues and error corrections
This change prevents website page saves from crashing when an embedded code block is missing required attributes. Instead of failing with an internal error, the system now validates the content and raises a clearer message, making editing more reliable for website users.
Original PR description
Currently, an error occurs when saving a website page that contains an embedded element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes. **Steps to produce:** - Install the…
Currently, an error occurs when saving a website page that contains an embedded
element missing the `'data-oe-type'`, `'data-oe-field'`, or `both` attributes.
**Steps to produce:**
- Install the `website` module.
- Open the `Website` app and click `Edit`.
- Drag an `Embed Code` block and add one of the following examples:
`<span data-oe-field='name' data-oe-model='res.partner' />`
or
`<span data-oe-type='int' data-oe-model='res.partner' />`
- Try to `Save` it.
**Error:**
`TypeError: can only concatenate str (not 'NoneType') to str `
`KeyError: None`
**Root Cause:**
At [1], the code tries to concatenate `'ir.qweb.field.' + el.get('data-oe-type')`,
but when `data-oe-type` is missing, `el.get('data-oe-type')` returns `None`,
causing an `error`.
At [2], when the `data-oe-field` attribute is missing, the code
tries to access `Model._fields[field]`, resulting in an `error`.
**Fix:**
This commit adds validation for missing attributes in the embedded
element, ensuring a clear error message is raised instead of a crash.
[1]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L67
[2]:
https://github.com/odoo/odoo/blob/4fca401148ed798b9c1d04674b44c3287ded5679/addons/web_editor/models/ir_ui_view.py#L71
sentry–6675421840Invoicing-only users in the India localization could hit an access error when creating or posting invoices. This update gives the invoicing group the read access it needs, so invoice processing works smoothly when the related accounting features are installed.
Original PR description
In India localization, invoicing-only users were getting an AccessError on `account.fiscal.year` when creating or posting invoices. This happened when both l10n_in_withholding and account_accountant modules were installed. Added missing read access for the invoicing group to resolve the issue. Reference computation: During computation of TDS/TCS, warning `compute_fiscalyear_dates` method is called https://github.com/odoo/odoo/blob/7afe40e50d88448dd966d20f5ae7ac84d986e405/addons/l10n_in_withholding/models/account_move.py#L124 In the `compute_fiscalyear_dates` method, it searches for 'account.fiscal.year' records https://github.com/odoo/enterprise/blob/f79601c62ca629dc01a5c1ad5520b0bb44a169d0/account_accountant/models/res_company.py#L162 As invoicing-only users don't have access to 'account.fiscal.year' records It will raise AccessError Task-5346551
This fix makes website anchor links behave as users expect when “Open in New Window” is enabled. Instead of staying in the same tab and scrolling on the page, the link now opens in a new tab while still jumping to the selected section.
Original PR description
Steps to Reproduce: 1. Create an anchor link for any dropped snippet. 2. Insert the link through the link popover. 3. Enable the "Open in New Window" option. 4. Click on Save. 5. Click on the link. Issue: Even though the "Open in New Window" option is enabled, the page scrolls in the same tab instead of opening in a new window and scrolling to the targeted view. Reason: When an anchor link has target="_blank", `ev.preventDefault()` was still being called, which prevented the browser from performing its default behavior of opening the link in a new tab. Fix: Removed `ev.preventDefault()` for such links, as the expected behavior is to open them in a new tab whenever target="_blank" is set. Additionally, the offcanvas mobile-specific logic has been removed, as it is no longer necessary now that `ev.preventDefault()` is no longer used. task-5104027 Forward-Port-Of: odoo/odoo#228787
This change prevents Odoo from showing an unexpected traceback when Egypt’s ETA rejects an e-invoice download request and the response cannot be read as JSON. Instead, the error is now handled properly, resulting in a smoother and clearer user experience when a request fails.
Original PR description
Before this commit: Steps 1) When clients try to download e-invoice for ETA 2) If ETA rejects the request, Odoo fails to parse to JSON 3) a JSONDecodeError exception is raised 4) Odoo doesn't catch it and a traceback is raised => A JSONDecodeError is raised but actually it's not json.decoder.JSONDecodeError, it's actually requests.exceptions.JSONDecodeError as mentioned here https://requests.readthedocs.io/en/latest/api/#requests.JSONDecodeError After this commit: If the request is rejected and Odoo failed to parse the response to JSON the exception is catched properly. opw-5241411 opw-5272195 Forward-Port-Of: odoo/odoo#236672
This update fixes a layout issue that could hide or break the exchange rate section on printed invoices when multiple GCC localization apps are installed together. It helps ensure invoices render correctly for affected companies, especially when using a foreign currency.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Certification lines now refresh their status color correctly when a certificate passes its end date. This ensures the Certifications report reflects the current situation without requiring any manual change.
Original PR description
**Steps to reproduce:** 1. Install `hr_skills_survey` 2. Go to Employees > Reporting > Certifications. 3. Create a certification line with a future end date → record shows in black. 4. Change the system date to after the end date. **Issue:** - The line color is not updated when time passes. **Cause:** https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/models/hr_resume_line.py#L17 https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/hr_skills_survey/views/hr_employee_certification_views.xml#L7 - The color was based on the stored computed field `expiration_status`, which only depends on `date_end`. Since `date_end` does not change with time, the field value is not recomputed daily. **Solution:** - Introduce a non-stored computed field `expiration_status_ui`, depending on `date_end` and use it in the view to update expiration_status. opw-5065185
This fix prevents the system from mixing different products when calculating average cost during stock valuation. As a result, validating returns and related deliveries works reliably, avoiding an error that could block normal warehouse operations.
Original PR description
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial…
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product. The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error. Steps to reproduce: - Create storable products P1 and P2: - Category: AVCO - P1 UoM: Unit - P2 UoM: Dozen - Create a sale order with 1 unit of P1 - Confirm the SO - Open the generated picking - Duplicate it → a new picking is created and still linked to the same SO - Change the product on the duplicated picking to P2 - Confirm and validate it - Create a return on this picking and validate it - Go back to the original picking of P1 and try to validate it Problem: A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)” This fix ensures that average price is computed only using stock moves belonging to the same product. opw-5027089
This change fixes an access issue that prevented invoicing-only users from opening or creating invoices when a TDS/TCS warning was present. As a result, teams with limited invoicing access can continue their work without unexpected permission errors.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551
This fix makes the vendor on-time delivery rate display the same value in the smart button and the graph. It now calculates against the original purchase order quantity, so partial receipts and duplicated receipts no longer distort the result.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#225529
The Documents settings page now shows clearer labels and helper text for each access right option. This makes it easier for administrators to understand what each permission does and choose the right setting with confidence.
Original PR description
This commit fix the label of documents access rights which now shows a helper for each documents res.groups. Task-5186096
Exchange rates from the Swiss Federal Tax Administration are now saved with the correct publication date instead of the later validity date. This ensures the dates shown in Odoo match the actual rate information received from the source.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127
11 changes
Resolved issues and error corrections
This update prevents an error when a badge is scanned for an attendee who is not linked to any sale order. It ensures the system treats these registrations as free by default, so event staff can scan badges without interruption.
Original PR description
Currently an error occurs when the user is scanning a badge that is not linked to a sale order. Steps to Reproduce: - Install 'event_sale' module. - Go to Events > Registration Desk ; click on Select…
Currently an error occurs when the user is scanning a badge that is not linked
to a sale order.
Steps to Reproduce:
- Install 'event_sale' module.
- Go to Events > Registration Desk ; click on Select Attendee >> New.
- Select any Event and then save it, A pdf having QR code would be generated.
- Now download that pdf.
- Go back to Events > Registration Desk ; click on Scan a Badge(Tap to scan) and
scan your QR Code.
- The error would be generated.
Traceback on sentry:
```
KeyError: False
File "odoo/http.py", line 2150, in __call__
response = request._serve_db()
File "odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1953, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 464, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 435, in _call_kw_model
result = method(recs, *args, **kwargs)
File "addons/event/models/event_registration.py", line 161, in register_attendee
res = attendee._get_registration_summary()
File "addons/event_sale/models/event_registration.py", line 136, in _get_registration_summary
'sale_status_value': dict(self._fields['sale_status']._description_selection(self.env))[self.sale_status],
```
This error arises at [1] when it attempts to access the dictionary with the key
'self.sale_status', but when 'self.sale_status' was False or not set, it
resulted in a KeyError.
This commit fixes the above issue by giving 'free' as the default value of sale
status as there is no sale order available.
Link: [1]-https://github.com/odoo/odoo/blob/c1d250fcbc178eaee1694197b759d3717e3b50e6/addons/event_sale/models/event_registration.py#L136
sentry-4620674401
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents a crash when someone enters an invalid Sendcloud tracking reference. Instead of an unexpected error, users now see a clear message explaining that the tracking code is not valid, which makes the issue easier to understand and resolve.
Original PR description
This traceback arises when the user gives an invalid tracking reference. <h4>To reproduce this issue:-</h4> 1) Install `delivery_sendcloud` 2) Create a new shipping method in `inventroy/configiration` 3) Make the provider `sendcloud` and give any key and secret 4) Now create a `delivery picking` from `Inventory/Operation/Delivery` 5) In `additional Info` select the carries as above created `shipping method` 5) Give any `tracking reference` 6) Click on `tracking` stat button Error:- ``` TypeError: 'bool' object is not subscriptable ``` When the user gives an invalid tracking reference it leads to the above traceback as there will be no `picking.sendcloud_parcel_ref` https://github.com/odoo/enterprise/blob/d91b91626fb488a98d10757142ad14cc9ff7d503/delivery_sendcloud/models/delivery_carrier.py#L188 After applying this commit will resolve this issue by raising a user exception. sentry-5096109840
This update prevents a crash that could happen when a user changes the expression label in the Generic Tax report. It ensures the Tax Report still opens normally even if that label has been renamed, improving reliability for accounting users.
Original PR description
This traceback occurs when the user changes the expression label of the column in the `Generic Tax report`. To reproduce this issue:- 1) Install `account_reports` 2) Open `Generic Tax report` from `Accounting Reports` 3) In `columns` change the `Expression Label` of tax and save the record 4) Open the `Tax Report` from `Reporting` 5) A traceback occurs Error:- ``` UnboundLocalError: local variable 'col_value' referenced before assignment ``` Because `col_value` is assigned based on the `expr_label` if it doesn't match the `if` conditions it leads to a traceback. https://github.com/odoo/enterprise/blob/d154cbf1bd5b4cc104ff0e2443047aff0c05330f/account_reports/models/account_generic_tax_report.py#L920-L932 After applying this commit will resolve this issue by assigning a fallback value of an empty string to col_value. sentry-5307746934
This update prevents an error when opening the restaurant mobile menu if the company has no country set. It helps keep the POS self-order flow working even when that company setting is left blank.
Original PR description
This issue arises when a user removes the `country` from their company and then attempts to open the `mobile menu` for the restaurant using the POS module. Steps to produce : - Install…
This issue arises when a user removes the `country` from their company and then attempts to open the `mobile menu` for the restaurant using the POS module.
Steps to produce :
- Install `pos_self_order` module.
- Navigate to Settings > User & Companies > Companies
- Open your company > Remove the country of your company.
- Now go to POS module open the `mobile menu` for the restaurant.
- Error will be generated.
See traceback :
```
IndexError: list index out of range
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1873, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/pos_self_order/controllers/self_entry.py", line 58, in start_self_ordering
**pos_config._get_self_ordering_data(),
File "addons/pos_self_order_epson_printer/models/pos_config.py", line 11, in _get_self_ordering_data
data = super()._get_self_ordering_data()
File "addons/pos_online_payment_self_order/models/pos_config.py", line 20, in _get_self_ordering_data
res = super()._get_self_ordering_data()
File "addons/pos_self_order/models/pos_config.py", line 335, in _get_self_ordering_data
"country": self.company_id.country_id.read(["vat_label"])[0],
```
This issue occurs because here
https://github.com/odoo/odoo/blob/78cbdc604ec6ef48ef291d354126d7b171eaec64/addons/pos_self_order/models/pos_config.py#L335 when try to access the `country_id` it will not get that because country was not selected in the company and also the country was not a required field.
sentry-4769344261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents backend crashes when a user enters invalid content while editing a report in Studio. Instead of failing silently or generating a server-side error, the editor now shows a user-friendly message so the issue can be corrected more easily.
Original PR description
Currently, an error is generated in backend when editing any reports in studio mode with an incorrect value or syntax. Steps to reproduce(edit a report of 'account' module to generate an error as an example): - Install an 'account' and 'web_studio' module. - Navigate to invoicing / Customers / Invoices and open a web studio mode. - Open reports and click any reports. - Click on 'EDIT SOURCES' to modify the report with incorrect values or syntax and an error will generated in the backend. To resolve the issue, we will add a try-except block at [1] to handle errors. This will ensure that if an error occurs during editing, it will raise a user error message and this error message will be seen in the report editor. link [1]: https://github.com/odoo/enterprise/blob/f94ca3f5ac02e932bb986c4f151733927acdd98c/web_studio/controllers/report.py#L666 sentry-5128667236
This update corrects an issue where the French Balance Sheet could become out of balance for companies using the 2024 chart of accounts. It ensures missing income and expense balances are still included when calculating retained earnings, so financial reports remain accurate and compliant.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well.
This update fixes an issue where clicking the Pack button in the purchase catalog could sometimes stop increasing the quantity, especially for products with decimal packaging sizes. It ensures the quantity is calculated more reliably so users get the expected number of packs every time.
Original PR description
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a…
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a product - Set a vendor "Mom" - Add a packaging of some decimal number, eg 22.68 - Create a new purchase from "Mom" - Open the catalog - Click the product once - Click the "pack" button 4 times (# of clicks required depends on the pack amount) > The last click did not increase the product quantity Cause ----- Javascript floats are sometimes an approximation of the value rather than the value itself. This means that when we do https://github.com/odoo/odoo/blob/0611a74cb52ca639b683ef158f8b4f2f347d08ad/addons/purchase/static/src/product_catalog/kanban_record.js#L33-L34 the flooring might sometimes get a close approximation and end up flooring down the packaging quantity. In our example, `this.productCatalogData.quantity` should be `68.04` but is actually `68.03999999999999`. This leads to `this.productCatalogData.quantity / packaging.qty` == `2.9999999999999996` `Math.floor` then rounds it down to 2 so we end up with 2 + 1 = 3, which is the current packaging quantity so nothing changes. ----- Ticket: opw-5130865
This fix ensures that a call is removed from the VOIP softphone as soon as it is unlinked. It prevents users from seeing outdated calls that have already been deleted, keeping the interface accurate and less confusing.
Original PR description
A call that was unlinked previously remained visible in the VOIP softphone. This fix ensures that the call is correctly removed from the softphone view as soon as it is unlinked. Task-5262162
This change fixes an incorrect Dutch translation for the 9% sales tax description. It helps ensure tax labels are shown clearly and accurately to users in the Dutch localization.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323
This update fixes an issue where sending an email from the Contacts list could fail when a message template was used. Emails now correctly find their recipients in this flow, so they are sent successfully instead of being cancelled.
Original PR description
Steps to reproduce: ------------------------- 1. Install the `Contacts` module and configure an outgoing mail server 2. Create a mail template with Auto Delete False and Applies to Contacts 3. Create…
Steps to reproduce: ------------------------- 1. Install the `Contacts` module and configure an outgoing mail server 2. Create a mail template with Auto Delete False and Applies to Contacts 3. Create a new contact with an email address 4. From the chatter, click Send Message, select the created mail template, and send it. 5. Go back to the Contacts list view and search for the newly created contact 6. Select the contact and from the Action menu, click Send Email 7. Again, select the same mail template and add a test email in the Reply-To Address field from the Settings page 8. Click Send Observation: ------------------------- 1. The email sent from the chatter appears in Sent state. 2. The email sent from the wizard appears in Cancelled state. Issue: ------------------------- In the following code https://github.com/odoo/odoo/blob/a85f268eab4647261b18b1106223c8e18dded085/addons/mail/wizard/mail_compose_message.py#L1037-L1044 there is no fallback for recipients when both `template_id` and `email_mode` are set. As a result, when `partner_ids` are missing in `mail_values_all`, the email fails to send. Solution: ------------------------- Added a condition to handle the case where both `template_id` and `email_mode` are present. If `partner_ids` are not defined in `mail_values_all`, the system now fetches `default_recipients` and adds them to `mail_values_all`. opw-5143950
This fix ensures that when a report filter is enabled on a combined report, it is also enabled on the report’s sections when needed. As a result, the filter will correctly appear in the user interface instead of being missing in some report views.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters.