Daily updates from Odoo
Wednesday, October 8, 2025
43 changes · saas-18.4
Resolved issues and error corrections
UPS shipping rates can now be checked during express checkout using only the limited delivery details collected at that step. This prevents shoppers from being blocked by unnecessary street and phone requirements, making checkout smoother for ecommerce customers.
Original PR description
Express checkout in ecommerce does an initial rate check with shipping connectors that does not require all of the fields normally required by that shipping connector. For UPS, this meant express checkout was failing due to an unnecessary `street` and `phone` field check since the only required delivery fields for express checkout are: (city, zip, country_code, state_code) For more info, see: https://github.com/odoo/odoo/blob/b403d5d74dd545f926a38a6aa6d18118d34e83b7/addons/website_sale/controllers/delivery.py#L181-L188 opw-[4447700](https://www.odoo.com/web#id=4447700&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#78788
Saving website settings with an invalid domain no longer causes an unexpected error. Users now receive a clear validation message, helping administrators correct the domain without disrupting configuration work.
Original PR description
Currently, an error occurs when user tries to save an invalid domain. Steps to replicate: - Install `website_sale`. - Go to `Settings > Website`. - In the domain field, give value as `[`. (any normal URL with a square bracket will also work). - Save and error will occur. Error: `ValueError: Invalid IPv6 URL` Cause: - The error happens because `config.get_base_url()` returns a malformed URL (like containing stray `[`), which makes urljoin [1] raise the error. Solution: - The solution prevents error by adding a constraint and raising a user-friendly `ValidationError` if the URL is invalid. [1]: https://github.com/odoo/odoo/blob/77398aefc291d33264b039e38681f0cd8f65483f/addons/website_sale/models/res_config_settings.py#L135 sentry-6805151048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223336
This fix corrects how service discounts are handled when calculating Brazilian taxes through Avalara. It prevents discounts from being subtracted twice, helping ensure more accurate tax amounts on affected service invoices.
Original PR description
Confusingly, Avalara's service API already accounts for the discount in lineNetFigure, whereas their goods API does not. In <saas-18.4 this was handled by _l10n_br_get_line_total(), but it got lost in the big refactor in saas-18.4 [1]. [1] https://github.com/odoo/enterprise/pull/82623 opw-5147143
This fixes an unreliable CRM automated tour by selecting the intended customer record and waiting until the opportunity name is properly filled in. It reduces false test failures and helps ensure CRM workflows remain stable during validation.
Original PR description
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults…
The problem here is twofolds: - After odoo/odoo#206314 the field being searched is filtered on `is_company` which means it's literally impossible to find the partner we create as that field defaults to `False`. - Before that PR, since we just `click` the first link we find in the dropdown, we might get a random company which exists in the database (if any) or we might hit the "create" option. In the latter case we have a non-zero chance of clicking `o_kanban_add` before the client has had the time to `name_create` the record, set the partner, call the onchange, and return with the opportunity's name, leading to an attempt to create a nameless opportunity and a "missing required field" error Selecting the very specific partner we created (correctly this time) and then actually waiting for the opportunity's name to be set should resolve the issue, and make problems in that step show up in the right location in the future rather than hit some sub-sub-sub-symptom 20 steps later. https://runbot.odoo.com/odoo/error/229719 Forward-Port-Of: odoo/odoo#230251
New user invitation emails now generate website and email links correctly. This prevents recipients from receiving malformed links, making account setup smoother and reducing support friction.
Original PR description
Website and email links were malformed on the New User Invite email template. Later versions also have this issue on the other templates will change those in forward ports. Renderer was treating the string formatting as a string itself when using the double curly braces on variables. Removed the curly braces so the variable was properly evaluated and inserted into the string. opw-4977756 Forward-Port-Of: odoo/odoo#221487
Users with limited access rights now see the correct page title when previewing copied links. This prevents misleading generic previews and makes shared links clearer for everyday users.
Original PR description
Users without access for specific actions cannot see the right preview information, using sudo like the search for generic action but on specific model solve the issue. Steps: - Login with a user without window actions access - Copy a link somewhere to have preview dialog Actual result: - Preview title is Odoo due to access error Expected result: - Preview title is the one of the page opw-4933194 Forward-Port-Of: odoo/odoo#222435
The barcode scanning dialog no longer crashes if a user goes back or presses Esc before the camera preview is ready. This prevents an error screen and keeps the scanning workflow stable when users close the dialog quickly.
Original PR description
Steps to reproduce: 1. Install `barcode` 2. Barcode > 'click to scan' 3. Before the camera preview loads, click the back button of the dialog Issue: A traceback occurs: `OwlError: The following error occurred in onMounted: 'Cannot set properties of null (setting 'srcObject')' ` Cause: Clicking the back button triggers `onWillUnmount`, which clears the stream and sets `this.videoPreviewRef.el` to null. However, some asynchronous functions in `onMounted` are still pending and try to access the video element, leading to a crash. Solution: Add a safe check based on component status before accessing `this.videoPreviewRef.el` opw-5055566 Forward-Port-Of: odoo/odoo#229937 Forward-Port-Of: odoo/odoo#226068
Saudi Arabia localization taxes are now correctly linked to fiscal positions. This prevents invoice taxes from being unintentionally removed when a tax localization is applied, helping ensure accurate tax calculation and invoicing.
Original PR description
Starting 18.4, if the tax position linked to an invoice is not set to any tax => it removes the taxes from the invoice (RD task 5017278). For l10n_sa, no tax is linked to a tax position so if a tax localization is set then product taxes will be removed. This commit set fiscal positions to l10n_sa taxes to avoid this. opw-5011877 
The Indian withholding process now checks whether any records were selected before continuing. If nothing is selected, users receive a clear error instead of encountering an unexpected failure, improving reliability in this workflow.
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190579 Forward-Port-Of: odoo/odoo#190324
ISO 20022 payment files for Danish banks can now include the required local clearing instruction, preventing bank rejections when this information is needed. Businesses can configure whether payments use overnight or same-day clearing; if left unset, files remain unchanged.
Original PR description
The denmark banks were refusing ISO20022 documents because there was a missing field: "//PmtInf/PmtTpInf/LclInstrm/Cd" or "//PmtInf/CdtTrfTxInf/PmtTpInf/LclInstrm/Cd". One of those field should be filled by either 'ONCL' or 'SDCL' which means 'Over Night Clearing' or 'Same Day Clearing'. To fix this we added a config parameter with a key: account_iso20022.local_instrument_code where we can set OCNL or SDCL to add the required field to the iso document. If nothing is set, the field will not be added. opw-5073076 Forward-Port-Of: odoo/enterprise#96190 Forward-Port-Of: odoo/enterprise#95903
This update fixes a web interaction issue that could cause crashes when certain wait actions returned no value. It makes the behavior more reliable for developers and helps avoid interruptions in website or app interactions.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229029
Dashboard treemap charts no longer replay animations unnecessarily when their data is refreshed. This avoids distracting visual changes and makes spreadsheet dashboards feel steadier during normal use.
Original PR description
Charts animations are played every time the chart data changes in dashboards. But the treemap data contains callbacks, which mess up the deepEqual we use to check if the data changed, since new callbacks are created each time. This adds an argument to deepEqual to ignore functions. Task: [5003595](https://www.odoo.com/odoo/2328/tasks/5003595) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225996
This fix ensures an internationalization-related test no longer changes shared test settings in a way that stops later tests from running. It helps keep continuous integration reliable so issues are caught before reaching customers.
Original PR description
The `config.parse_config` call changes the test flags, effectively disabling all following tests and breaking the CI. See: odoo/odoo#229755
This fixes an accounting issue where credit notes created after a sales down payment did not reverse the related cost of goods sold. Businesses now get accurate stock and expense accounting when refunding invoices that included down payments.
Original PR description
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on…
**Problem:** When we do a downpayment on an invoice then pay the rest and do a credit note, the credit note does not reverse the cogs **Steps to reproduce:** - create a storable product invoiced on ordered quantity - set the category of the product as avco and "inventory valuation" of the category as automated - set an onhand quantity and a positive cost - create a SO for 1 quantity of this product and confirm - click on create invoice, select downpayment percentage and 25% - click on create draft and confirm it - click on create invoice, select regular, create draft - confirm and select credit note - write something in the reason field and click on reserve - confirm it **Current behavior:** if you open the "Journal Items" page of the credit note you'll see that there is no line revresing the cogs (there would be if we didn't do a downpayment but invoiced all at once) **Expected behavior:** There should be: - A line crediting "600000 Expenses" (or the account that was debited for the cogs on the original invoice) with the amount being the cost of your product. - A line debiting "110300 stock interim (delivered)"(or the account that was credited for the cogs on the original invoice) with the amount being the cost of your product. **Cause of the issue:** Since this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 (slightly modfified for efficieny reasons by this commit https://github.com/odoo/odoo/commit/4f9c52c03c65a497937053530e8d6c775d305e35), when _stock_account_prepare_anglo_saxon_out_lines_vals is called on the account move (the credit note) it calls _get_anglo_saxon_price_ctx. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L114 One of the invoice lines of the account move is linked via sale_line_ids attribute to a sale order line that is a downpayment. As a consequence, inside _get_anglo_saxon_price_ctx, move_is_downpayment will be populated with this line. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L136-L139 Then _stock_account_prepare_anglo_saxon_out_lines_vals calls _stock_account_get_anglo_saxon_price_unit. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/account_move.py#L131 Inside this method, because move_is_downpayment is populated, is_line_reversing will stay false https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L163-L164 As a consequence, - qty_to_invoice will become - qty_to_invoice - account_move will be populated - therefore posted_cogs will be populated https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_stock/models/account_move.py#L166-L174 So _compute average price will be called with a qty_invoiced of 1 instead of 0 and a qty_to_invoice of -1 instead of 1. So it will return 0 instead of the cost of the product because "missing" will be negative. https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/stock_account/models/product.py#L915 **fix** The use case of this commit https://github.com/odoo/odoo/pull/163251/commits/d7b0510908d341c205461ca18b1730c93b88e445 is this one : - SO for qty of 10 (product invoiced on delivered qty). - 100% downpayment. - deliver 6. - invoice. In that case the invoice is actually a credit note but it still has to include the cogs (not reversed), so move_is_downpayment needs to be populated However in our use case the cogs has to be reversed (so move_is_downpayment has to be None). One difference between those two use case is that in our use case the account move has a reversed_entry_id. opw-5041783 Forward-Port-Of: odoo/odoo#229774 Forward-Port-Of: odoo/odoo#226809
Shared employee profile links that include restricted information now show a clear access message instead of crashing. Users without permission are redirected to the public employee list, and a new test helps prevent similar issues from returning.
Original PR description
Sharing a link of an employee profile containing private info generated a traceback. Permissions had to be applied to the private field. I've also put a more explicit error message that allows the user to get redirected to the public employee list. I couldn't find a way to get the employee id from the url before the generic permission warning comes in. Thus I had to resort to redirecting to the general public employees list. Other tracebacks may happen each time a private field without the corresponding groups is put in the xml. Thus I added a test to prevent us from doing that again. Forward-Port-Of: odoo/odoo#229611 Forward-Port-Of: odoo/odoo#228623
This fix ensures FIFO product costs are recalculated from the actual inventory valuation rather than a manually set cost that may no longer match stock value. Businesses get more accurate product costs after revaluation, reducing accounting and inventory valuation discrepancies.
Original PR description
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on…
**Steps to reproduce:** - create a storable product with fifo category - update the cost to 200 - click on the on hand smart button and add a quant of 1 quantity - update the cost to 300 - click on the on hand smart button and update the quantity to 2 - the value should be 500, which makes a 250 value per product - open Inventory/valuation and search your product - group by product, select your product and click on "+" icon to open the revaluation widget - add 200 (so +100 per unit) - go back to the product form **Current behavior:** the cost is now at 400 **Expected behavior:** the cost should be at 350 (250 + 100) If we change the standard_price we should change it in accordance with the valuation **Cause of the issue:** In action_validate_revaluation, during the update of the standard_price, the current standard_price (set by the user and disconnected from the valuation) is used in the computation. https://github.com/odoo/odoo/blob/5118f7cb80744f901d7028dc75c29aba9591b83b/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L127 opw-5028848 Forward-Port-Of: odoo/odoo#229977 Forward-Port-Of: odoo/odoo#228457
This fix ensures country-specific point-of-sale session information for Chile and Peru is kept when sessions sync across multiple devices. Businesses using multi-device PoS setups avoid losing required localization data after real-time updates.
Original PR description
Before this commit, the special fields were added to the PoS session in the `_load_pos_data` function. However, they were not included when sending synchronization notifications to other devices. As a result, in multi-device setups, these fields would be removed after a WebSocket notification. related: https://github.com/odoo/odoo/pull/228419 opw-5073848 Forward-Port-Of: odoo/enterprise#95455
This fixes Nuvei payment handling when customers return from the payment page without completing payment, avoiding validation errors caused by missing notification data. It also ensures Webpay payments are checked using the right whole-number amount format, helping valid payments complete successfully.
Original PR description
Since https://github.com/odoo/odoo/pull/163860, all notifications from providers are checked to see that they have the correct currency and amount in their flow before processing the notification. However, this has two issues with Nuvei: 1. The process when a customer hits "Go back" on the payment page instead of paying does not send any notification data. As such trying to compare these values will not work. 2. Certain payment methods within Nuvei use different decimal precision than the currencies on odoo. Webpay must always be in whole values even for USD, as such, we need to pass the correct number of precision digits to the validation method otherwise Webpay will never be able to go through. opw-5108631
Duplicated CRM leads without an assigned salesperson now stay eligible for rule-based assignment. This prevents missed sales ownership when teams duplicate leads and later update them to match assignment criteria.
Original PR description
Currently, leads are not automatically assigned via rule-based assignment when duplicating an existing lead, even if the duplicated lead matches the assignment criteria. **Pre-requisites:** 1) Set up…
Currently, leads are not automatically assigned via rule-based assignment
when duplicating an existing lead, even if the duplicated lead matches
the assignment criteria.
**Pre-requisites:**
1) Set up rule-based lead assignment in the CRM settings.
2) Configure the sales team's assignment domain:
`[("user_id", "=", False)]`
3) Configure the sales team members' domain:
`[("probability", ">=", 10)]`
**Steps to Reproduce:**
1) Create a lead that matches the above assignment rules.
2) Remove the salesperson (user_id) and sales team from the lead.
3) Duplicate the lead.
4) Update the probability to a valid value (e.g., ≥ 10).
5) Manually trigger the `Rule-Based Assignment`.
**Issue:**
The original lead gets assigned, but the duplicated one does not.
**Cause:**
When duplicating, the system sets date_open to the current date by default,
even if the duplicated and original leads have no assigned users.
https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_lead.py#L929-L931
However, `rule-based assignment` only considers leads where `date_open` is False https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_team_member.py#L136-L141
**Solution:**
Set `date_open` to False during duplication if the original lead has no `user_id`.
This ensures the new lead remains eligible for assignment.
opw-5003529
Forward-Port-Of: odoo/odoo#229512
Forward-Port-Of: odoo/odoo#227387This fixes image editing so that rotating, resizing, or moving an image can be undone back to its original state with a single Ctrl+Z. It makes content editing more predictable and reduces frustration from needing several undo actions.
Original PR description
**Current behavior before PR:** - When rotating, resizing, or dragging an image using the transform container, pressing Ctrl+Z did not revert the image to its initial state (when the transform container was opened). - Instead, it required multiple undo operations to return to the initial state. **Desired behavior after PR is merged:** - Pressing Ctrl+Z now correctly reverts the image to its initial state in a single undo, after a transformation. task-5114320 Forward-Port-Of: odoo/odoo#228720
This fix ensures Spanish point-of-sale compliance fields remain available when sessions sync between multiple devices. It prevents important fiscal data from disappearing after real-time updates, improving reliability for businesses using these localization features.
Original PR description
Before this commit, the special fields were added to the PoS session in the `_load_pos_data` function. However, they were not included when sending synchronization notifications to other devices. As a result, in multi-device setups, these fields would be removed after a WebSocket notification. related: https://github.com/odoo/enterprise/pull/95455 opw-5073848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228419
Public mail-related pages now correctly translate their visible text for users. This fixes an issue where translated content could appear in the original source language, improving the experience for multilingual visitors.
Original PR description
Human-readable content defined in public page components isn't translated. This is because we forgot to give Owl a translation function, so it falls back to returning the source terms as they are (identity function). This commit resolves the issue by providing the missing translation function. Task-4493082 Task-5140665 Forward-Port-Of: odoo/odoo#230266 Forward-Port-Of: odoo/odoo#230129
This fix ensures Point of Sale test companies include a country when needed by installed localizations. It prevents avoidable test failures and helps keep the release validation process stable.
Original PR description
Before this commit, some tests would fail when localizations requiring a country were installed, because the created company did not have a country set. runbot-233158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230114
Opening the Quality Points button from a product could crash when Point of Sale was installed because the wrong list view was selected. The fix ensures the correct Quality Control view is used, so users can access quality points from product records reliably.
Original PR description
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue**…
**Step to Reproduce** 1- Install point_of_sale and quality_control. 2- Open POS -> Product -> Product 3- Open any product and click the Quality Points smart button → traceback occurs **Issue** `UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: ""quality.point"."product_variant_count" field is undefined."` **Root Cause** https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/point_of_sale/views/product_view.xml#L23-L25 - View reference is passed in the context. - When this context is propagated to `action_see_quality_control_point`, https://github.com/odoo/enterprise/blob/7b777bffbebfb6503bb348005e9ce076825926e4/quality_control/models/quality.py#L579-L584 https://github.com/odoo/enterprise/blob/2e08282ca275bf1e66c58e28391f11f8bd7884d2/quality_control/views/quality_views.xml#L859-L868 - Than traceback occurs because the action does not pass a `view_id`. - When the context contains `list_view_ref`, it attempts to load the product template list view with the `quality.point` model. - This leads to a traceback since the fields defined in that view do not exist on the `quality.point` model. **Solution** - Pass a proper `view_id` from the Python side to ensure the correct view is loaded, preventing `list_view_ref` from forcing to load an invalid template. **opw-** **5090505** Forward-Port-Of: odoo/enterprise#95040
This update removes a non-essential test check that could fail unpredictably when product loading conditions changed. It helps keep automated validation stable without changing how users work with the point-of-sale loyalty features.
Original PR description
Before this commit, some tests could fail randomly if a new product was included in the list of limited loading products. The part of the test that checked whether the product was not loaded was not essential, so it has been removed to prevent unnecessary failures. opw-5109838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228364
The Point of Sale test process now waits longer for the system to load when many regional settings are installed. This reduces false test failures and helps keep release checks stable without changing the customer-facing PoS experience.
Original PR description
Loading the PoS with all the localizations installed can take up to 15s to load, so we increase the timeout of the first step of the generic tour to 20s to make sure it doesn't fail. runbot-233059 Forward-Port-Of: odoo/odoo#229925
This fixes an issue where separators in the Email Marketing showcase template could disappear in received emails. The change keeps separators visible on desktop layouts and improves how their border colors are rendered, making sent marketing emails match the intended design more reliably.
Original PR description
Problem: When adding the `s_showcase` template in email marketing and saving, the separator is not properly rendered in the received email. Cause: The separator is implemented as an empty `<div>` with `display: inline-block` and `height: 100%`. In emails, this can collapse to 0px, making the separator invisible. Additionally, `border-<position>-color` was not applied correctly in some cases. Solution: - Lock the computed height of empty separator elements so they remain visible. - Restrict visibility of separators to desktop screen sizes where columns are stacked horizontally. - Fix rendering of `border-<position>-color`. Steps to reproduce: 1. Open a new email marketing. 2. Add the `s_showcase` template. 3. Test-send the email. 4. Observe that the separator is not visible. opw-5077992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226350
The employee form now shows the full count of documents stored in an employee's folder and any subfolders, excluding folders themselves. This gives HR users a more accurate view of how many employee documents are available without needing to browse each folder manually.
Original PR description
Before this commit, the documents count on the employee form view showed only the count of documents (folders included) inside the employee folder but not the ones in subfolders. This commit fix that by showing the count of every documents (folders excluded) included in the employee folder or its subfolders. Task-4944895 Forward-Port-Of: odoo/enterprise#91009
This fixes Razorpay payment failures that could occur when a provider had both Key ID/Secret credentials and OAuth connected. Odoo now avoids sending conflicting authentication methods, preventing 403 errors during mobile website payments.
Original PR description
In a specific context, Razorpay rejects connections using both Key ID/Secret and an access token simultaneously. To reproduce, it's require a real production Razorpay account since Oauth is not available in test mode. Step to reproduce: - Configure Key ID/Secret and connect via OAuth on the Razorpay payment provider. - On iOS/Android, making a payment on the website triggers a "403 Forbidden" error because Razorpay redirect to /payment/razorpay/return and the signature from Razorpay not correspond to the expected signature computed with the Key Secret. This fix prioritizes call with Key ID/Secret over token authentication. opw-5100194 opw-4989944 opw-5039880 opw-5099580 Forward-Port-Of: odoo/odoo#229468
This fixes payroll accounting tests after an underlying employee contract model change. It helps keep automated checks reliable without changing day-to-day payroll functionality for users.
Original PR description
Explanation: hr.contract is reworked into hr.version runbot-229897
Creating a new website page while using mobile view no longer causes an error. This helps users continue building and editing website content smoothly from the mobile preview experience.
Original PR description
Steps to reproduce: 1.open website. 2.switch to mobile view. 3.click new button and select new page option 4.a traceback occurs. Before this commit: Creating a new page in mobile view raised a traceback because contentDocument was undefined due to an incorrect selector. After this commit: The issue is resolved by using the correct querySelector value, ensuring that contentDocument can be accessed properly.
This fixes an issue that could cause a server error when reporting problems from the Nilvera integration for Turkish localization. Users should now receive the intended error message instead of an unexpected failure.
Original PR description
The http response object doesn't have a `code` attribute, this commit fixes this typo which has already been fixed in 19.0 as a part of #222869 task-5050516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228088
This update adds a protective check to avoid rare calculation errors when electronic invoice values round down to zero. It helps keep invoice export processing stable and prevents a potential division-by-zero failure in edge cases.
Original PR description
[FIX] account_edi_ubl_cii: float comparison safeguard. This fix solves a potential issue where the `delivered_qty * price_unit` is too close to zero making it pass the float comparison check, later we divide against the same product, but this time wrapped in `curency.round` which may round it to zero, resulting in a division by zero error. Whilst I found no functional way to reproduce the issue as the value of price_unit should already be zero when we get here but, the fix is to simply safeguard from potential future changes. Ticket [link](https://www.odoo.com/odoo/project.task/5013588) opw-5013588 Forward-Port-Of: odoo/odoo#230236
Event invitation descriptions now format links more safely so Gmail does not break them. This helps recipients open the correct event URL directly from their email, reducing confusion for attendees.
Original PR description
When website_event is installed an anchor tag is added inside the event description which is guaranteed to break the url in the gmail client. We now quote the description appropriately so that there's no confusion. task-5092759 Forward-Port-Of: odoo/odoo#229979 Forward-Port-Of: odoo/odoo#228359
The update ensures page components finish loading before edit-mode change tracking resumes. This prevents pages such as the login screen from being incorrectly marked as modified, reducing confusion for website editors.
Original PR description
*web, website Before this commit, `PublicComponentInteraction` was not awaiting the mounting of Owl components. Consequently, the DOM mutations generated by the components were not always ignored. After this commit, the mounting is awaited before restarting the mutation listener. ** HOW TO REPRODUCE THE PROBLEM ** One case were the problem is evident is the `/web/login` page. 1. Navigate to `/web/login` 2. Enter edit mode 3. Inspect the page searching for `o_dirty` 4. The page is already dirty. This happened because of `UserSwitch` not being awaited.
The stock quantities list now highlights only products that actually have an overdue removal date. This prevents regular products from being incorrectly shown in red for stock users, making the list easier to read and reducing confusion.
Original PR description
Description of the issue/feature this PR addresses: For stock users (not admins), the stock quantities list view display red lines for every product. Current behavior before PR: <img width="2243" height="217" alt="image" src="https://github.com/user-attachments/assets/330c591c-6ef4-46cb-8336-fa39fb483333" /> Desired behavior after PR is merged: Red lines are only displayed for products with a removal date and a removal date < current date <img width="2241" height="290" alt="image" src="https://github.com/user-attachments/assets/fe37adc7-e736-447e-a21e-e2fae984e074" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228992
This update fixes a backend issue where certain request parameter names could conflict with core remote call fields. It helps ensure affected Odoo web requests are handled reliably without disrupting normal business workflows.
Original PR description
Backport 1bb69de64165b18fca7d00164c5299e58c48d40f > 44:18.716 INFO o.t.result: 0 failed, 0 error(s) of 12 tests when loading database 'odoo-backport-json2-name-collison'
This update adjusts how AI-related functions are called so they are easier to customize and better aligned with newer versions. It is an internal reliability fix with no expected direct impact on day-to-day users.
Original PR description
To ease the override and compatibility with what is done in 19.0, we call the function with kwargs instead of args. Forward-Port-Of: odoo/enterprise#96528
This fixes a problem where Google address suggestions could fail during eCommerce checkout if Google returned address details in an unexpected order. The autocomplete now chooses recognized address information first and better handles regional city formats, reducing checkout address entry errors.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I…
Versions -------- - 18.0+ Steps ----- 1. Enable Google address autocomplete; 2. go eCommerce checkout; 3. add an address during the delivery step; 4. autocomplete a bunch of addresses. > [!Note] > I haven't been able to reproduce it myself, but others have. > It appears that the order Google provides place types isn't always the same. Issue ----- You may get a `KeyError`, trying to fetch `standard_data['country']`. Cause ----- The fields get sorted by type, and we try to sort `country` before `state`, so that the `country` key should be present when we get to `state`. The likely issue is that Google often provides multiple types per field, and we only keep the first one, assuming it to be the most relevant one, but the API documentation makes no guarantees about the array's order[^1]. For example, if a field were to have `political` in front of `country`, we would keep the `political` type, only to ignore it later on, as we have no mapping for it. [^1]: https://developers.google.com/maps/documentation/places/web-service/place-types#address-types Solution -------- 1. Iterate over the types, and get the first one that's part of `FIELDS_MAPPING` 2. Before searching for a `state`, ensure `country` has already been set, otherwise log a warning. 3. Extra: add `postal_town` as a type, which gets used instead of `locality` in some countries like Sweden. opw-4880651 Forward-Port-Of: odoo/odoo#230134 Forward-Port-Of: odoo/odoo#217171
This fix prevents valid accented characters, such as ü, from being removed from legal names used in Mexican electronic invoicing. It helps ensure company names match official SAT records and reduces the risk of rejected or incorrect documents.
Original PR description
Previous commit (#95207) removed accents for names including character ü which indeed is a recognized character for SAT opw-5125107 Forward-Port-Of: odoo/enterprise#96043
Loyalty discounts and coupons now use a consistent date check during checkout and payment confirmation, preventing valid orders from failing because of timezone differences. Expired coupons are also removed from orders at the right time, so payment totals stay accurate and customers are not charged incorrectly.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California…
Versions -------- - 17.0+ Steps ----- 1. Have a database with GeoIP enabled; 2. have a promotion program that gives a discount on a specific product; 3. use a VPN to browse /shop from California before 7:00 UTC; 4. add the product to your cart; 5. go to checkout; 6. pay for the order. Issue ----- Order cannot be confirmed due to incomplete payment. Cause ----- The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order. Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order. Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed. Solution -------- If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates. For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone. For website orders, if defined, use the eCommerce salesperson's time zone instead. Also fix an issue where expired coupon lines weren't getting removed from the order. opw-4765873 opw-4781346 opw-4939268 Forward-Port-Of: odoo/odoo#229749 Forward-Port-Of: odoo/odoo#222428
This fixes an issue where computing taxes on an invoice could fail when no tax was found for a customer's ZIP code. The system now handles the missing tax details safely, helping users complete invoice tax calculations without interruption.
Original PR description
Currently, an error occurs when computing taxes for an invoice. **Error:** `KeyError: 'manual_tax_amounts'` **Cause:** When a user clicks the `Compute Tax` button, the system calculates the tax for…
Currently, an error occurs when computing taxes for an invoice.
**Error:**
`KeyError: 'manual_tax_amounts'`
**Cause:**
When a user clicks the `Compute Tax` button, the system calculates the tax for that invoice, including the `manual_tax_amount` [1]. However, if no tax is found for a given customer ZIP code, the `tax_values_list` becomes empty [2]. As a result, `manual_tax_amounts` in the base line also becomes empty.
Later, when the system tries to fetch the `manual_tax_amounts` key from extra_tax_data, it raises a KeyError [2], because the key no longer exists.
Additionally, the condition in [3] indicates that there is no guarantee that the `manual_tax_amounts` key will always be present in the base_line.
**FIX:**
This commit ensures that if the manual_tax_amounts key does not exist, an empty dictionary {} is used instead. This prevents the KeyError from occurring during tax computation.
[1]- https://github.com/odoo/enterprise/blob/b17b6b4e5ca3085d831fc763457496b5c5b639c5/account_external_tax/models/account_external_tax_mixin.py#L155-L163
[2]- https://github.com/odoo/enterprise/blob/a51aee8f6e8bce2aa699d3199d6723495464a762/account_external_tax/models/account_external_tax_mixin.py#L88
[3]- https://github.com/odoo/odoo/blob/241c170dbece8c1652db9ca1aa935b2106ede532/addons/account/models/account_tax.py#L1330
sentry-6919182805Fixed an issue that blocked users from editing properties on several demo job offers in the Recruitment app. These demo jobs now correctly use the current company, preventing the warning and allowing configuration changes as expected.
Original PR description
Steps to reproduce: - Go to the Recruitment app - Open the configuration panel for the demo offer for CTO, Consultant, Experienced Developer or Human Resources Manager - Click on the cogwheel - Select "Edit properties" - A warning appears and you can't edit properties Reason: The definition of the job demo data sets the "company_id" field to False, which causes an error when you try to edit the properties. How it was fixed: By removing the explicit value of False for the field "company_id", it will auto assign the field to the current company and allow the properties to be edited correctly. Task ID: 5093032