Daily updates from Odoo
Friday, November 21, 2025
109 changes
12 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 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
This fix ensures that additional fields added to pay run forms by localizations are kept when the record is saved. It prevents user-entered values from being lost, which helps maintain accurate payroll data.
Original PR description
In some localizations, extra fields are added in the form view of payruns, these field values are lost due to the way we buildRawRecord
This fix removes an incorrect block when creating a reordering rule for a product in a different company. Previously, kit bills of materials from another company could prevent setup even though they should not apply there.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
When users press Alt+A from the public website, the editor now opens in a usable translation state whenever the page supports translations. This fixes a confusing case where the editor opened but could not actually translate the page, improving the experience for multilingual websites.
Original PR description
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A…
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A (the shortcut to open the builder) => The builder opens, but it is unusable. The builder options are the translation options, but the iframe is not in a translatable state. __Cause:__ Pressing Alt+A outside the admin backend just [adds `enable_editor=1` in the URL][1]. When the page is displayed in the 2nd language `data-translatable` is included in the metadata so the translation mode opens. However the iframe relies on the `edit_translations` search param being set to include the translation branding (i.e. `data-oe-translation-source-sha`) which is not the case after pressing Alt+A. __The fix:__ Add `edit_translations` when pressing Alt+A in any case. If the page is translatable, the translation mode will correclty open, otherwise it will be ignored and the edit mode will open instead. NB: By doing this, we bypass the checks in [`attemptStartTranslate`][2] therefore a user who doesn't have the proper access rights will still be able to open the translation mode but they will not be able to do anything. Using those checks would add too much complexity to the code in regards to how niche the feature is anyway. [1]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/js/content/redirect.js#L33 [2]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/client_actions/website_preview/edit_website_systray_item.js#L54 task-5125700
Refunds in Point of Sale now handle serial-numbered products more accurately. When only part of a quantity is refunded, staff can choose which serial numbers to return, and the system preselects the right number by default to make refunds faster and less error-prone.
Original PR description
When refunding an order that contains a product tracked by serial number if you refund less than the total quantity of the product in the order all the serial numbers of the original order would be set anyway. Also you were not able to select the serial numbers to refund. Steps to reproduce: ------------------- * Create product P1, storable, tracked by serial number * Create 2 Serial Numbers SN1, SN2 for P1 * Create a POS order with 2x P1 (SN1, SN2) * Pay and validate the order * Refund the order, set quantity of P1 to 1 * Validate the refund > Observation: The refund order contains P1 with SN1 and SN2, and you cannot edit the serial numbers. Why the fix: ------------ We now allow to select the serial numbers when doing a refund and only show the serial numbers that were in the original order. We also select by default the same number of serial numbers as the quantity to refund. opw-4965171 Forward-Port-Of: odoo/odoo#235514 Forward-Port-Of: odoo/odoo#230778
10 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 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 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
Anchor links with the “Open in New Window” option enabled now correctly open in a new tab instead of staying in the same page. This fixes the browsing behavior users expect and makes website links work consistently across desktop and mobile views.
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#236783 Forward-Port-Of: odoo/odoo#228787
5 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
This update corrects how planning hours are counted in Timesheets/Planning analysis reports. Shifts that end outside normal working hours, especially when they cross into a new month, will no longer be incorrectly included in the next month’s planned hours.
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
19 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
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
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#99940This 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
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
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
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
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
This 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-511014324 changes
Resolved issues and error corrections
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
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 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
This change lets portal users comment on opportunities they can already view. It fixes a case where they could read the record but were blocked from sending a message, improving collaboration and follow-up.
Original PR description
When we want to post a message, we check that the user has access to the thread, i.e. we check access for the `crm.lead` record with the `write` operation. It is therefore necessary for the group portal to be able to post message on the `crm.lead` record (opportunity) he can read by adding `_mail_post_access` with the `read` operation.
This fix ensures the cost of goods sold for kits is calculated using the product’s own base unit of measure, even when the sales order uses a different unit. This prevents inaccurate cost values in accounting when selling the same kit in another unit.
Original PR description
Steps to reproduce: - Make a kit in uom A - Sell that kit in uom B Issue: The cogs price_unit will be computed in the SO line's uom rather than based on the kit's default uom. Harmonize the code so it's clear that `_get_cogs_value()` is always expected to give the unit price in the product's base uom, not in the uom of the account move line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing order catalogs will now only show consumable products for components and by-products. This prevents users from adding service-type items that cannot be stocked, consumed, or produced, and removes an unnecessary Services filter from the catalog.
Original PR description
Issue: ====== User can add `service type` products in the MO catalog which is not valid. When we manufacture the products, allowing service products in the MO catalog is not valid. These products are…
Issue:
======
User can add `service type` products in the MO catalog which is not valid.
When we manufacture the products, allowing service products in the
MO catalog is not valid. These products are not stockable or traceable,
and therefore cannot be consumed as raw materials or produced as by-products.
How to reproduce:
=================
1. Install mrp.
2. Create MO.
3. Open catalog for `Components` or `By-Products`.
4. User can add `Service` type products from here.
Cause of the issue:
===================
- Domain for product catalog doesn't contain `('type', '=', 'consu')`.
Solution:
=========
- Added `('type', '=', 'consu')` in product catalog domain.
With this commit, users can now select only consumable products from the
`Add a line` or `Catalog` in the MO `Components` and `By-Products` sections.
Also removed the `Services filter` from the MO catalog, since there are
no service-type products in the catalog, so it doesn’t make sense to
keep this filter.
TaskId : 4904067This fix keeps the preparation display updated when staff transfer, merge, link, or unlink table orders. It also prevents duplicate preparation records from being created when orders are adjusted, helping kitchen screens match the POS more reliably.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/enterprise#98374
This update ensures that restaurant table actions like transferring, merging, linking, or unlinking orders properly update the kitchen preparation screens. It also prevents duplicate preparation records from being created when orders are adjusted, helping keep POS and kitchen information consistent.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/odoo#233630
This update fixes an issue where vendor credit notes could be rejected by MyInvois when the original bill had a custom reference. The system now uses the reference stored with the submitted e-invoice, which helps ensure the reversal document matches what the tax system expects.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference…
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050 Forward-Port-Of: odoo/odoo#235026 Forward-Port-Of: odoo/odoo#234199
When a vendor bill email contains multiple image attachments, Odoo now checks whether each attachment group is actually useful before creating additional bills. This avoids creating unnecessary records and helps reduce wasted processing costs and database clutter.
Original PR description
Steps to reproduce: - Set up email alias for Vendor Bill journal - Send email with N images alias Issue: <N> Bills are created, in each one we will attempt to extract the image content to enrich the bill. Analysis: This occurs because we split the attachment list into several groups, each one creating a new invoice (except the first). However we don't take into account if the attachments are actually meaningful. In many cases this behavior will pollute the database and waste iap credits. This commit proposed to evaluate if in each group there is at least a meaningful attachment before creating/extending an invoice opw-5076315 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/5076315) Forward-Port-Of: odoo/odoo#234913
This fix prevents a kit bill of materials in one company from incorrectly blocking reordering rule creation in another company. It ensures Odoo only checks kit bills of materials that belong to the same company, or are shared across companies, which avoids unnecessary validation errors.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
The replenishment info wizard now counts more in-progress stock moves when estimating daily demand. This makes the demand calculation closer to other purchasing views and helps produce more accurate replenishment suggestions.
Original PR description
In the replenishment info wizard, the daily demand based on previous periods of time only takes 'done' moves into account. This is different from the purchase catalog which also takes 'assigned', 'confirmed' and 'partially_available' moves. This PR adds those 3 states in the domain when searching for moves. task 5219526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes record access checks use the same rules everywhere, regardless of a specific context setting. It prevents inconsistent access behavior and helps ensure users see and can act on records as expected.
Original PR description
Since https://github.com/odoo/odoo/pull/219703, we ir.rule domain doesn't depend on active_test context key. But `_check_access` is still depending on active_test which is not consistent. Fix it.
21 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 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
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
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
The Italian “Libro Giornale” report was affecting all journal reports in some cases, which could remove journal names from exported PDFs. This update limits the custom formatting to the correct Italian report only, so other companies’ journal reports display properly again.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520
This change restores the expected payment setup for standard ISO 20022 bank transfers. Payments now automatically use the NURG service level as before, which helps ensure the correct processing of non-SEPA transactions.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e
This change makes Odoo more reliable when linking incoming supplier bills to their related purchase orders. It now ignores tiny price differences that are within the normal product price rounding, so valid matches are no longer missed because of insignificant decimal variations.
Original PR description
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is…
Fixes Task 5213234 Issue: In AccountMove method _find_matching_po_and_inv_lines (called when looking for a subset match of EDI invoice lines with PO lines), the price_unit of a purchase.order.line is compared to the price_unit of an invoice line. However, currently the comparisons do not take into account the precision to be applied to product prices. In some cases, the invoice line price_unit differs from the price_unit in a PO line, but by less than the "Product Price" precision. With the current comparisons this leads to not matching the lines. This has prevented matching some invoices received via Peppol for at least one big customer (see Task-5213234) Steps to reproduce: - Create an XML document for an EDI UBL invoice with 2 lines; the first line has a price_unit 113.57 euros (for example) - Create a PO with a reference matching the invoice, and one PO line with a price_unit matching the price_unit of the first invoice line (113.57 euros) - Upload the XML invoice and create a bill from it; during the creation of the account.move.line, the price_unit gets a value which is slightly different from 113.57 (113.57000000000001) (due to python rounding ?) - Result: no link is established between the PO and the invoice. This fix makes sure that the "Product Price" precision is used when comparing the invoice line price_unit with a PO line price_unit. opw-5213234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232527
This update prevents the interface from displaying the word “undefined” when a hidden section is skipped during page rendering. In full-size forms, it ensures empty spaces stay clean instead of showing stray text where buttons or controls would normally appear.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823 Forward-Port-Of: odoo/odoo#236461
This update corrects the French Balance Sheet so it stays balanced when using the 2024 chart of accounts. It restores missing income and expense amounts in the retained earnings calculation, which helps ensure accurate financial reports for companies using the French localization.
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, 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
This update corrects missing settings on several Philippine tax tags so they are treated properly in tax calculations. As a result, tax reports will no longer show incorrect figures for affected cases.
Original PR description
This commit sets tax_negate to true to (-QAPA, -QAPB, -SAWTA, -SAWTB). They were missing and impacted a tax report falsely. opw-5157090
Users can now create reordering rules for a product in one company even if that product has a kit bill of materials defined in another company. This fixes an incorrect validation error and prevents kit settings from one company from blocking operations in another.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Add a kit BoM restricted to Company A - Switch to Company B - Try to create an orderpoint for "P1" in Company B Issue: A validation error is raised: "A product with a kit-type bill of materials cannot have a reordering rule." Cause: The check did not consider the company of the BoM, so kit BoMs defined in other companies incorrectly blocked orderpoint creation. Solution: Add the company condition in the BoM search domain to ensure that only BoMs belonging to the same company (or global ones) are considered. opw-5158491 Forward-Port-Of: odoo/odoo#232685
This update stops users from changing the product on combo item lines by mistake or misuse. Description edits are still possible, but users now need to hide the product-related columns first, which helps keep combo orders accurate.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes).
This fix allows users with invoicing-only permissions to create and open invoices even when a TDS/TCS warning is set on the chart of accounts. It removes an access error that was blocking normal invoicing work for those users.
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 update prevents import failures when users upload CSV files encoded in UTF-16. Instead of crashing with a low-level decoding error, Odoo now shows a clearer warning, making it easier to understand and resolve the problem.
Original PR description
Currently, an error occurs when importing CSV files encoded in utf-16. **Steps to reproduce:** - Install the `account_bank_statement_import_csv` module. - Open invoicing and upload file [1] in Bank transactions. - Change the encoding to `utf-16` and click `test`. **Error:** `UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x0a in position 376: truncated data` **Root Cause:** At [2], the CSV data is decoded strictly with the specified encoding. When decoding detects incomplete or unexpected byte sequences, Python raises an `error`. **Fix:** This commit ensures raising a `warning`, improving the `error message clarity`. [1]: https://drive.google.com/file/d/14thHRN210aeY8fcUBAb01PniVrd7QHer/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/67503c0ce7ede8373800caa0a12203d271b7f1ae/addons/base_import/models/base_import.py#L544 sentry-6864546266
For Canadian companies that close their fiscal year on a date other than December 31, the tax report now lets them choose a different start date. This helps ensure annual filings are calculated on the correct period and avoids issues with closing dates.
Original PR description
If a user from CA has a fiscal year on something other than the 31/12 and needs to return annually, he can't do his closing on the right bounds. We now allow CA to show the field to be able to shift it, as government allow it. Later, we will change the heuristic to be smarter to show it as soon as it may cause issue. opw-5193999
This fix restores the missing date scope settings on some Balance Sheet lines used in cross-report links. As a result, the report will show figures for the intended period more consistently, reducing the risk of confusing or incomplete financial comparisons.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
The German DATEV export now correctly reflects bills where the tax amount was manually adjusted. This prevents mismatches between what users see in accounting reports and what gets exported for tax and audit purposes.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#98684
9 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 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
When an invoice is duplicated, it will no longer carry over the original source document from the previous invoice. This avoids misleading information on copied invoices and prevents errors in external invoice exports that rely on that field.
Original PR description
Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495