Thursday, October 9, 2025
30 changes · 19.0
Resolved issues and error corrections
Fixes an issue where Time Off list view header buttons, such as New Group, did not respond properly unless they were approve or refuse actions. This helps managers complete Time Off and allocation workflows from list, calendar, and Gantt views without blocked or ignored actions.
Original PR description
**Issue** When clicking header buttons other than approve/refuse in Time Off list view, the actions are not processed correctly. **Steps to Reproduce** 1. Navigate to Time Off > Management > Time Off or Allocations 2. Switch to List view 3. Click on New Group button 4. Action is not executed properly **Root Cause** Previously, handleViewButtonClick only processed approve/refuse actions and ignored other header button actions. Now, non-leave actions are correctly forwarded to the default handler. Task ID: 5062846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes Nuvei payment handling so customers who return from the payment page without completing payment are not blocked by missing notification data. It also validates amounts correctly for Nuvei methods such as Webpay that require whole-number amounts, improving successful payment processing.
Original PR description
Since https://github.com/odoo/odoo/pull/163860, all notifications from providers are checked to see that they have the correct currency and amount in their flow before processing the notification. However, this has two issues with Nuvei: 1. The process when a customer hits "Go back" on the payment page instead of paying does not send any notification data. As such trying to compare these values will not work. 2. Certain payment methods within Nuvei use different decimal precision than the currencies on odoo. Webpay must always be in whole values even for USD, as such, we need to pass the correct number of precision digits to the validation method otherwise Webpay will never be able to go through. opw-5108631 Forward-Port-Of: odoo/odoo#230159
This fixes Brazilian Avalara tax calculations for service invoices so discounts are not subtracted twice. Businesses using this localization should see more accurate tax amounts on discounted service lines, reducing billing and compliance discrepancies.
Original PR description
Confusingly, Avalara's service API already accounts for the discount in lineNetFigure, whereas their goods API does not. In <saas-18.4 this was handled by _l10n_br_get_line_total(), but it got lost in the big refactor in saas-18.4 [1]. [1] https://github.com/odoo/enterprise/pull/82623 opw-5147143 Forward-Port-Of: odoo/enterprise#96585
Fixed an issue where computing taxes on an invoice could fail when no external tax was found for a customer's ZIP code. The system now safely continues with empty manual tax data, helping users complete invoice tax calculations without interruption.
Original PR description
Currently, an error occurs when computing taxes for an invoice. **Error:** `KeyError: 'manual_tax_amounts'` **Cause:** When a user clicks the `Compute Tax` button, the system calculates the tax for…
Currently, an error occurs when computing taxes for an invoice.
**Error:**
`KeyError: 'manual_tax_amounts'`
**Cause:**
When a user clicks the `Compute Tax` button, the system calculates the tax for that invoice, including the `manual_tax_amount` [1]. However, if no tax is found for a given customer ZIP code, the `tax_values_list` becomes empty [2]. As a result, `manual_tax_amounts` in the base line also becomes empty.
Later, when the system tries to fetch the `manual_tax_amounts` key from extra_tax_data, it raises a KeyError [2], because the key no longer exists.
Additionally, the condition in [3] indicates that there is no guarantee that the `manual_tax_amounts` key will always be present in the base_line.
**FIX:**
This commit ensures that if the manual_tax_amounts key does not exist, an empty dictionary {} is used instead. This prevents the KeyError from occurring during tax computation.
[1]- https://github.com/odoo/enterprise/blob/b17b6b4e5ca3085d831fc763457496b5c5b639c5/account_external_tax/models/account_external_tax_mixin.py#L155-L163
[2]- https://github.com/odoo/enterprise/blob/a51aee8f6e8bce2aa699d3199d6723495464a762/account_external_tax/models/account_external_tax_mixin.py#L88
[3]- https://github.com/odoo/odoo/blob/241c170dbece8c1652db9ca1aa935b2106ede532/addons/account/models/account_tax.py#L1330
sentry-6919182805
Forward-Port-Of: odoo/enterprise#96401The Time Off screens now correctly process the New Group action from list, calendar, and Gantt views. This lets managers create grouped time off requests without the button failing or being ignored.
Original PR description
See https://github.com/odoo/odoo/pull/226574 **Issue** - When clicking header buttons other than approve/refuse in Time Off list view, the actions are not processed correctly. - Added New Group Time Off to calendar and gantt view **Steps to Reproduce** 1. Navigate to Time Off > Management > Time Off or Allocations 2. Switch to List view 3. Click on New Group button 4. Action is not executed properly **Root Cause** Previously, handleViewButtonClick only processed approve/refuse actions and ignored other header button actions. Now, non-leave actions are correctly forwarded to the default handler. Task ID: 5062846
The purchase reporting view now correctly includes purchase order lines for products that do not have a category. This restores the vendor On-time Rate graph so purchasing teams can assess vendor delivery performance even when product category data is missing.
Original PR description
**Steps to reproduce:** 1-Install the purchase_stock module. 2-Create a Purchase Order with a new vendor. 3-In the Purchase Order line, add a product without a category. 4-Confirm the order and…
**Steps to reproduce:** 1-Install the purchase_stock module. 2-Create a Purchase Order with a new vendor. 3-In the Purchase Order line, add a product without a category. 4-Confirm the order and validate the generated receipt. 5-In the vendor form view, click the On-time Rate smart button → no graph is visible. **Issue:** https://github.com/odoo/odoo/blob/77b3956ed5635d79ae8dc19423140dc6a10098f1/addons/purchase_stock/report/vendor_delay_report.py#L46-L50 ``` The On-time Rate graph is not displayed in the Vendor Delay report. ``` **Cause:** - From version 18.2, `categ_id` was removed as a required field. The report query still uses an inner join on `categ_id`, which excludes products without a category and prevents data from being generated. - Commit which make `categ_id` non require - https://github.com/odoo/odoo/pull/166323/commits/b039caecbeb04057fbccb1cc88d03a4946f88e8e **Solution:** - Replace the inner join with a left join so that products without a `categ_id` are also included in the report (with null values when the category is not set). **opw** - 4991367 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230388 Forward-Port-Of: odoo/odoo#225557
Vendor credit notes matched to purchase orders now show the correct positive quantity when reversing over-billed purchase lines. This helps avoid confusing refund quantities and supports more accurate purchase billing records.
Original PR description
Steps to reproduce:- - Create a Purchase Order with Product A(invoicing policy: received quantities) and Quantity 3. - Create Vendor Bill with Product A and Quantity 3 and match it with the PO. - Receive only 2 on PO. - Now on PO, Quantity: 3, Received:2, Billed:3 - Create a Vendor Credit Note for that partner, add an empty line and save. - Click on PO Matching at the top. - Select line from Vendor Credit Note and line from PO, click match. Problem: In Vendor Credit Note Quantity: -1 (which should be 1) Before this commit: When credit note values are prepared from purchase order, quantity to invoice on purchase order is set as quantity on credit note. After this commit: When credit note values are prepared from purchase order, inverse(-ve) of quantity to invoice on purchase order is set as quantity on credit note. task-4975200 Forward-Port-Of: odoo/odoo#230487 Forward-Port-Of: odoo/odoo#221203
Customer statement emails sent from child invoice contacts now include the correct PDF details instead of an empty attachment. The Customer Statement button is also hidden when there are no transactions or no amount due, reducing confusion for accounting users.
Original PR description
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and…
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and confirm it. 3. Go to the child contact and open the Customer Statement smart button. 4. Download the PDF → data is shown correctly. 5. Send the statement → the attachment in the sent mail is empty. **Issue:** - When sending customer statements via email from a child contact, the generated PDF attachment contains no data, showing empty amounts and transactions. - Additionally, the "Customer Statement" button was still visible even when the total due was zero. **Cause:** - The button visibility condition checks for `total_due == 0.0 and not has_moves`, which didn’t properly cover all use cases. **Solution:** - Update button visibility condition to: `invisible="not has_moves or total_due == 0"` ensuring it is hidden when there are no moves or the total due is zero. **opw-5009182** Forward-Port-Of: odoo/enterprise#95356 Forward-Port-Of: odoo/enterprise#93162
The AI assistant now handles incomplete grouped search requests more safely when the language model leaves out required grouping or summary fields. This prevents terminal errors and keeps the chat experience stable for users making business data queries.
Original PR description
Currently, an error occurs when no groupby property is found in LLM response while trying to search records through the AI agent in the chat. Steps to replicate: - Install ai_app and sale_management.…
Currently, an error occurs when no groupby property is found in LLM response
while trying to search records through the AI agent in the chat.
Steps to replicate:
- Install ai_app and sale_management.
- Setup gemini key.
- In the systray click on AI icon.
- Type in:
`read group in res partner`
or
`read group in partners groupby None`
- Error will occur in terminal.
(If the error doesnt occur the first time, spam the above given prompt.)
Error:
`ValueError: TypeError("'NoneType' object is not iterable") while evaluating
"ai['result'] = record._ai_tool_read_group(model_name, domain, groupby, aggregates, having, offset, limit, order)"`
Cause:
- As the LLM response didnt incude groupby it was passed on as None to the orm,
which caused the `'NoneType' object is not iterable` at the line [1].
- The groupby was set `None` through line [2], the loop sets every param that
is not in the instance as None i.e. Every value that is in `ai_tool_schema`
but not received in LLM response is set as `None`.
Solution:
- The method `_ai_tool_read_group` now safely handles cases where `groupby` or
`aggregates` (similar error occurs when aggregates is none at [3]) are None.
- Fields are assigned default values before calling the method `_read_group`.
[1]: https://github.com/odoo/odoo/blob/c034fed2eeb194961af7e1b3c60203141784acf2/odoo/orm/models.py#L1919
[2]: https://github.com/odoo/enterprise/blob/7e6fe07512b7d897cf6315d45e6a1004e48ef45e/ai/utils/tools_schema/validators.py#L51
[3]: https://github.com/odoo/odoo/blob/c034fed2eeb194961af7e1b3c60203141784acf2/odoo/orm/models.py#L1923
sentry-6912361256This fix ensures the correct domestic fiscal position is selected for several country localizations, which helps apply the right local taxes. It adjusts fiscal position ordering for the UAE, Mexico, and Cambodia, and removes a duplicate Italian domestic fiscal position that could cause incorrect selection.
Original PR description
Since the fiscal position sequence is used to determin the domestic fiscal position, and hence, the domestic taxes - it is important to properly sequence the fiscal positions. This commit fixes the…
Since the fiscal position sequence is used to determin the domestic fiscal position, and hence, the domestic taxes - it is important to properly sequence the fiscal positions. This commit fixes the following localizations: **AE** Sequences are added making Dubai the domestic fiscal position. However this needs to be improved to automatically prioritize the fiscal position based on the company's state. **IT** (l10n_it_edi_doi) An additional domestic fiscal position was mistakenly added. The correct domestic FP is defined in it's dependency module l10n_it. The duplicate FP is removed. **MX** Sequences are added **KH** Sequences are added No Task - l10n's identified by the fiscal position checks in `test_all_l10n` 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#230654
This fix ensures outgoing stock movements are properly included when Odoo calculates product quantities in strict mode. Businesses should see more accurate inventory availability figures in affected stock workflows.
Original PR description
### Issue: Commit ba54310a11d2b702753d4b9b028a62dd00a91467 has altered the location domain for quantities computations. However, the `dest_loc_domain_out` has not been correctly replaced: https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/addons/stock/models/product.py#L319 Since the returned value used to be negated and is not anymore. This results in out moves being ignored by the `_compute_quantities` in `strict` mode. opw-4997982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229734 Forward-Port-Of: odoo/odoo#229304
The Point of Sale customer details screen now shows only the information needed for checkout and related POS work. This reduces clutter for staff and helps avoid errors caused by back-office-only fields appearing in the POS interface.
Original PR description
Before this commit: ==================== The POS frontend used the main backend form view of res.partner, which displayed all partner details. Many of these fields and buttons were irrelevant for the POS and occasionally caused errors or tracebacks due to backend-specific features being exposed. After this commit: =================== The POS frontend now displays a simplified partner form with only the essential fields required for POS operations. Unnecessary backend details are hidden to improve usability and prevent potential errors. Task-5103953
Gantt group headers now keep the right size so they remain visible and aligned while users scroll. This prevents oversized headers from breaking the sticky behavior, especially on smaller mobile screens.
Original PR description
Gantt group headers could stop being sticky because their width was fixed based on the number and size of columns. Even though they were set to position: sticky, oversized headers could no longer remain aligned when scrolling, as they extended beyond the viewport and were constrained by the document width. This was especially noticeable on mobile, where group headers are often wider than the screen. The fix applies a max-width style to these headers, capping their size to the available space so they remain sticky without overflowing the document. task-4970992 Forward-Port-Of: odoo/enterprise#96612 Forward-Port-Of: odoo/enterprise#96015
This fix improves how Swiss payroll recalculates payslip issues, helping ensure payroll warnings and related checks stay accurate after changes. It reduces the risk of outdated or incorrect payslip information affecting payroll review and accounting workflows.
Original PR description
task-5150492
Adding a combo product to the online shop cart no longer fails when its related combo choice was deleted. This prevents shoppers from encountering an error at checkout and keeps the cart flow working for affected products.
Original PR description
Currently, an error occurs when a user adds a combo product to the cart. Steps to Reproduce [video](https://drive.google.com/file/d/1m-zxaIsrIzogeLun_Dj92Hb37-S9g9dO/view?usp=sharing): - Install the…
Currently, an error occurs when a user adds a combo product to the cart. Steps to Reproduce [video](https://drive.google.com/file/d/1m-zxaIsrIzogeLun_Dj92Hb37-S9g9dO/view?usp=sharing): - Install the `website_sale` module. - Create a product of type `combo` and add a `combo choice`. - Go to the `combo choices` and delete `that combo choice`. - Go to the `website` > `Shop` and add that product to the `cart`. `ValueError: min() arg is an empty sequence` This error occurs after this [commit](https://github.com/odoo/odoo/pull/198070/files), When user creates a combo product, adds its related combo choice, and then deletes that combo choice, adding the product to the cart causes the system to check the quantities of the order line [1]. Since there is no sale combo choice for that product, the combo line becomes empty and raises an error[2]. This commit ensures combo choice quantities are checked only if they exist. [1]- https://github.com/odoo/odoo/blob/df05ae6d9af6abdfd67c49ac7a4d01762472bfc3/addons/website_sale/controllers/cart.py#L189 [2]- https://github.com/odoo/odoo/blob/df05ae6d9af6abdfd67c49ac7a4d01762472bfc3/addons/website_sale/models/sale_order.py#L621 sentry-6924112987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Shared employee profile links that include private information now show a clearer access message instead of causing an error. Users are redirected to the public employee list, and extra checks help prevent similar permission issues from returning.
Original PR description
Sharing a link of an employee profile containing private info generated a traceback. Permissions had to be applied to the private field. I've also put a more explicit error message that allows the user to get redirected to the public employee list. I couldn't find a way to get the employee id from the url before the generic permission warning comes in. Thus I had to resort to redirecting to the general public employees list. Other tracebacks may happen each time a private field without the corresponding groups is put in the xml. Thus I added a test to prevent us from doing that again. Forward-Port-Of: odoo/odoo#230390 Forward-Port-Of: odoo/odoo#228623
Quality checks for serial-number tracked products now correctly stay failed when an item fails inspection during receipt processing. This prevents defective tracked items from being incorrectly marked as passed, improving inventory quality control accuracy.
Original PR description
Serial number tracked product are marked as pass even when they fail a move_line type of check. ### Steps to reproduce: * Create a product tracked by serial number * For this product create a control…
Serial number tracked product are marked as pass even when they fail a move_line type of check. ### Steps to reproduce: * Create a product tracked by serial number * For this product create a control point: - Control per quantity - Operations : Receipts * Create a receipt for this product * Mark the receipt as Todo * Start the Quality check from the receipt, without using the smart button. * Fail the Quality check * The Quality check still passes ### Issue: When validating a quality check and it fails: https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity opw-5015266 Forward-Port-Of: odoo/enterprise#92966
Fixed a survey issue where people who answered certain multiple-choice questions with a comment could still be told the question was unanswered. This improves survey completion reliability and adds safeguards to prevent invalid multiple answers on single-choice questions.
Original PR description
Issue: When answering a question with a comment in multiple choice with roaming activated for the survey, the UI will display a warning message that says the question requires an answer. Cause: The backend creates a skipped record if none of the pre-created answers is chosen. Solution: Don't create a skipped record if a comment counts as an answer and a comment is provided. Added validation of input and unittests Task-5062984 Forward-Port-Of: odoo/odoo#226022
Fast checkout could leave printed receipts empty, and in restaurant workflows it could cause an error when printing. This fix ensures the receipt screen uses the correct current order so customers receive complete receipts reliably.
Original PR description
pos*: pos_event_iot, l10n_it_pos Steps to reproduce: - Enable a one-click payment method. - Create and validate an order using fast validation. - On the receipt screen, print the order receipt. Issue: - The printed receipt is empty (no order details). - In restaurant mode, a traceback occurs when printing the receipt. Fix: - Use the receipt screen’s `currentOrder` reference instead of fetching the order directly from the POS instance. Task-5093060 Related: https://github.com/odoo/odoo/pull/227621
This fixes an issue where users working with Indian localization could not create a new company contact from a CRM lead when entering a GSTIN. The change prevents an invalid contact type from being used during PAN entity creation, allowing the contact save process to complete normally.
Original PR description
Currently, with Indian localization, creating a contact from a CRM lead raises an error. **Steps to Reproduce:** 1) Install CRM,l10n_in (with Demo) 2) Switch to IN Company 3) Navigate to CRM> Click…
Currently, with Indian localization, creating a contact from a CRM lead raises an error. **Steps to Reproduce:** 1) Install CRM,l10n_in (with Demo) 2) Switch to IN Company 3) Navigate to CRM> Click on 'New' 4) For **Contact** value click on 'Search more'>'New'. 'Create contact' wizard will open and set the following values >- Set contact as 'Company' >- Set 'GSTIN' (e.g 22AAFCH6738N1Z8) 5) Click Save Error: `ValueError: Wrong value for l10n_in.pan.entity.type: 'contact'` Root Cause: since [this commit](https://github.com/odoo/odoo/pull/214189/commits/c943637ef4aef740b97abaf1852ceb6fdfcd55bb), the field `l10n_in_pan_entity_id` at [1] was changed from `char` to `Many2one` which depends on the field `type` in the `l10n_in_pan_entity` as shown at [2]. Now following the above steps, the type of the partner is set as 'contact' from [3], which is not available at [2], raising an error. Fix: Updated the context value before creating a record for Pan Entity. [1]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/l10n_in/models/res_partner.py#L27-L35 [2]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/l10n_in/models/l10n_in_pan_entity.py#L15-L27 [3]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/crm/views/crm_lead_views.xml#L454 sentry-6916949666
Fast validation in Point of Sale now keeps the correct order linked to the receipt screen. This prevents empty printed receipts, restaurant printing errors, and unintended new orders in some checkout flows.
Original PR description
Steps to reproduce: - Enable a one-click payment method. - Create and validate an order using fast validation. - On the receipt screen, print the order receipt. Issue: - The printed receipt is empty (no order details). - In restaurant mode, a traceback occurs when printing the receipt. - In retail mode, an unwanted new order is created. Fix: - Prevent the creation of a new floating order during fast order validation. Task-5093060 Related: https://github.com/odoo/enterprise/pull/96695
This fixes a problem that prevented Mexican electronic invoices from being cancelled because the certificate key was sent in a format rejected by providers. Businesses using Mexican localization can now cancel CFDI invoices reliably again.
Original PR description
### Steps to reproduce 1. Install `l10n_mx_edi` with demo data 2. Switch to the ESCUELA KEMPER URGATE demo company 3. Create an invoice to the INMOBILARIA CVA demo partner 4. Send the invoice CFDI 5.…
### Steps to reproduce 1. Install `l10n_mx_edi` with demo data 2. Switch to the ESCUELA KEMPER URGATE demo company 3. Create an invoice to the INMOBILARIA CVA demo partner 4. Send the invoice CFDI 5. Request cancellation of the CFDI 6. The cancellation fails with the error 'invalid passphrase'. ### Analysis When calling `_finkok_cancel`, `_solfact_cancel`, or `_sw_cancel`, one of the API call parameters is the `pem_key` of the certificate given by the SAT. Before 19.0, the PEM key was in an unencrypted format. Since f88f8258ead, `env['certificate.key'].pem_key` is encrypted. According to Finkok's API documentation, the private key should be encrypted using DES when given as a SOAP parameter. https://wiki.finkok.com/home/webservices/ws_cancelacion/cancel However, in testing, encrypting the private key using DES seems to be rejected by Finkok. Solucion Factible and SwSapien don't indicate in their documentation whether and how the private key should be encrypted. ### Solution We send the private key unencrypted, as was already the case before 19.0. opw-5137549
Opening a single bank statement line in reconciliation now behaves more consistently: clearing the filter no longer expands every line, and the statement summary returns as expected. The update also hides an irrelevant statement creation button when only one line is shown and fixes an error when opening the general ledger from this view.
Original PR description
When you open a statement line from a reconciled move, it opens the bank reconciliation widget with only the selected statement line, which is unfolded by default. However, there are a few issues with this behavior, which are fixed in this commit: 1 - When entering the bank reconciliation widget, the initial line is unfolded. If you remove the filter, all the other lines become unfolded as well. This should not be the case; only the original line should remain unfolded. 2 - By default, the statement summary line is hidden. When the filter is removed, the summary remains hidden. We now ensure the summary is displayed again when the filter is cleared. 3 - The Statement button on the statement line (which is meant to create a new statement) doesn't make any sense when there is only one line. It is now hidden in this case. task-5108118 Forward-Port-Of: odoo/enterprise#95558
This fix adds the extra order details some Adyen payment methods need, such as country code and line items. It helps customers complete payments with options like Klarna instead of having transactions fail during processing.
Original PR description
Some payment methods eg. Klarna require 'country code' and 'line items' in order to process the transaction. opw-5077617 Forward-Port-Of: odoo/odoo#230292
This fix prevents Chrome on iOS from automatically changing certain text on Odoo pages in a way that could disrupt the web interface. It helps keep screens rendering correctly for users browsing Odoo from affected Chrome iOS versions.
Original PR description
Chrome iOS wraps some text nodes (like measures, email...) with a `<chrome_annotation>` tag, which breaks OWL rendering. This commit works around it by adding the (undocumented) `<meta name="chrome"…
Chrome iOS wraps some text nodes (like measures, email...) with a `<chrome_annotation>` tag, which breaks OWL rendering. This commit works around it by adding the (undocumented) `<meta name="chrome" content="nointentdetection">` tag to disable this Chrome behavior. The tag has to be set before the onDOMContentLoaded event to be taken into account. Note: Looks like this behavior was present in Chrome iOS 127 and disabled afterward (because it already had issues) but it appeared again in version 140-141. References: - https://issues.chromium.org/issues/353650041 - https://issues.chromium.org/issues/388718411 - https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags - https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile - https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an - https://github.com/solidjs/solid/issues/2235 opw-4969197 Forward-Port-Of: odoo/odoo#230081
This fixes an issue that prevented Viva payment webhook verification from finding the correct point-of-sale payment method. Businesses using Viva payments can now verify the webhook successfully and avoid related server errors during setup.
Original PR description
Steps to reproduce:
1. Configure a Viva payment method
2. Copy the webhook URL and attempt to configure it on viva.com
3. Click the 'Verify' button to confirm the webhook is functioning
EXPECTED BEHAVIOUR:
- The webhook verifies successfully
ACTUAL BEHAVIOUR:
- An error message is displayed, and the Odoo server also logs an error
In the commit cc60da3, an optimisation was added to domain searches that subtly changed the behaviour. In particular, in the case where a domain is written like such:
```python
env['pos.payment.method'].search([('company_id.id', '=', company_id)])
```
The `company_id` variable is no longer implicitly converted from `str` to `int`. In the `pos_viva_com` controller, we were relying on this conversion as the parameter is passed to the method as a string.
To fix this, we now explictly cast the variable to `int`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where employees could not edit personal information in the salary configurator when the website editing component was not installed. The change restores access to the underlying input fields, ensuring salary package configuration remains usable in affected setups.
Original PR description
Before this commit, when website was not installed (or more precisely html_builder), the salary configurator was not editable anymore due to ::before section that took the whole page. This was due to the changes made in https://github.com/odoo/odoo/pull/229554/. The style rule regarding relative positioned sections was move from html_editor to html_builder as this was a more website specific (or html_builder specific) rule. The fix should then be done in modules that used that rules but that does not depends on html_builder. The commit applies relative position to the personal info section ans force the ::before to let the pointer go through it to access underlying inputs. Task-5154145
This fix ensures recruitment offer simulations use the correct company when calculating available salary benefits. As a result, benefit values are properly updated instead of relying on the default first company.
Original PR description
in this commit, fixes issue when open simulation page
through recruitment offer values of benefits not updated.
issue:
get only default first company while triggering get
white list method.
task-4929771
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-prSalary simulation pages opened from recruitment offers now use the correct company context when loading benefit values. This prevents benefits from being shown with defaults from the wrong company, helping recruiters and candidates see accurate offer details.
Original PR description
in this commit, fixes issue when open simulation page through recruitment offer values of benefits not updated. issue: get only default first company while triggering get white list method. task-4929771
This change prevents certain template attributes from being automatically translated when they are used to pass internal website parameters. It avoids a server error when editing translations on pages such as the online shop, improving reliability for multilingual websites.
Original PR description
Scenario: enable second language on website, go to /shop, edit
translation => error 500 is shown with error:
SyntaxError: invalid syntax (<>, line 1)
Cause: since eb6e88a25050fff2bd09317739dd51ba451450df parameters are set
on the t-call tags, but this can conflict with attribute tag that are
translatable. In the case of /shop, there is:
<t t-call="website_sale.search" placeholder="placeholder"/>
that is transformed to:
<t t-call="website_sale.search"
placeholder="<span data-oe-model=...>placeholder</span>"/>
but this is an invalid value, t-call attribute should only be translated
if they have the suffix .translate and should not be auto-translated.
opw-5121074