Wednesday, November 5, 2025
27 changes · saas-18.3
Resolved issues and error corrections
The website now only shows the language selector when there is more than one language available. This prevents an empty menu item from appearing in the header, which removes an unnecessary border or blank space and improves the page layout.
Original PR description
This PR calls the language selector placeholder only when multiple languages exist, avoiding an empty header list item that creates an unnecessary border or empty space. task-5150808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233744 Forward-Port-Of: odoo/odoo#231256
This fixes an issue where a product selected through the variant grid could be incorrectly treated as part of an existing combo, causing its extra price to be added to the combo instead of creating a separate order line. With this change, the system now properly separates combo items from standalone products when the grid opens and saves.
Original PR description
Steps: - create a product with attributes of create_variant=never - set variant selection to order grid entry - add this product as a combo choice and set extra_price>1 - In sale order form first add the new combo product with the previously created product - add the new product with same selection of attribute values as combo Issue: - The separately added product should create a new line, but since it was added as a part of the combo, the product's price is summed with extra price and added to the combo itself Cause: - the grid field that is responsible for adding product using product matrix does not filter combo lines Fix: - added filter for combo lines when matrix opens and saves opw-5164789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234102
This change removes Chinese yuan (CNY) from the PayPal payment options in Odoo. It prevents customers from reaching a payment flow that PayPal cannot complete for most non-China accounts, avoiding failed invoice payments and confusion.
Original PR description
## Versions 18.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
18.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893
Forward-Port-Of: odoo/odoo#232092This fix ensures that when multiple product variants have different prices, adding one lot-tracked variant in Point of Sale no longer changes the prices of the other variants. It helps keep pricing accurate at checkout and avoids unintended price updates for customers and staff.
Original PR description
Before this commit, when a product had multiple variants with different prices and was tracked by lot, adding different variants in the PoS would incorrectly update all product prices. opw-5228830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234171
This change rolls back a previous bot-detection filter in the Blog and Slides areas. The earlier check was not reliable, so it is being removed while a better way to limit unwanted crawling is developed.
Original PR description
This reverts [1] because the is_a_bot check is not reliable. Many crawlers spoof user agents or ignore robots rules, so they still index every tag combination and overload tag clouds. We revert while we look for a better protection. [1]: 4b1c3bfa83af2b1851db62df5aca4d5777a3d88c Forward-Port-Of: odoo/odoo#234278
This update adjusts an automated sales/manufacturing test so it no longer depends on a field that only exists when Enterprise is installed. It helps keep the test suite reliable across different Odoo setups and prevents false failures during validation.
Original PR description
Cause ----- Test introduced in 2da1c78 uses the field `backorder_ids` which is only present when enterprise is installed https://github.com/odoo/enterprise/blob/67fdbc5ae724a184d62d8cfa23403b8c759b9317/stock_barcode_mrp/models/mrp_production.py#L10 ----- Error: 233584 Forward-Port-Of: odoo/odoo#233730
This fix adds a safety check before using certain HR menu entries, so the system no longer fails if those menus have been removed or are missing during an upgrade. It helps keep database updates and maintenance tasks running smoothly, especially in older databases with customized setups.
Original PR description
To Reproduce: 1) make a database in 16.0 and go to developer mode. 2) Delete the menus 3) I mocked the views with upgrade mockcrawler. it failed for these xmlids: ``` hr_attendance.menu_hr_attendance_attendances_overview hr_timesheet.timesheet_menu_activity_use hr.menu_hr_employee ``` but we should have a check anyways. 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#230135 Forward-Port-Of: odoo/odoo#215426
This update prevents accounting journals from reusing the same alias when a journal type is selected before its name. It removes an error that could block users from saving a second journal of the same type, making journal setup smoother and more reliable.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225537
Event registration forms now request the reCAPTCHA verification token only when the user submits the form, instead of when the form first opens. This prevents the token from expiring while someone is filling out the form, so registrations complete successfully even if it takes a few minutes.
Original PR description
Steps to reproduce =============== 1. Enable reCaptcha in Settings and configure keys. 2. Go to an event and click Register. 3. Fill in the form but wait more than 2 minutes. 4. Submit the form ---> An error message is shown. When reCaptcha was enabled on event registrations, the token was being requested too early (during `willStart`). Since a token is only valid for 2 minutes, users who took longer to fill out the registration form encountered an error when submitting. After this commit, the reCaptcha token is requested only on submitting. This way, the token is always valid and the form can be submitted successfully, even after several minutes. Task-4982067 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#233517 Forward-Port-Of: odoo/odoo#223538
Fixed an issue in the product screen where tapping an order line no longer selected it when the certified scale module was installed. This restores the expected behavior so staff can select items normally, while long press continues to open the configurator popup.
Original PR description
Task: [5163235](https://www.odoo.com/odoo/project/1737/tasks/5163235) --- In the product screen, pressing an orderline was supposed to select this line and a long press was supposed to open the Configurator popup. However, since the feature of the long press, if we install the module `l10n_eu_iot_scale_cert`, pressing an orderline does not select it anymore. This was due to the fact that a `t-ref` was added in the orderline template and that in the `l10n_eu_iot_scale_cert` module, we were overriding this template completely. Forward-Port-Of: odoo/enterprise#96980
This update removes a flicker that appeared when hovering over the favorite filter edit icon in the search bar. The icon now keeps its space visible in the layout, so the menu no longer shifts size and behaves more smoothly.
Original PR description
This PR fixes an issue related to the edit favourite filter icon. Prior to this PR, the edit favourite filter icon used `d-none` by default and `display: block` on hover. Since `display: none` removes the element from the layout, the parent popover resized on hover, causing a flickering effect. This did not occur for filters with short labels (which had enough room for the icon) or for long labels (where the label was truncated). To prevent the flickering, the icon now uses `visibility: hidden/visible`, which keeps its space in the layout and avoids layout shifts. https://github.com/user-attachments/assets/5308c11e-8706-403c-80e3-fc05ab37a61d task-5237493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales quotations can now be previewed correctly even after being customized with Studio. This prevents an error that previously blocked the portal report preview when certain sales report fields were added.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5136553 Forward-Port-Of: odoo/odoo#233755
The bank reconciliation screen now updates correctly when users move through paginated records. This prevents reconciliation buttons and partner counts from disappearing on later pages, so accountants can continue reconciling records without losing key information.
Original PR description
Issue: when navigating through paginated records in the bank reconcilliation widget the functions `computeReconcileLineCountPerPartnerId` and `computeAvailableReconcileModels` were not re-executed. This caused reconciliation model buttons and partner counts to disappear on pages after the first. steps to Reproduce: 1 - In a database with >80 records to reconcile and pre-existing reconciliation models: 2 - Go to Accounting -> N to reconcile button. 3 - In Kanban view expand a record to view reconciliation model buttons (displays correctly). 4 - Navigate to the next page. - From the second page onward, reconciliation model buttons and partner counts are not displayed. fix: on top of the `onWillStart` hook, which runs at the view is first rendered, I added `onRootLoaded` to ensure computations run whenever the dependencies change, updating the widget correctly on pagination. opw-5083877
This update adds the required accounting setup to an automated dropshipping test so it can run correctly even when demo data is not installed. It prevents the test from failing because a purchase journal was missing, improving the reliability of the test suite.
Original PR description
The test `test_dropship_return_backorders_bill_on_order` failed when running without demo data because no chart of accounts was installed, so no Purchase journal existed. As a result, `purchase_order.action_create_invoice()` raised: UserError: No journal could be found in company ... for any of those types: purchase This change inherits from `AccountTestInvoicingCommon` to have the necessary charts. [runbot-231285](https://runbot.odoo.com/odoo/error/231285) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224775
Tax closing entries are now linked to the right tax report, so generating a closing entry from a generic report or a national variant no longer creates duplicate or mismatched draft moves. This ensures users get a single, consistent closing entry for the same period, which avoids confusion and incorrect follow-up actions.
Original PR description
To reproduce the issue, on a Belgian company: 1) From the Generic Tax Report, or any of its two grouped variants (Account>Tax or Tax>Account), click on the closing entry button. It generates a draft…
To reproduce the issue, on a Belgian company: 1) From the Generic Tax Report, or any of its two grouped variants (Account>Tax or Tax>Account), click on the closing entry button. It generates a draft move. Log a note on that move. 2) Open the national tax report of Belgium, for the same period as in 1). Click on the closing entry button again. ==> The draft move generated in 2) is NOT the same as the one generated in 1) (you can check that from the note logged in 1)). This is because tax_closing_report_id is too naively set on the account.move, to always match the report on which the button was clicked. This commit fixes that, ensuring we set the right report in the closing field. Something will be done in the migration script to 19.0 to set the report properly before creating the returns. The problem also occurs when multiple national variants are available : in this case each of those reports creates a distinct closing entry, with the exact same informations, giving the illusion we're doing per-report closings. In such cases, we associate the closing move to the Generic tax Report. opw-4858689 Forward-Port-Of: odoo/enterprise#95775
This update removes a warning that could appear when using the booking form in Point of Sale during automated tours. It helps keep the POS experience cleaner and avoids confusing warning messages during testing and usage.
Original PR description
This will remove missing wigdet warning encountered when using the booking form from the point of sale. opw-5109501 Enterprise: https://github.com/odoo/enterprise/pull/96811
This fix corrects the mobile editor toolbar so it no longer switches to image controls when a text format like bold is applied. Users will now see the normal formatting toolbar and the active formatting button will be highlighted properly, making mobile editing clearer and more reliable.
Original PR description
**Current behavior before PR:** In mobile view, when applying the bold format using the toolbar button, the normal toolbar is incorrectly replaced by image toolbar. This occurs because `getFilteredTargetedNodes` returns an empty array, and as a result, the `isApplied` method evaluates to true since Array.every on an empty array returns true. **Desired behavior after PR:** This PR ensures that the toolbar remains in its normal state when a format is applied via the toolbar button. The corresponding format button (e.g., bold) is correctly highlighted. task-5123317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229454
This update stops the same invoice from being settled more than once in Point of Sale. It helps avoid duplicate customer account entries and keeps the settlement process accurate, while also preserving the selected customer if an attempt fails.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971)
This update prevents archived reconciliation rules from showing up when users match bank transactions. It helps keep the list clean and reduces the chance of selecting outdated rules by mistake.
Original PR description
Steps to reproduce: ------------------- 1. Install Accounting (with demo data). 2. Go to Accounting > Dashboard and open the "Bank" journal. 3. Click on any unreconciled line and open the dropdown menu. 4. Select “Manage models” and archive one of the reconcile models. 5. Return to the bank journal and open any unreconciled line. Issue: ------- Archived reconcile models are still shown in the available model list. Cause: ------ The [SQL query](https://github.com/odoo/enterprise/blob/6615de3100ac1192039a5f276df278c543f2fabb/account_accountant/models/account_reconcile_model.py#L47-L118 ) does not filter out inactive reconcile models. Solution: ---------- Add a condition to include only active models. opw-5189700
This change prevents an error when sending a credit or debit note to Uruguay’s tax authority if the original invoice is not a valid electronic document. Instead of failing with a server traceback, Odoo now shows a clear message so the user can correct the issue before resending. This improves reliability and makes the process easier to complete successfully.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770
Forward-Port-Of: odoo/enterprise#90281This fix improves the spreadsheet version history view by avoiding an unnecessary company currency request. As a result, the view should open more efficiently and with less backend processing, especially in cases where this action is used frequently.
Original PR description
The perfomance commit added in https://github.com/odoo/odoo/pull/151725 did not account for the version history action that does not inherit from `AbstractSpreadsheetAction`. this missing value trickled down to a bug only detectable in the VersionHistory action and which is addressed in https://github.com/odoo/odoo/pull/232985 This commit adds the same performance to VersionHistory action. Task-5187293 Forward-Port-Of: odoo/enterprise#98197 Forward-Port-Of: odoo/enterprise#98038
Fixed an issue where the image toolbar would not appear if the editor had lost focus, even though the user’s selection was still relevant. This makes image editing behave more reliably when switching between elements on the page.
Original PR description
Description of the issue: - The image toolbar failed to open when the editable had lost focus. - Previously, `focusEditable()` exited early if the active element was inside the editable, even when the actual document selection wasn’t. Solution: - Updated the condition in `focusEditable()` to also check whether the document selection is inside the editable. - Now it only returns early when both the active element and the selection are within the editable. task-5117272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230549
This fix prevents the delivery date from being unintentionally changed when an invoice is confirmed after adjusting the delivery. It helps ensure sales and accounting documents stay consistent, avoiding confusion and rework for users.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable anglo-saxon accounting; 2. have a product category with automated AVCO; 3. assign category to a deliverable product; 4. set product to invoice on…
Versions
--------
- 17.0+
Steps
-----
1. Enable anglo-saxon accounting;
2. have a product category with automated AVCO;
3. assign category to a deliverable product;
4. set product to invoice on delivery;
5. add product to a sales order;
6. confirm order & delivery;
7. create invoice;
8. change the delivery on the invoice;
7. confirm the invoice.
Issue
-----
The delivery date gets reset.
Cause
-----
Commit 818cf04f05767 added `delivery_date` as a permanently protected field when modifying moves or move lines, protecting the records on `write`. With anglo-saxon accounting however, new move lines are created when confirming an invoice, which in turn recalculate the delivery date, as `_get_protected_vals` isn't used for their move on `create`.
Solution
--------
Add `self.env['account.move'].protecting(_get_protected_vals({}, moves))` when creating new lines for a move, to avoid recomputing fields that should always be protected.
opw-4965036
Forward-Port-Of: odoo/odoo#231186This fix removes a hardcoded 30-day assumption when calculating the minimum rental period on the website. As a result, customers can now correctly select rental dates in shorter months like February without being blocked by an incorrect end-date limit.
Original PR description
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting,…
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting, set `Minimum Rental Duration` to 1 month. 3- Create a rental product and from website, choose the date: - 01/02/2026 - 28/02/2026 4- This fails. The earliest end date it accepts is 03/03/2026. Cause: This is due to hardcoded 30 days: https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L7-L12 https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L47-L53 We can use luxon plus method instead. ```diff + const minEndDate = startDate.plus(Object.fromEntries([[unit, duration]])); ``` In all usages of `msecPerUnit` we can do the same. Also we can keep remove `msecPerUnit` from master. opw-5094534 Forward-Port-Of: odoo/enterprise#98828 Forward-Port-Of: odoo/enterprise#98168
Orders are now synchronized one at a time instead of in large batches. This reduces the risk of timeouts and synchronization errors, helping prevent lost or partially processed orders, including orders that need invoicing. The loyalty flow was also adjusted so coupon programs are confirmed correctly for each order.
Original PR description
`syncAllOrders` method is now splitting the list of orders to synchronize them one by one. This allows to have better control over each order synchronization and error handling. Some customer were experiencing issues when synchronizing too many orders at once, leading to lost orders or orders not being synchronized properly. For example, synchronizing orders that needs to be invoiced takes too long and can lead to timeout issues. By synchronizing orders one by one, we ensure that each order is properly synchronized before moving to the next one. --- Modification in `pos_loyalty` module to adapt to this change: The `confirm_coupon_programs` method is now called for each order individually, instead of being called once for all orders in the `payment_screen`. This ensures that coupon programs are confirmed correctly for each order even when orders synchronization is delayed Forward-Port-Of: odoo/odoo#232691 Forward-Port-Of: odoo/odoo#232073
This update corrects a linting check so that indexed relationships are properly recognized even when they come from inherited data models. It helps prevent missed indexing warnings, improving database performance checks and code quality.
Original PR description
Many2one fields that originated from an `inherits` model were not linted for indexing if they were an inverse to a One2many field, because those fields on the inverse model have `store=False`. The Many2one field that needs to be indexed is the one on the delegated model. This commit fixes this by always getting the `base_field` for the inverse field - if it's an inherited field, it will use the source field; if not, it will use the field itself. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents point of sale orders from getting stuck when the connection to the blackbox is unavailable during synchronization. If an order cannot be signed because the system is offline, it is returned to draft so the cashier can try again once the connection is restored.
Original PR description
When trying to sync orders while being offline, a `ConnectionLostError` is raised. This error was not handled in the pos_blackbox_be module. Now, if an order was not signed correctly by the blackbox, we put its state back to "draft", allowing the cashier to retry later (when the connection to bbox is re-established).