Daily updates from Odoo
Wednesday, October 8, 2025
73 changes · 19.0
Security fixes and vulnerability patches
The POS employee login screen now avoids triggering browser password saving or autofill prompts. This helps protect employee credentials on shared devices where multiple staff members access the same point-of-sale system.
Original PR description
*=point_of_sale Following this commit: ==== - Replaced 'password' input type with masked 'text' input to prevent browsers from offering to save or autofill credentials on the splash screen. - This improves security in shared device environments, especially when multiple employees access the system on the same device. task-4800745 Forward-Port-Of: odoo/odoo#211040
New functionality added to Odoo
Adds a new Lazada connector so businesses can manage Lazada shops directly from Odoo. It imports orders, synchronizes products and inventory, supports Lazada- and merchant-fulfilled workflows, and handles fulfillment details such as shipping labels and tracking.
Original PR description
This module: * Import orders from multiple accounts and shops * Orders are matched with Odoo products based on their internal reference (item_id or model_id in Lazada) * Support for both Fulfillment by Lazada (FBL), Fulfillment by Merchant (FBM): * FBL: Importing the completed orders * FBM: Delivery information is fetched from Lazada, track and synchronize the stock level to Lazada. Features: * Shop authorization * Order fetching * Lazada product fetching * Stock level pushing * Order fulfillment * Shipping label fetching task - 3478992
Enhancements to existing features
The state selection field now uses the same spacing as similar lookup fields. This creates a more consistent form layout and removes an unnecessary visual gap when searching for states.
Original PR description
Related PR: https://github.com/odoo/odoo/pull/229290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230338
This change updates the follow-up process tests to use the newer journal items action instead of the older overdue entries flow. It helps keep the accounting follow-up feature aligned with the current workflow while removing unused pieces.
Original PR description
Current behavior before PR: - The test_journal_items_action_domain_filters_partner_posted_entries test was calling action_open_overdue_entries on the partner. - It checked overdue invoices by…
Current behavior before PR: - The test_journal_items_action_domain_filters_partner_posted_entries test was calling action_open_overdue_entries on the partner. - It checked overdue invoices by searching moves with the returned domain. Desired behavior after PR is merged: - The test now calls the new action action_open_partner_followup_journal_items. - It searches for account.move.line records using the action domain. - It validates the related invoices via line_ids instead of directly searching moves. - Removes redundant code. Changes implemented: - Replaced action_open_overdue_entries with action_open_partner_followup_journal_items. - Replaced search on account.move with search on account.move.line. - Assertion updated to check the invoices line ids are equal to move_lines.ids. - Removed view_followup_invoice_list custom view and action_open_overdue_entries which no longer used - Renamed test_overdue_invoices_action_domain_includes_children_partners testcase to test_journal_items_action_domain_includes_children_partners and updated its docstring. related commit-[75533f4](https://github.com/odoo/enterprise/commit/75533f4808f2aa52f70a12dba8829caef44bf1b7) related pr-[upgrade#8470](https://github.com/odoo/upgrade/pull/8470)
Mexican payroll now uses payslip issue checks to warn users when required information is missing for CFDI generation. This helps payroll teams identify and resolve data problems earlier, reducing failed or delayed electronic payslip processing.
Original PR description
We now have a "issues" system on the payslips. Let's use it to signal what is missing for the correct generation of the CFDI. Task: 5068311
This update adds shared automated testing for country-specific point of sale compliance features, with tailored steps where local rules require them. It helps reduce the risk of regressions across several localized POS setups and improves confidence when delivering future changes.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788 Forward-Port-Of: odoo/enterprise#96074 Forward-Port-Of: odoo/enterprise#91928
This update adds shared automated checks for point-of-sale localization modules across multiple countries. It helps reduce the risk of country-specific POS compliance or invoicing issues reaching customers by validating common flows with local variations.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788 Forward-Port-Of: odoo/odoo#229614 Forward-Port-Of: odoo/odoo#222232
When users upload XML bills from bank reconciliation, the system now automatically activates the bill currency if it was inactive. This removes a manual step, speeds up bill upload, and makes the reconciliation workflow smoother.
Original PR description
Before: - When the user uploads an XML file from the bank reconciliation widget using 'Upload Bills' button and a currency of that bill is not active, then we ask the user to activate that currency manually. - Since users know the currency of Bill at the moment, we should directly activate the currency. After: - Now we activate the currency of Bill directly if it is not active, without asking to the user. Impact: - Improves user experience by not manually activating the currency of the bill. - Save users' time when uploading Bills in the bank reconciliation line. Task-5108103 Forward-Port-Of: odoo/enterprise#95513
Resolved issues and error corrections
Moving a CRM opportunity into an empty pipeline stage with recurring revenues enabled no longer triggers an error. This keeps sales teams' pipeline views stable during normal drag-and-drop updates.
Original PR description
**Steps to reproduce:** 1.Install crm 2.Enable 'Recurring Revenues' from settings 3.Go to CRM > 'My pipeline' > Create a record here 4.Enable debug mode 5.Either create a new stage or move records from any stage to make an empty stage 6.Move created record to an empty stage **Issue:** This Traceback accurs : "Uncaught Promise > Invalid props for component 'AnimatedNumber': 'value' is not a number" **Cause:** https://github.com/odoo/odoo/blob/5ade756227abf58769ff904651628a3ccaf8e19a/addons/web/static/src/views/view_components/animated_number.js#L8-L21 AnimatedNumber expects a numeric value for its value prop. When moving to an empty stage, the aggregate value is false, which is not a valid number for the component. **Solution:** Check for the rrmAggregate value to render the component. opw-4972672 Forward-Port-Of: odoo/odoo#221705
The accounting dashboard's drag-and-drop buttons and upload areas now automatically adapt to light and dark themes. This removes mismatched hardcoded colors, improving visual consistency and readability for users who switch themes.
Original PR description
Current behavior before PR: - Drag & drop buttons and upload drop zones of dashboard cards had hardcoded backgrounds (#F2EDF0 / grey), which did not adapt to dark mode. Desired behavior after PR is merged: - Removed hardcoded background colors from drag & drop button and upload drop zone cards on dashboard and updated their background to adapt in light & dark modes. Changes implemented: - Removed hardcoded background color (`#F2EDF0`) from `account_drag_drop_btn` & `drag_to_card` CSS classes. - Removed overriding background-color property from `o_drop_area` CSS class. - Updated background-color of `o_drop_area` in `o_account_dashboard_kanban_view` CSS class to `o-view-background-color`. task-5092460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227707
Saving an invalid website domain now displays a user-friendly validation message instead of causing an unexpected error. This helps administrators quickly correct domain entries and prevents disruption when updating website settings.
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 fixes how the HTML editor recognizes background-related styling classes, including variants with custom prefixes. It prevents unrelated class names from being treated as color styles, making editor formatting more reliable.
Original PR description
The previous regex `/\bbg-[^\s]*\b/` did not correctly handle class names with prefixes and could incorrectly match strings like 'someprefix-bg-primary'. Updated regex: `/(?:^|\s)(?:text-)?bg-[^\s]+/` | Feature | Old Regex | New Regex | |:----------------------|:--------------|:-------------------------------| | 'bg-*' classes | ✅ Yes | ✅ Yes | | 'text-bg-*' classes | ✅ Yes | ✅ Yes | | Avoid 'someprefix-bg-*' | ❌ Incorrect | ✅ Correct | | Custom prefixes | ❌ No | ✅ Yes (e.g., 'foo-bg-*') | | Boundary detection | \b word | ^ or whitespace (?:^|\s) | This fix ensures accurate parsing of CSS class names in the codebase while supporting both standard and custom prefixes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a CRM test select the intended customer record and wait for the opportunity name to be ready before continuing. It reduces false test failures and helps keep CRM quality checks stable without changing customer-facing behavior.
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
Link previews now show the correct page title even for users who lack access to certain backend actions. This prevents confusing generic “Odoo” preview titles and gives users clearer context when sharing or pasting links.
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 New User Invite email template now generates website and email links correctly. This prevents recipients from receiving malformed links, making onboarding invitations work as expected.
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
This fix prevents an IoT device from immediately losing its server configuration after being paired again in a specific recovery scenario. It helps avoid failed setup loops and reduces manual reconfiguration for users managing IoT boxes.
Original PR description
Steps to reproduce: 1. Pair your IoT 2. From the IoT homepage, clear the server configuration 3. From the DB, delete the IoT box record 4. Pair your IoT again EXPECTED BEHAVIOUR: - IoT pairs succesfully ACTUAL BEHAVIOUR: - IoT pairs but then immediately clears the server configuration This commit introduces a simply sanity check to workaround the issue, by simply ignoring a `server_clear` message if it was received less than 5 seconds after connecting to the websocket. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230244
Closing the barcode scanning dialog before the camera preview finishes loading no longer causes an error. This improves reliability for users who navigate back or press Escape while opening the scanner.
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
Credit notes created after a sales order down payment now correctly reverse the cost of goods sold. This keeps inventory and expense accounting accurate when customers are refunded after partial upfront payment.
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
This fixes ISO 20022 payment files for Danish banks by allowing the required local clearing instruction to be added when configured. Businesses using Danish bank payments can avoid rejected payment files by setting the appropriate clearing option, while behavior stays unchanged if no option is set.
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
The German Datev export no longer fails when sale or purchase receipts are created without a customer or vendor. This helps businesses export accounting data reliably even when receipts do not require partner details.
Original PR description
Since 18.4, there are purchase receipts as a function for vendor bills, where you can choose to put no vendor in the vendor field, the same is true for invoices with sale receipts. Making sure that partners are not Null task-5114562 Forward-Port-Of: odoo/enterprise#95649
The sales dashboard spreadsheet now applies the selected medium filter to list sections as expected. This keeps dashboard list data consistent with the rest of the filtered sales report, improving reliability for users reviewing sales performance.
Original PR description
Before this commit, the medium global filter was not applied to the lists in the sales dashboard spreadsheet. Task: 5129301 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet engine up to its latest version with fixes for chart animations, dashboard chart menus, formatting conversion, sheet renaming, mobile formula access, headers, and pivot measures. Users should see smoother spreadsheet dashboards and fewer small interruptions when editing or presenting spreadsheet content.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/86fc4428f8 [REL] 19.0.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/86fc4428f8 [REL] 19.0.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/47bb54fc70 [FIX] chart: zoomable chart should be animated [Task: 5079057](https://www.odoo.com/odoo/2328/tasks/5079057) https://github.com/odoo/o-spreadsheet/commit/301b2ca0ec [IMP] carousel: allow full screen toggle in carousel [Task: 5078831](https://www.odoo.com/odoo/2328/tasks/5078831) https://github.com/odoo/o-spreadsheet/commit/975b3487fe [MOV] figures: rename `fullScreenChart` to `fullScreenFigure` [Task: 5078831](https://www.odoo.com/odoo/2328/tasks/5078831) https://github.com/odoo/o-spreadsheet/commit/0cea053f34 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306) https://github.com/odoo/o-spreadsheet/commit/a2df5684dd [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129) https://github.com/odoo/o-spreadsheet/commit/0c0386b3ec [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030) https://github.com/odoo/o-spreadsheet/commit/297ca4a894 [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626) https://github.com/odoo/o-spreadsheet/commit/030841ec5e [FIX] composer: show FX icon in inactive mobile composer [Task: 5092659](https://www.odoo.com/odoo/2328/tasks/5092659) https://github.com/odoo/o-spreadsheet/commit/23f44838cb [FIX] chart: fix button hover background in dashboard menu [Task: 5082189](https://www.odoo.com/odoo/2328/tasks/5082189) https://github.com/odoo/o-spreadsheet/commit/242c9a7966 [FIX] pivot: add deferred calculated measure [Task: 5096156](https://www.odoo.com/odoo/2328/tasks/5096156) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Live chat visitors can no longer start calls or invite guests from chat threads. This prevents unsupported visitor actions and keeps live chat interactions aligned with intended permissions.
Original PR description
This commit removes the possibility for live chat visitors to start a call and invite guests. task-4849019 Forward-Port-Of: odoo/odoo#229924 Forward-Port-Of: odoo/odoo#228531
This fix prevents Chilean electronic invoice XMLs received by email from failing when they contain accented characters such as Ó. Businesses can process these vendor documents more reliably without manual intervention caused by import errors.
Original PR description
### Issue:
The invoice XMLs having special characters like "Ó" received in DTE emails will trigger a traceback.
### Cause:
`.decode('utf-8')` will try decoding the bytes in utf-8 but Ó is not UTF-8, so there is a traceback:
```
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 1734: invalid continuation byte
```
In any case, it crashes at the next line: `xml_content = etree.fromstring(xml_dte)` because the XML specifies the encoding (i.e. unicode) but the true encoding is `utf-8` so an error is raised:
```
ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
```
### Solution:
Remove `.decode('utf-8')` when decoding. The method `fromstring` accepts bytes and will use the encoding specified in the XML.
opw-5124661
Forward-Port-Of: odoo/enterprise#96410This fixes an inventory valuation issue where FIFO product costs could be updated from the manually set cost instead of the actual valuation average. After revaluation, product cost now stays aligned with inventory value, improving accuracy for stock accounting and reporting.
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
The Point of Sale automated test tour now waits longer for the system to load when many localizations are installed. This reduces false test failures in slower setups and helps keep release validation stable.
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
Fixes an issue where automatic replenishment could create purchase orders with slightly inflated quantities when product packaging used different unit multiples. This helps businesses avoid unnecessary over-ordering and keeps inventory purchases aligned with actual demand.
Original PR description
**Steps to reproduce:** - enable "units of measure & packagings" settings - navigate to "units and packagings" and create a new one called "pack of 2" - set a quantity of 2 and the reference unit as…
**Steps to reproduce:** - enable "units of measure & packagings" settings - navigate to "units and packagings" and create a new one called "pack of 2" - set a quantity of 2 and the reference unit as "units" - create a new storable product - next to "sale price" change the unit to "pack of 6" - in the sales tab add "pack of 2" in the packagings - in the purchase tab add a vendor - click on the reordering rule smart button and create a new one - set the min and max to 0 and set the replenishment multiple to "pack of 2" (you might have to make this column visible using the filters) - create and confirm a quotation for 1 pack of 6 **Current behavior:** a new Purchase Order is created for a quantity of 1.02 **Expected behavior:** it should be a quantity of 1 **Cause of the issue:** qty_multiple is rounded (in _compute_quantity) before the computation of remainder. https://github.com/odoo/odoo/blob/7a0a246016d50ae80e49f3502a97e82d414ab0b0/addons/stock/models/stock_orderpoint.py#L373-L376 In cases of repeating decimal numbers (like 0.3333333 in our example), this leads to the remainder not being 0 even though it should be 0. opw-5040144 Forward-Port-Of: odoo/odoo#230013 Forward-Port-Of: odoo/odoo#228014
Fixes minor visual issues when editing spreadsheet date filters on mobile. Active selections now show the check mark correctly, and navigation arrows remain visible and usable in the bottom sheet.
Original PR description
In mobile, the dropdown to edit a date filter value is now displayed in a bottom sheet. There was some minor issues in the styling: - the check icon for active item wasinside another icon - the arrow next/previous were grayed out since ":hover" doesn't really exist on mobile Task: [5092756](https://www.odoo.com/odoo/2328/tasks/5092756) 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
Appointment bookings with multiple staff members now calculate manual confirmation thresholds using the combined capacity of all assigned users. This prevents bookings from being unnecessarily marked as requests when enough total capacity is still available, and adds test coverage for this behavior.
Original PR description
While the fix has been already implemented in 19.0 in [1], this commit forwards-port the test of the original commit, as it differs from the one included (modified) in [1] and treats the case of…
While the fix has been already implemented in 19.0 in [1], this commit forwards-port the test of the original commit, as it differs from the one included (modified) in [1] and treats the case of managing capacity, and some other use cases not covered by the test in [1]. A small error is also corrected in a separate commit, as the appointment used to get the phone question was wrong in a test related to the original issue. ORIGINAL ISSUE ============== Introduced in https://github.com/odoo/enterprise/commit/bce7e94650c337a9046958a7689c81db5b2a4c73, We now handle capacity when booking users. They have each a max capacity of user_capacity for each slot. However, when it comes to the manual confirmation treshold, we do not account for the total capacity of all users combined, but consider the maximum to be user_capacity! This can lead to a lot of 'request' meetings as we reach the manual confirmation percentage very quickly. STEPS TO REPRODUCE ================== 1. Create an appointment type based on users, with 'manage capacities' enabled, 'manual confirmation' enabled and 'when over' 50% total capacity. Set 2 users and 3 'seats max'. This way, the total capacity of your appointment is 2 * 3 = 6 per slot. 2. As a public user, take an appointment for 2 capacity in the front end 3. The meeting will end up as a 'request', even though the capacity booked is 2/6 < 50%, and should be 'booked' FIX === We now multiply the number of users on the appointment type by the user_capacity when computing the total capacity and comparing it to the asked capacity on booking an appointment. 1 : https://github.com/odoo/enterprise/commit/b19e26b0333180ba7a487e14e06385693cf7ab16 Task-4930778 Forward-Port-Of: odoo/enterprise#89876
UPS shipping rate checks during ecommerce express checkout no longer fail when shoppers have only provided the limited address details required at that stage. This helps customers continue checkout smoothly before entering full street and phone information later.
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
Adyen redirect payments now skip amount and currency checks that do not apply to that payment flow. This prevents valid redirect transactions from being blocked unnecessarily, helping checkout completion stay smooth.
Original PR description
Amount and currency validation is skipped for redirect transactions.
Fixes an error that could stop users from validating payments in Point of Sale when using Kenya OSCU electronic invoicing. This ensures sales can be completed normally for Kenyan companies without the checkout process failing.
Original PR description
**Steps to reproduce:** 1. Install `l10n_ke_edi_oscu_pos`. 2. Set company to a Kenya (KE) company. 3. Open POS → Clothes shop → add a product → go to Payment → try to Validate → traceback occurs.…
**Steps to reproduce:**
1. Install `l10n_ke_edi_oscu_pos`.
2. Set company to a Kenya (KE) company.
3. Open POS → Clothes shop → add a product → go to Payment
→ try to Validate → traceback occurs.
**Issue:**
- A traceback is raised when validating a payment in the POS screen.
`undefined
TypeError: Cannot read properties of undefined (reading 'services')
at OrderPaymentValidation.beforePostPushOrderResolve`
**Cause:**
- ` this.env` and `this.orm` is not directly accessible in `OrderPaymentValidation`.
https://github.com/odoo/enterprise/blob/8ca771eb28a1fac13037c0d45e8d716d3dfc6ed2/l10n_ke_edi_oscu_pos/static/src/app/utils/order_payment_validation.js#L7-L24
**Solution:**
- Use `this.pos.env` instead of `this.env`, and `this.pos.data.call` instead of
`this.orm.call` to correctly access the environment and execute data calls
during payment validation.
> Reference:
https://github.com/odoo/enterprise/blob/5a794a6e69ba884862b4a3f399143d1392caa6f0/pos_barcodelookup/static/src/overrides/components/product_screen/product_screen.js#L8-L10
[Related Community PR](https://github.com/odoo/odoo/pull/230069)
**opw - 5137557**Opening the Quality Points button from a product in Point of Sale no longer causes an error. The system now opens the correct quality control view, preventing disruption for users reviewing product quality rules.
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 fixes an internal website test that was failing when video snippets opened an unexpected media dialog. The test now skips video snippets in the same way it already skips image snippets, helping keep automated checks reliable without changing customer-facing behavior.
Original PR description
Since PR odoo/odoo#214984, the “test_03_snippets_all_drag_and_drop” test fails because the video snippet opens the media dialog and the test does not handle it. Solution: as with image snippets, we will ignore them in this test. Error: https://runbot.odoo.com/odoo/runbot.build.error/231594 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
Point of Sale now handles unusually large payment amounts without crashing during order validation. The fix also ensures the confirmation prompt closes correctly after approval, helping cashiers complete sales smoothly.
Original PR description
**Steps to reproduce:** 1. Install the POS module. 2. Open POS and add a product. 3. Proceed to the payment page. 4. Make a payment greater than (total cost of order * 1000). 5. Try to validate the…
**Steps to reproduce:**
1. Install the POS module.
2. Open POS and add a product.
3. Proceed to the payment page.
4. Make a payment greater than (total cost of order * 1000).
5. Try to validate the payment → traceback occurs.
**Issue:**
- A traceback is raised when validating a payment in the POS screen.
`undefined
TypeError: Cannot read properties of undefined (reading 'utils')
at OrderPaymentValidation.isOrderValid `
**Cause:**
- ` this.env` is not directly accessible in `OrderPaymentValidation`.
> Reference:
https://github.com/odoo/odoo/blob/33c789eeed3b307e40c0f7ab2c6bc07c33867498/addons/pos_online_payment/static/src/app/utils/order_payment_validation.js#L25-L28
**Solution:**.
- Use `this.pos.env` instead of `this.env` to correctly access the environment
during payment validation,
> NOTE
- After fixing the traceback, the 'Large Payment Amount' confirmation dialog
appears correctly. However, when clicking 'OK', the dialog was not closing
because the callback function `validateOrder` returned `False` even for valid
orders. This caused the dialog to reopen in an infinite loop.
https://github.com/odoo/odoo/blob/d309b52e5b19727b3e91ed91afd44e392a3b851a/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js#L71-L91
- Add return `True` in `validateOrder`, because even when the order was valid,
it returned `False`, causing the `ConfirmationDialog` to reopen repeatedly
when clicking "OK". Returning `True` ensures the dialog closes properly after
successful validation.
> Reference:
https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/point_of_sale/static/src/app/utils/order_payment_validation.js#L108-L138
[Related Enterprise PR](https://github.com/odoo/enterprise/pull/96284)
opw-5137557The website builder now clearly disables the remove button when a carousel has only one slide left. This prevents users from seeing an action that appears available but cannot actually remove the final required slide.
Original PR description
Steps to reproduce: - Drop a carousel snippet - In the builder options, click on the "-" button to remove all items except the last one. => The button is still displayed as working (not disabled), even though clicking on it won't remove the last slide. To clarify that this is the expected behavior, we disable the button if there is only one carousel item left. Forward-Port-Of: odoo/odoo#226877
This fixes Indian HR leave calculations so sandwich leave counts all applicable non-working days around a leave period, not just the nearest day. It also ensures half-day leave is recorded as 0.5 days instead of a full day, improving payroll and absence accuracy.
Original PR description
**Steps to reproduce:** - Install l10n_in and l10n_in_hr_holidays module - Time off > configuration > Public holidays - Create a public holiday for Independence Day (15/08/2025) - Go to Time off >…
**Steps to reproduce:** - Install l10n_in and l10n_in_hr_holidays module - Time off > configuration > Public holidays - Create a public holiday for Independence Day (15/08/2025) - Go to Time off > configuration > 'Time off Types', - Create a Time off type with - 'Sandwich leave' ticked and `Take Time Off in` to half a day - Go to Time off > Management > Time off - Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 - Case 2: Create a paid time off with any date and mark it as a half-day **Observation:** - Case 1: You will see Duration 3 days with the sandwich leave policy. - Case 2: Half-day leave shows 1 day instead of 0.5 **Root Cause:** - Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days. https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46 - Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not. https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19 **Solution:** - Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found. - Case 2: Fixed duration calculation to add 0.5 for half-day leaves. opw-5025766 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226883
This update prevents a crash when website interaction code waits on an action that intentionally returns no value. It makes the web interface more reliable for developers building interactive pages, with no expected change for everyday users except fewer errors.
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
This fixes incorrect buyer document values shown on Indonesian e-Faktur invoices when contacts use Other ID or National ID document types. The change helps ensure exported tax invoice data matches the expected official labels, reducing confusion and compliance issues.
Original PR description
the byer document has a wrong value in others and NIT. so this commit change the values to `Other ID` and `National ID` To check values: go to fields and search for `l10n_id_buyer_document_type` opw-4974469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222346
A test setup issue was corrected so that one internationalization test no longer changes settings used by later tests. This helps keep automated checks reliable and prevents false CI failures or missed test coverage.
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 Forward-Port-Of: odoo/odoo#230504
Restaurant floorplan buttons now display their labels when users hover over the whole button, rather than only when hovering the icon. This makes actions easier to identify and helps staff navigate the point of sale interface more quickly.
Original PR description
Display the title of buttons on hover in the floorplan (instead of showing title only when hovering icons). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now correctly shows and allows selection of product variant options that use the Image display type. This prevents sales staff from being blocked when selling products configured with these newer variant options.
Original PR description
**Steps to reproduce:** - Make a variant category, make it an Image - Add it to a product, go to PoS and order the product - The product variants will not be shown and can't be selected **Why the fix:** Since 19.0, there is a new kind of variant, Image, but it was not taken in the conditional statement for the product popup for the variants. As it didn't fall into any category, nothing was shown. At the moment this is basically the same as the Color option, but with an extra label below to provide more information. This it will be IMP later on with images like in the Sales module. opw-5099123
Online store cart notifications will now close automatically after 4 seconds instead of staying on screen indefinitely. This improves the shopping experience by preventing persistent messages from blocking or distracting customers.
Original PR description
Due to the notifications revamp in https://github.com/odoo/odoo/commit/bbe90382f6c65a6b8737b3e8ec8295b2ee733475, eCommerce notifications were showing indefinitely, with no way to hide them. This commit adapts the cart notification component to close itself after 4 seconds.
This update corrects how the website editor decides the default image format when adding or editing images. It prevents incorrect image type behavior caused by a browser interpretation issue, helping image handling work more reliably for users.
Original PR description
This commit fixes an issue introduced by 9685f54b53525429d5fbcfd5bdc45e0ff75d4581 with a condition that isn't properly interpreted by the browser's engine following the operators' precedence. The `!==` is interepreted before the `??` which leads to unwanted behaviors. [Source](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_precedence#table) task-5152847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Duplicated leads without an assigned salesperson now remain eligible for rule-based assignment. This prevents sales opportunities from being missed when teams rely on automated assignment rules.
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#227387Creating a new attendance record no longer crashes if the Check In field is emptied. The system now safely uses today's date when no check-in value is provided, allowing users to continue editing the record without interruption.
Original PR description
The system crashes with an error when the user removes the Check In value while creating a new attendance record and then tries to modify other fields. **Steps to produce:** - Install the `Attendances` module. - Go to the `Attendance app` and click on `New`. - In the wizard, remove the `Check In` value and click anywhere. **Error:** ```py AttributeError: 'bool' object has no attribute 'tzinfo' ``` **Cause:** - At [1], when the `check_in` value is changed, the `_compute_date` method is triggered. If `attendance.check_in` is `False`, the computation attempts to access `tzinfo` on a boolean value. **Solution:** - If the `check_in` value is not present, set the `attendance.date` to today’s date. [1] https://github.com/odoo/odoo/blob/b5a08dcd33cf72c129c4c512045edfe1d8c852a7/addons/hr_attendance/models/hr_attendance.py#L83-L90 **sentry-6924425687** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes Razorpay payment failures that could occur when a provider was configured with both standard credentials and OAuth. The payment flow now uses the correct authentication method, helping customers complete payments on mobile without 403 errors.
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
Invoices using the Saudi Arabia localization can now be printed or sent without triggering an error. The report date formatting was corrected so PDF generation works as expected for customer invoices.
Original PR description
Steps to Reproduce: - Open any customer invoice for l10n_sa localisation. - Click the Send or Print button. - The system shows a traceback instead of generating the PDF report. Issue: - The problem was caused by a wrong date format setting in the report template. Fix: - Updated the date field setup in the report so it formats correctly when printing or sending invoices https://drive.google.com/file/d/1eY3F78YVQzutLikTigXAR0I0_2DwWILs
This fix ensures separator lines in the email marketing showcase template remain visible in sent emails. It improves email layout consistency, especially on desktop displays, so recipients see the design as intended.
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#230485 Forward-Port-Of: odoo/odoo#226350
The website editor now shows clean mailing list names when adding checkbox options to a newsletter subscription form. This removes confusing numbers from the selection list, making form setup clearer for website editors.
Original PR description
In the "Subscribe to newsletter" form, "Add new Checkbox" on the web editor for "Subscribe to" field lists mailing list with number. This commit removes the number by fetching the records from mailing list via "name" and not "display_name". Steps to Reproduce: 1. Add a form 2. Change action to "Subscribe to Newsletter" 3. Click on "Subscribe to" field 4. Click on "Add new Checkbox" and you see the numbers on the list. opw-4730089 Forward-Port-Of: odoo/odoo#223499 Forward-Port-Of: odoo/odoo#210891
The employee form now shows a complete count of employee documents stored in the main employee folder and any subfolders, while excluding folders from the total. This gives HR teams a more accurate view of how many documents are attached to each employee.
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 fix prevents an error that could occur when employees opened their personal preferences after being assigned to a group. It helps ensure users can reliably access and update their profile settings without interruption.
Original PR description
Currently an error occurs when user open their preferences. **Steps to Reproduce:** - Install the `hr` module. - Go to `Groups`, create a group, and assign the `current user to it`. - Make sure this user has an `Employee record`. - Click on the `profile icon` in the top-right corner and select `My Preferences`. `IndexError: list index out of range` This commit adds a test for this [PR], as the issue is fixed here. [PR]: https://github.com/odoo/odoo/pull/230210 sentry-6913468854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds a safeguard in electronic invoicing calculations to avoid a rare division-by-zero error when very small amounts round down to zero. It helps keep invoice generation more robust against edge cases and future changes, with no expected impact on normal workflows.
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
The website builder now applies the correct spacing and text-size styling when regenerating pricelist descriptions. This keeps pricelist sections visually consistent after users edit or toggle description text.
Original PR description
New description paragraphs generated by the builder for the "pricelist" snippets were missing two expected classes. - "mt-2" was never applied, so all pricelist variants lacked the vertical spacing below product titles. - The boxed and cafe snippets also needed the `o_small` class to keep their text size consistent. Steps to see the missing "o_small": 1. Drop an "s_pricelist_boxed" or "Pricelist Cafe" snippet on a page. 2. Use Backspace to delete the text already present in one of the descriptions. 3. Toggle the "Descriptions" option off and on; the regenerated paragraph appears larger than expected because `o_small` is absent. task-5117864 Forward-Port-Of: odoo/odoo#229464
This change moves HR-dependent scheduling tests into the HR-specific project module so builds no longer fail when the HR app is not installed. It helps keep automated testing reliable across different installation setups without changing business functionality.
Original PR description
Steps to reproduce: - start test_auto_schedule_flex_resource when hr not installed. => `AttributeError: 'res.users' object has no attribute 'action_create_employee' Source: - action_create_employee comes from hr, but the test is in project_enterprise Fix: - tests related to hr moved to project_enterprise_hr
Outgoing stock movements split across multiple lots or serial numbers now allocate costs only to the relevant lot. This prevents overstated or distorted lot costs and gives businesses more accurate inventory valuation.
Original PR description
Description of the issue/feature this PR addresses: If "out" moves have more than one lot (i.e. two move lines for one move), then the lot cost calculations go way askew. Current behavior before PR: Lot cost calculations work by taking a subset of a stock move value, up to the quantity of just that lot. When recalcing lot cost, for "in moves" the value correctly uses a "portion" of the cost from the move. But for "out moves", it does not - assuming the FULL move is for a single lot. If multiple lots or serial numbers are on a single move, then it should apportion that too. Desired behavior after PR is merged: The out moves check the move lines for those for the specific lot, and only include a portion of the out in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mexican electronic invoicing now keeps valid accented characters, such as ü, in legal names. This prevents compliant customer or company names from being altered and helps avoid issues with SAT validation.
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
This update adjusts an internal website performance test so it no longer fails because of small query count differences caused by optional installed add-ons. It helps keep automated testing reliable without changing customer-facing behavior.
Original PR description
The difference query is not relevant to the overall performance of the page. This difference depends on how you run the tests with the other addons installed. issue: AssertionError: 36 != 37
Saudi invoices that include section lines can now be printed without causing an error. This ensures businesses using Saudi localization can generate compliant invoice documents reliably, even when invoices are organized into sections.
Original PR description
### Issue: Printing a Saudi invoice with section lines results in a traceback. ### Steps to reproduce: - Install l10n_sa and switch to a Saudi company - Create an invoice with section lines for a Saudi partner - Click "Print" ### Cause: To compute the totals for the section lines, we try to use the field `child_ids` but it was removed in [this commit](https://github.com/odoo/odoo/commit/572680aa30d41900223f1bea36e410e5c0270b37) for performance issues. ### Solution: Use `_get_section_lines()` added by the same commit. opw-5140406
The Join and Reject buttons shown in chat calls now keep the intended pill-shaped style and no longer appear oversized. This makes call actions clearer and more consistent for users when returning to conversations with active calls.
Original PR description
Before this commit, "Join" and "Reject" call actions with label, which are shown on chat with a call for which the user has already joined a call at least once, had wrong style. This happens because:…
Before this commit, "Join" and "Reject" call actions with label, which are shown on chat with a call for which the user has already joined a call at least once, had wrong style. This happens because: 1. they use `.rounded-pill` and `.rounded-start/end-3`, and the `.rounded-3` are behaving as `rounded-0` when with `rounded-pill` 2. buttons are bigger than expected, because of `aspect-ratio: 1` The `.rounded-3` and non-intentional: the button must be pill-shaped. This commit fixes this by making the condition for `.rounded-3` more specific, i.e. not consider join-leave-call buttons that are circled and pilled. For the sizing, this comes from recent change [1] that fixed issue in Picture-in-Picture were the buttons have different size than in the browser tab. The fix made by [1] affects more buttons than expected, such as the "Join" and "Reject" buttons. More investigation is necessary to understand why buttons have different sizes in picture-in-picture, but in the meantime it's best to remove the `aspect-ratio: 1`, as the current bug is more important to fix than the sizing of picture-in-picture buttons. Task-5149688 [1]: https://github.com/odoo/odoo/pull/228657/files#diff-94618ed43461f410ce199f94861d88901c7d868045d6bfe5614e134498e856aaR37 Before <img width="174" height="132" alt="Screenshot 2025-10-07 at 14 33 12" src="https://github.com/user-attachments/assets/ed228673-7cde-45a1-91e3-2438b258373b" /> After <img width="171" height="128" alt="Screenshot 2025-10-07 at 15 50 30" src="https://github.com/user-attachments/assets/b8882714-24a7-4fea-8442-2c915a9519b9" />
Stock quantity lists now only highlight products in red when they have a removal date that is already past due. This prevents regular products from being incorrectly flagged for stock users, making the list easier to read and helping teams focus on genuinely expired items.
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 fix prevents scheduled inventory valuation closing from crashing when the required journal or valuation account has not been configured. Businesses get a safer process with clearer handling of incomplete settings, reducing unexpected accounting interruptions.
Original PR description
When the journal is not set in the inventory valuation settings, running the cron ``Stock Account: Inventory Valuation Closing`` results in a traceback. Steps to reproduce the error: - Install…
When the journal is not set in the inventory valuation settings, running the cron ``Stock Account: Inventory Valuation Closing`` results in a traceback. Steps to reproduce the error: - Install ``accountant`` and ``stock`` modules - Go to Settings > Inventory Valuation > Periodicity: Daily > Unset the Journal > Save - Run the cron ``Stock Account: Inventory Valuation Closing`` Traceback: ```py NotNullViolation: null value in column "journal_id" of relation "account_move" violates not-null constraint ``` https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/stock_account/models/res_company.py#L57-L63 This occurs because when the journal is unset, ``journal_id`` becomes null, leading to the above error when the cron runs. Error also occurs when the Valuation Account is unset. Traceback: ```py CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" ``` sentry-6925934391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Chrome-specific issue where background videos in the ecommerce category showcase could flicker when visitors hovered between blocks. The change keeps the video display steady, improving the visual polish of website pages using this snippet.
Original PR description
**[FIX] website: stabilize showcase background video in Chrome** Steps to reproduce: - Drop the "s_ecomm_categories_showcase" snippet. - Change its background to a video. - Hover between the different blocks. - Bug: the video flicker on hover. Before this commit Chrome kept resizing the iframe, making the video flicker on hover. After this commit we freeze the iframe sizing in pixels so Chrome keeps the video stable. task-5104176
Event description links are now formatted so they work reliably in email clients such as Gmail. This prevents broken or confusing event URLs for recipients, helping attendees access event information without issue.
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
Google address suggestions can list address details in different orders, which sometimes caused checkout address completion to fail. This fix picks recognized address fields more reliably, preventing errors and improving address handling for customers in countries with different locality formats.
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
The point of sale preset form now displays key fields more cleanly, especially on mobile screens and when time-based order management is disabled. This makes setup easier for restaurant or shop staff by avoiding overlapping labels, misplaced inputs, and confusing placeholder text.
Original PR description
In this commit: -------------- - The preparation capacity field was not properly displayed when manage orders by time is disabled, now we have added a additional class to make ui proper. task: 5077509
This fix changes how AI tool functions receive their inputs, making them easier to customize and better aligned with the current version. It helps reduce compatibility issues for implementations that extend or override AI behavior.
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 fix prevents an error in the Indian withholding workflow when the action is opened without any selected records. Users now receive a clear message instead of encountering a confusing failure, helping avoid interruption during tax-related processing.
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
Loyalty discounts and coupons now use a consistent date when checking expiration, preventing valid checkout payments from failing because of timezone differences. Expired coupons are also removed at the right time, so order totals stay accurate before payment is completed.
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
The video call interface now highlights the fullscreen button directly instead of drawing attention to the overflow menu. This makes it clearer for users how to switch to fullscreen during Discuss calls.
Original PR description
Before this commit, when someone enabled video for the 1st time in a discuss conversation, the "..." call action had pulse animation. This is there to incite using the fullscreen mode, which was in the "..." in the past. Now that this button is in the bottom right of call view and immediately available, the pulse effect can be immediately moved to the fullscreen button. Before  After 
The Indian payroll demo contract now lists Mitchell Admin as the HR Responsible instead of OdooBot. This makes the sample offer signing flow better match a realistic logged-in user experience.
Original PR description
Currently, OdooBot is set as the HR Responsible in the default contract template demo data. To make the offer signing process more realistic and aligned with the login user, OdooBot is replaced with Mitchell Admin. task-5095841
Payroll payment reports can now be generated when an employee has multiple bank accounts with a 100% and 0% salary split. This prevents report failures and ensures all configured bank accounts can be included correctly in the CSV output.
Original PR description
-When generating a payment report CSV for user with multiple bank accounts that have a salary split of 100%/0%, a traceback occurs. -The logic has been adjusted so that bank account of 0% split percentage can be included in the payment report.
Code cleanup and technical improvements
This update reorganizes how embedded action settings are managed so they are easier to maintain and less prone to mistakes. It also adds automated checks to help ensure project-related settings are copied, removed, saved, and retrieved correctly.
Original PR description
In this PR, we rework the embedded actions settings logic in the control panel, to use a "pure" class that contains all the state and logic related to these settings. We also rework the `ResUserSettings` mock model in `web` to make it generic and use it in other modules, like in `mail`. Finally, we add Python tests to ensure the correct behavior of the embedded actions settings when copying/removing projects and when setting/getting those settings from the DB (check validity of fields and correctness). We also add some checks in the JS tests to ensure that the embedded actions settings are correctly set. task-5003800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr