Daily updates from Odoo
Monday, October 27, 2025
77 changes
13 changes
Resolved issues and error corrections
This fixes an unstable automated test for the website builder sidebar behavior. It reduces false failures caused by timing issues, helping teams validate website changes more consistently without affecting customer-facing functionality.
Original PR description
Tour added in that [commit], was previously failing and the earlier [fix] only reduced the frequency of failures. However, it still occasionally fails due to race conditions of the iframe becoming ready and the moment the builder opens the block tab after the iframe has been reloaded. This commit aims to fix it. [commit]: odoo@a5455bf [fix]: https://github.com/odoo/odoo/commit/0a9522792cc0e18a895c0589f34977123d091d1a runbot-233438
This change adds a safeguard to ensure invoice PDFs show the correct product information when a line has an added description. It helps prevent a past issue where the product name could be omitted from printed invoices, improving invoice clarity for customers.
Original PR description
Issue: If a description is added on a product line, the printed invoice PDF only shows the description without the product name. Purpose of this PR: To add a test to ensure that the product description is correctly reflected on invoice PDF. Original issue was fixed by this PR: https://github.com/odoo/odoo/pull/222589 opw-4985815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French FEC imports now use a valid debit account for rounding differences after a chart of accounts change made the previous account code a grouping account. This prevents import issues and helps ensure accounting data is posted to the correct usable account.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
This fixes unreliable automated checks around two-factor authentication setup by making the test steps wait for clearer completion signals. The change helps reduce false failures in testing environments, improving confidence in releases without changing user-facing behavior.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
Corrects how Peppol verification status changes are logged for contacts. This ensures the system records the expected verification information even when multiple identifier checks are involved, improving traceability for electronic invoicing setup.
Original PR description
Failed fw-port in https://github.com/odoo/odoo/pull/231142. The logging won't happen if a value is found for the second tested EAS. task-none Forward-Port-Of: odoo/odoo#232900
Saving departure notes for archived employees no longer triggers an error. This prevents interruptions for HR users when maintaining employee records after departure.
Original PR description
Html fields are not part of the supported fields for tracking, see https://github.com/odoo/odoo/blob/11289fd128827587f6ed3fc5beed28f461c0e039/addons/mail/models/mail_tracking_value.py#L49 This causes a traceback when saving the `departure_description` on an archived employee. Added in https://github.com/odoo/odoo/commit/aa4d13b89b4497d2e5b33faa49ad86e0788782a2 Previous related fix: 9b723e2591224f2b563924d3b3dfe27ab909b7d0 opw-5140525
This fix prevents users from creating a new workplace directly from certain Swiss payroll forms when that shortcut could trigger an error. Users can still select existing workplaces, while avoiding a confusing failure during employee or contract setup.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#96675 Forward-Port-Of: odoo/enterprise#93424
This fix prevents messaging and live chat screens from breaking when a channel member is loaded without full profile details. The system now safely falls back to an existing “unnamed” label, keeping conversations accessible in flows where member identity details are not needed.
Original PR description
Sometimes, channel members are received without their partner/guest because it's not important in the flow. However, some part of the JS code assume the persona is always set, resulting in errors. This PR guards access to persona when computing the member name, a fallback to "unnamed" is already in place. task-5184408 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#233056
Payroll now checks the correct document template separately for each payslip. This prevents cases where one payslip's missing or different template could affect others, helping ensure payroll documents are generated with the right layout.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
German e-invoices now use the actual customer or parent company name when an invoice address has no contact name. This prevents labels like "Invoice Address" from appearing in XML invoice data when they are not shown on the customer-facing PDF.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format - For this contact, create an "Invoice Address" without "Contact Name" - Create an invoice with the invoice address as customer - Confirm the invoice - Generate "XRechnung" via "Send & Print" button **Issue:** In the generated ULB XML and in factur-x.xml file embedded in the PDF, the customer name contains the mention "Invoice Address", which doesn't appear on the PDF of the invoice. **Cause:** The used invoice address has no name, so its "display_name" is build from the name of the parent contact and the type of the child contact (i.e. Invoice Address). **Solution:** Only use "display_name" of a contact if "name" is set. Otherwise fall back on "display_name" of the commercial partner. opw-5159291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232819
Email Marketing templates using the showcase block now keep their separator styling after saving. This ensures recipients see emails as designed, improving visual consistency in campaigns.
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. Solution: Backport fix from `web_editor/convert_inline`: https://github.com/odoo/odoo/commit/7e3e6c1f42d97c2bb6830ed59dbec3a3b745d0c0 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#230773
Internal users who click the View Product button in product-related emails are now taken to the internal product page instead of the public shop page. This keeps staff workflows accurate while preserving the public shop redirect for portal and public users.
Original PR description
### Issue: Mail action redirects only to shop page, even though the user has internal access to the product page. #### To reproduce: 1- Create a db with website_sale installed. 2- Create a product and publish it. 3- In the product page chatter, send a message to an internal user 4- In received email, click on `View Product` button 5- As you see the shop page opens This is reproduced after #202555 Inside `_get_access_action`, if the product is published, we are returning `website_url`. We can add a check to do that only if user is portal or public. opw-5155281 Forward-Port-Of: odoo/odoo#233030 Forward-Port-Of: odoo/odoo#231961
Contact addresses now include the second street address line when generating the complete address. This ensures emails and other documents show the full address for contacts who use an additional address line.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
11 changes
Resolved issues and error corrections
The web interface no longer shows an incorrect timezone mismatch warning when a user's computer and profile use the same timezone with a 30- or 45-minute offset. This prevents unnecessary confusion for users in affected regions.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025 Forward-Port-Of: odoo/odoo#232813 Forward-Port-Of: odoo/odoo#230274
The French FEC import now uses a valid debit account for rounding differences after the previous account code became an account group. This prevents import issues and helps accounting data load correctly under the updated French chart of accounts.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
German e-invoice XML files now use the real customer or company name when an invoice address has no contact name. This prevents labels like "Invoice Address" from appearing in electronic invoice data and keeps it consistent with the PDF invoice.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format - For this contact, create an "Invoice Address" without "Contact Name" - Create an invoice with the invoice address as customer - Confirm the invoice - Generate "XRechnung" via "Send & Print" button **Issue:** In the generated ULB XML and in factur-x.xml file embedded in the PDF, the customer name contains the mention "Invoice Address", which doesn't appear on the PDF of the invoice. **Cause:** The used invoice address has no name, so its "display_name" is build from the name of the parent contact and the type of the child contact (i.e. Invoice Address). **Solution:** Only use "display_name" of a contact if "name" is set. Otherwise fall back on "display_name" of the commercial partner. opw-5159291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232819
This update makes automated checks for two-factor authentication setup more dependable by removing timing-sensitive steps. It reduces intermittent test failures under heavy load, helping keep development and release validation smoother without changing customer-facing behavior.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
Sale orders that use only fixed taxes no longer fail when read through XML-RPC integrations. This prevents export or integration errors by ensuring tax total values are returned in a format the system can safely transmit.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a fixed tax; 2. create a sale order using only the fixed tax; 3. read the sale order via XML-RPC. Issue ----- TypeError: cannot marshal None unless allow_none is enabled Cause ----- If only a fixed tax is used, the `_get_tax_totals_summary` method returns a dict where the `display_base_amount_currency` and `display_base_amount` values are `None`, leading to an error serializing the result. Solution -------- As the result gets serialized by `OdooMarshaller(allow_none=False)`[^1], we should use `False` instead of `None`. [^1]: https://github.com/odoo/odoo/blob/b887bf2/odoo/addons/base/controllers/rpc.py#L114 opw-5173477 Forward-Port-Of: odoo/odoo#232517
Draft sales orders now let users click product lines to edit the product or add a description instead of unexpectedly opening the product record. This reduces friction when updating quotes and prevents confusion during routine sales order edits.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Create a sales order; 2. add a product that doesn't have an extra description; 3. save & exit view; 4. go back to view; 5. add a description or change the product on the line. Issue ----- Clicking on the product field opens the product record instead of edit mode. Cause ----- It opens the product record because the `canOpen` property is set to `true`. As this is the default value, and isn't getting changed anywhere, the line will always open the product record outside of edit mode. Solution -------- Instead of using OR, check `props.canOpen` AND additional checks. opw-5172115
This change removes redundant database checks from mail link previews because existing required-field rules already cover them. It helps avoid restore problems when moving database dumps between PostgreSQL versions, though existing databases may still need cleanup before restore.
Original PR description
Same as #229274 these constraints are redundant with `required=True` and cause issues when restoring a dump from pg17 to pg18. And much like #229274 this only fixes databases going forward, on existing databases the constraints have to be dropped on the source.
This fixes an issue in Email Marketing where separators in the showcase email template could appear incorrectly after saving. Recipients should now see the intended email layout, helping campaigns look more polished and consistent.
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. Solution: Backport fix from `web_editor/convert_inline`: https://github.com/odoo/odoo/commit/7e3e6c1f42d97c2bb6830ed59dbec3a3b745d0c0 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#230773
Fixed an issue where internal users clicking a product link from an email were sent to the public shop page instead of the product record they can access. This helps staff reach the correct product page directly from email notifications while keeping public and portal users on the website view.
Original PR description
### Issue: Mail action redirects only to shop page, even though the user has internal access to the product page. #### To reproduce: 1- Create a db with website_sale installed. 2- Create a product and publish it. 3- In the product page chatter, send a message to an internal user 4- In received email, click on `View Product` button 5- As you see the shop page opens This is reproduced after #202555 Inside `_get_access_action`, if the product is published, we are returning `website_url`. We can add a check to do that only if user is portal or public. opw-5155281 Forward-Port-Of: odoo/odoo#233030 Forward-Port-Of: odoo/odoo#231961
This update fixes a failing automated test related to chat message bubbles in the Discuss area. It helps keep release validation stable without changing how users interact with the application.
Original PR description
Backport of fix https://github.com/odoo/odoo/pull/227445 Fixes runbot-error-233607 Forward-Port-Of: odoo/odoo#233243
The complete contact address now includes the second street address line when it is filled in. This ensures emails and templates using the full address show complete and accurate contact information.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
5 changes
Resolved issues and error corrections
The French FEC import now uses a valid debit account for rounding entries after a chart of accounts change made the previous account code a group rather than a usable account. This prevents import issues and helps accounting data load correctly for French companies.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
This update makes rental-related automated tests more reliable when demo data is not installed. It ensures the tests no longer depend on missing accounting or stock setup, reducing false failures in validation environments.
Original PR description
The test was failing in no-demo environments because it relied on accounting and stock configurations that were not present. When the test attempted to set property_valuation = 'real_time' on the product category, it triggered a ValidationError because the related stock accounts had not been properly set up for the test's transaction context. runbot-error-230417 Forward-Port-Of: odoo/enterprise#94182 Forward-Port-Of: odoo/enterprise#92292
This update adjusts internal performance tests to reflect an extra calendar lookup needed when employees have different work calendar types. It helps ensure payroll and appointment-related checks remain accurate without changing day-to-day user workflows.
Original PR description
- adjusted some query counters to account for the extra search in `_attendance_intervals_batch` done by the method `_get_calendar_at` task-id: 5065160 Forward-Port-Of: odoo/enterprise#96848
Belgian companies connecting to CodaBox can now use their company registry number when their VAT number is marked as not applicable. This prevents connection issues for non-taxable companies and keeps the setup flow consistent with companies that leave the VAT field empty.
Original PR description
If a company is not subject to taxes, they may not have a VAT number. In that case, the field can be left empty, such that the Company Registry is used instead for the CodaBox connection. However, the case where "/" (Non Applicable) was used as the VAT number was handled. This commit now handles VAT="/" in the same way it handles no VAT at all by using the company registry as a fallback. The commit also cleans up how the company ID is used to avoid duplicated code by creating a computed field. opw-5164155 Forward-Port-Of: odoo/enterprise#98025
The complete contact address now includes the second street address line when it is filled in. This ensures emails, templates, and other outputs using the complete address show the full customer or partner address correctly.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
7 changes
Resolved issues and error corrections
This update fixes inconsistent employee payroll fields and makes Australian payroll API tests independent from demo data. It helps keep payroll-related builds stable and reduces false failures during validation.
Original PR description
- Remove test dependency on demo data - Fix inconsistency on employee fields runbot-231643 runbot-230983 Forward-Port-Of: odoo/enterprise#96217
The EC Sales report now correctly shows the Code filter, making it easier for users to narrow report results as intended. This fixes a configuration placement issue so the report behavior matches the expected experience in newer versions.
Original PR description
Before: EC Sales report Code filter was not visible. As custom_display_config options was defined in the generic ec sales list code inside function `_custom_options_initializer` while it should actually be placed inside `_init_core_custom_options`. After: Like 18.4 now EC Sales report Code filter visible task-5109538 Forward-Port-Of: odoo/enterprise#96028
This update adjusts Odoo Enterprise unit tests to match recent changes in the Hoot testing framework. It helps keep automated testing reliable while limiting changes to test code, reducing risk to business features.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/232536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#98075 Forward-Port-Of: odoo/enterprise#97851
When users transfer a VoIP call, the contact search box is now cleared instead of showing the previous search. This prevents confusion and makes the call transfer flow cleaner for users.
Original PR description
**Purpose:** Previously, when a contact was searched and made a call. During a call, clicking "Transfer" showed the old search term. **Specification:** Now, the search box is explicitly emptied when transferring the call by resetting this.softphone.addressBook.searchInputValue. **Task-** 5087938 Forward-Port-Of: odoo/enterprise#98016 Forward-Port-Of: odoo/enterprise#95102
This fix ensures each payslip uses the correct template, even when no template is available in some cases. It helps prevent payroll document generation from applying the wrong template across multiple payslips.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
A typo was corrected in Odoo Studio's list of new field options, changing “Multine” to “Multiline.” This improves clarity for users when creating or editing fields, with no change to functionality.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97771 Forward-Port-Of: odoo/enterprise#97713
The complete contact address now includes the second street address line when it is filled in. This ensures email templates and other uses of the full address show all relevant address details, reducing incomplete or unclear customer communications.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
22 changes
Resolved issues and error corrections
This fixes a crash that occurred when users expanded a Spanish VeriFactu document view. The unnecessary message panel was removed because this document type does not support it, making the view open reliably.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231739 Forward-Port-Of: odoo/odoo#231601
This update fixes visual glitches in list rows used for sections, subsections, and product lines. Users will see clearer section separation, fewer duplicate borders during drag-and-drop, and more consistent pricing and hover styling in accounting and sales screens.
Original PR description
If we drag a row, there is a double border bottom under the `.o_list_record_remove`. This is due to the selector removing the border bottom being applied only on `.o_data_cell` since it's not a data-cell. This PR apply it on the td instead to be more generic. Sections and subsection's design was updated in https://github.com/odoo/odoo/commit/520bb2ff8eb165e4a9389db6300192f9b4a05dfd but the differentiation was too light. It also introduces issue: - Double border on subsection on drag - Empty tr having the main section border - Tax Incl. prices not receiving price styling - Combo lines were animated on hover but they are not draggable - Fix section hover not being applied in the quotation templates - Avoid long section name being cropped too early - Focus-within state applying wrong color on even sections task-5125867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French FEC imports now use a valid debit account when handling rounding differences. This prevents import issues caused by a recent chart of accounts change where the previously used account became an account group rather than a usable account.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
The user preferences screen no longer shows an incorrect timezone mismatch warning when the computer and Odoo timezone match but use a half-hour or 45-minute offset. This prevents unnecessary confusion for users in regions with non-whole-hour timezones.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025 Forward-Port-Of: odoo/odoo#232813 Forward-Port-Of: odoo/odoo#230274
This fixes a migration problem that could occur when the Manufacturing Work Orders app had been removed. Quality checks now reference the correct quality control form, helping upgrades complete reliably without unnecessary module dependencies.
Original PR description
Before this commit: The view `quality_point_routing_view_form` from `mrp_workorder` was used as inherit_id in `quality_mrp`. When `mrp_workorder` was manually uninstalled, `quality_mrp` caused a…
Before this commit:
The view `quality_point_routing_view_form` from `mrp_workorder` was used as inherit_id in `quality_mrp`. When `mrp_workorder` was manually
uninstalled, `quality_mrp` caused a missing view reference while migration.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 559, in _tag_root
f(rec)
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 423, in _tag_record
f_val = self.id_get(f_ref, raise_if_not_found=nodeattr2bool(rec, 'forcecreate', True))
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 543, in id_get
return self.model_id_get(id_str, raise_if_not_found)[1]
File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 547, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_model.py", line 2232, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "/home/odoo/src/odoo/19.0/odoo/tools/cache.py", line 98, in lookup
return self.lookup(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/tools/cache.py", line 155, in lookup
value = self.method(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_model.py", line 2225, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: mrp_workorder.quality_point_routing_view_form
```
After this commit:
The inherited view is changed to use `quality_control.quality_point_view_form_inherit_quality_control` to avoid dependency on `mrp_workorder`.
OPW: [5112724](https://www.odoo.com/odoo/project/70/tasks/5112724)
Traceback group: https://upgrade.odoo.com/odoo/tbg/2174This fixes a crash that could occur when viewing an invoice preview while Stripe payments are enabled. The preview now selects the correct invoice frame, so users can reliably view invoices without interruption.
Original PR description
Before this commit: - when stripe is enabled, the invoiceHTMLEl is set to the stripe iframe instead of the invoice one leading to a crash. after this commit: - the invoice iframe is correctly retrieved by using it's ID. 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 fixes an issue where inventory shipping settings could not be saved after SMS text confirmation was turned off. The system now only requires an SMS confirmation template when SMS text confirmation is actually enabled, preventing unnecessary save errors.
Original PR description
Due to this [commit](https://github.com/odoo/odoo/commit/889848aa65b474c3f495e65b75409068b6ef172a), The field ```stock_sms_confirmation_template_id``` is visible only when…
Due to this [commit](https://github.com/odoo/odoo/commit/889848aa65b474c3f495e65b75409068b6ef172a), The field ```stock_sms_confirmation_template_id``` is visible only when ```stock_confirmation_type``` is set to sms and ```stock_text_confirmation``` is set to True. However, the field ```stock_sms_confirmation_template_id``` is marked as required whenever ```stock_confirmation_type``` is set to sms, regardless of whether ```stock_text_confirmation``` is enabled. As a result, when saving the record with ```stock_text_confirmation``` unchecked, the required field ```stock_sms_confirmation_template_id``` remains invisible and unset — which causes a missing required field error during record save. Steps to reproduce: [Video](https://drive.google.com/file/d/1cpL6ie2zSDgW5mYGqOH5h-CpzxppXzFi/view) 1. go to settings - inventory - shipping 2. check Text Confirmation , set stock_confirmation_type = sms 3. uncheck Text confirmation 4. save the changes - To fix this issue, need to just add condition of ```stock_text_confirmation``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures each payslip checks and uses its own available template instead of assuming one template applies to all payslips. This helps prevent payroll document generation issues when a template is unavailable or varies between payslips.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
The Barcode app now rounds the quantity shown on the fulfill button, avoiding confusing long decimal values when processing receipts with decimal quantities. This makes inventory scanning screens clearer and helps users trust the displayed quantities during warehouse operations.
Original PR description
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54)…
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54) and mark it as To Do. - Open the Barcode app, open the corresponding receipt, and click the Edit button. - Increment the number of scans several times until you notice too many decimal digits (if you choose 10.54, you can test with 3). **Cause** A floating-point precision error occurs in the getter [`quantityToFulfill`](https://github.com/odoo/enterprise/blob/4b08734124c3bc84f7d95d170b39e9909e20d66b/stock_barcode/static/src/widgets/digipad.js#L55C9-L55C50), which is rendered directly [in XML templates](https://github.com/odoo/enterprise/blob/e8063141b33a9a8aa51d1ce94a66af313b2c1c89/stock_barcode/static/src/widgets/digipad.xml#L20C25-L21C89) without rounding. **Solution** Round the displayed value in the `quantityToFulfill` getter in the same manner than in [barcode_model](https://github.com/odoo/enterprise/blob/d4e5b69c7ea87fba3f2a5204ed6939b97879e4a8/stock_barcode/static/src/models/barcode_model.js#L99-L103). opw-5039796 Forward-Port-Of: odoo/enterprise#97475
This fixes Odoo's web test tooling so custom mock server responses are returned exactly as intended instead of being repackaged. It helps keep automated tests more accurate and reduces false failures when teams test special response scenarios.
Original PR description
Before this commit, when an 'onRpc' handler would return a 'Response' object, it would still be wrapped in a JSON-RPC payload (under the 'result' key) if the "content-type" header specified that it was a JSON-RPC. However, if a 'Response' object is returned by the handler, it usually means that the response should be that object as-is, as it was created with the desired final parameters. This commit ensures that 'Response' values are returned as they are, instead of being wrapped in a JSON-RPC payload object. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232844 Forward-Port-Of: odoo/odoo#232614
A spelling mistake in the Web Studio field creation options was corrected from “Multine” to “Multiline.” This improves clarity for users configuring views and avoids confusion when selecting field types.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97771 Forward-Port-Of: odoo/enterprise#97713
This fixes a website shop test that could fail when multiple websites are configured with different domain settings. The change makes the test use the intended default website, improving reliability without changing customer-facing behavior.
Original PR description
Why? ==== -When a domain value is set, get_current_website may return a different website ID than the default one. In this case, the domain of the other website is False, causing a failure when trying to check if a boolean exists within a string. Fix === - Use directly the default website. runbot-233387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The checkout test for Ecuador address flows now waits until the page interaction is ready before moving to billing details. This helps avoid false failures in automated checks, improving confidence in website sales quality without changing customer-facing behavior.
Original PR description
This commit add wait for intreaction to be ready before moving to billing step which render billing container conditionally depending on toggle from interaction. runbot-231718
This fixes an issue where the showcase email template could lose or misrender its separator after saving in Email Marketing. Recipients should now see the intended visual layout, helping marketing emails look consistent and professional.
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. Solution: Backport fix from `web_editor/convert_inline`: https://github.com/odoo/odoo/commit/7e3e6c1f42d97c2bb6830ed59dbec3a3b745d0c0 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#232565 Forward-Port-Of: odoo/odoo#230773
The accounting settings no longer show the "Enable Auto Transfers" option because it pointed to an old module name and did not work when users tried to save it. Users who need this capability can still install the Account Transfers app directly, avoiding a confusing setting that appeared to do nothing.
Original PR description
### Steps to reproduce: - Install "account_accountant" - Go in the settings - Search for "Enable Auto Transfers", tick the option - Save - The option is not ticked ### Cause: This option is supposed to install the module for Account Transfers. The option field is called `module_account_auto_transfer`. It's supposed to install the module `account_auto_transfer`. But this module was [refactored in 19.0](https://github.com/odoo/enterprise/commit/77c248981c9e1ccbb5d4c88a0915a231f040df84) and renamed `account_transfer`. So the settings can't find the module to install, nothing happen, and the option stays the same. ### Solution: Hide the option in 19.0. To respect the stable, we cannot rename a stored field. This is not a very important loss, the users can install the module `account_transfer` directly from the Apps application. Give the variable the correct name (`module_account_transfer`) in master. opw-5149342
The Point of Sale automated test was adjusted to skip an unreliable closing step that often failed when many add-ons were installed. This reduces false failures in validation runs and helps teams get faster, more dependable feedback.
Original PR description
fix runbot error on generic pos tour runbot-233183
Email buttons for published products now send internal users to the product record they can access, instead of always opening the public shop page. This prevents confusion for staff using product chatter emails while keeping public and portal users on the website shop experience.
Original PR description
### Issue: Mail action redirects only to shop page, even though the user has internal access to the product page. #### To reproduce: 1- Create a db with website_sale installed. 2- Create a product and publish it. 3- In the product page chatter, send a message to an internal user 4- In received email, click on `View Product` button 5- As you see the shop page opens This is reproduced after #202555 Inside `_get_access_action`, if the product is published, we are returning `website_url`. We can add a check to do that only if user is portal or public. opw-5155281 Forward-Port-Of: odoo/odoo#233030 Forward-Port-Of: odoo/odoo#231961
This update makes automated tests for two-factor authentication more stable by removing timing-sensitive steps and waiting for clearer success signals. It helps reduce false test failures under heavy load, improving confidence in release validation without changing the user-facing feature.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
When an employee adds more of a lunch item they already have in their cart, Odoo now updates only the pending "To order" entry. Previously, already ordered lunch lines for the same product could be increased by mistake, which could lead to incorrect lunch quantities.
Original PR description
**Issue**
When a user has two instances of the same product in their lunch cart, one with state "To order" and one with state "Ordered", and places a new order for that product, both the "To order" and "Ordered" records have their quantity incremented. Only the "To order" record should be updated.
**Steps to Reproduce**
- Add two lunch orders for the same product: one with state "To order" and one with state "Ordered".
- Place a new order for the same product.
- Observe that both records ("To order" and "Ordered") have their quantity incremented.
**Root Cause and Changes Made**
The _find_matching_lines method does not restrict the search to orders with state "new" ("To order"). As a result, it returns all matching records for the product, regardless of their state. When update_quantity is called, it updates the quantity for all these records.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228712This fix prevents chat and live chat from failing when a channel member is missing profile details that are not needed for the current workflow. The system now safely falls back to an existing "unnamed" label, helping users continue conversations without interruptions.
Original PR description
Sometimes, channel members are received without their partner/guest because it's not important in the flow. However, some part of the JS code assume the persona is always set, resulting in errors. This PR guards access to persona when computing the member name, a fallback to "unnamed" is already in place. task-5184408 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#233134 Forward-Port-Of: odoo/odoo#233056
The complete contact address now includes the second street address line when it is filled in. This ensures email templates and other uses of the complete address show the full customer or partner address accurately.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
The Discuss meeting view now uses larger action buttons that better match the spacious video/avatar layout. This makes call controls easier to see and use during meetings, improving the overall user experience.
Original PR description
Buttons has same size as other discuss actions, which are sized for dense UI like discuss app with message list and composer + panels. In meeting view, the UI is essentially streams / avatar cards. Buttons below need to be sized accordingly, i.e. bigger, which this commit does. Part of Task-5190261 Before <img width="1281" height="899" alt="before" src="https://github.com/user-attachments/assets/3a808149-02c1-41de-b7ef-d2c7681f06c3" /> After <img width="1279" height="902" alt="after" src="https://github.com/user-attachments/assets/3a8e6ff8-6ab2-4d50-a71d-e435e63e28d1" />
11 changes
Resolved issues and error corrections
This fix makes an internal mail test less sensitive to timing delays when checking channel subscriptions. It helps prevent false failures in automated validation, improving release confidence without changing user-facing behavior.
Original PR description
Before this commit, the test was checking the channels that were subscribed to in the websocket by filtering on their name. This could cause a condition with the debounce of the update_channel in the websocket. Indeed, if waiting too much time (300 ms at the present) between the presences subscription and the channel subscription, the first one would yield an empty array of subscription since not a discuss channel subscription. This commit fixes the issue by just taking the subscription into account if any channel is in the list, otherwise we simply avoid the step in the test. fixes-runbot-161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230608
Companies without an applicable VAT number can now connect to CodaBox using their company registry number instead. This avoids connection issues for non-taxable Belgian companies that mark VAT as non-applicable.
Original PR description
If a company is not subject to taxes, they may not have a VAT number. In that case, the field can be left empty, such that the Company Registry is used instead for the CodaBox connection. However, the case where "/" (Non Applicable) was used as the VAT number was handled. This commit now handles VAT="/" in the same way it handles no VAT at all by using the company registry as a fallback. The commit also cleans up how the company ID is used to avoid duplicated code by creating a computed field. opw-5164155
Creating multiple accounting journals of the same type could fail when no alias domain was configured because Odoo reused the same generated alias. This fix makes the alias uniqueness check include aliases without a domain, preventing save errors and allowing users to create journals normally.
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
This update stabilizes an automated barcode test by ensuring the screen has finished updating before the test checks the result. It helps prevent false test failures in development pipelines without changing how users interact with barcode features.
Original PR description
This commit fixes a test that sometimes failed, because we didn't wait for an animationFrame after the macro was complete. As a consequence, there was no guarantee that the form view had been updated before the check. runbot error~226829 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 prevents an accounting process from failing when it encounters an empty value where a number is expected. It helps users continue their work without seeing a confusing error message.
Original PR description
Description of the issue/feature this PR addresses: ValueError: invalid literal for int() with base 10: '' Current behavior before PR: ValueError: invalid literal for int() with base 10: '' Desired behavior after PR is merged: not giving valueerror --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Missing translation in settings for "Configure Signature Certificates" in spanish Steps to reproduce: ------------------- * Install module l10n_mx * Switch to a Mexican Company * Go in setting/accouting -> Issue: "Configure Signature Certificates" is not translated. Observation: ------------ It's translated from 18.2+ https://github.com/odoo/enterprise/commit/8e14c5b9c43e109754e5411588d18b93b37335d6 opw-4942599
Original PR description
Missing translation in settings for "Configure Signature Certificates" in spanish Steps to reproduce: ------------------- * Install module l10n_mx * Switch to a Mexican Company * Go in setting/accouting -> Issue: "Configure Signature Certificates" is not translated. Observation: ------------ It's translated from 18.2+ https://github.com/odoo/enterprise/commit/8e14c5b9c43e109754e5411588d18b93b37335d6 opw-4942599
Website forms now handle field names that include the “|” character when setting conditional visibility rules. This prevents dependent fields from staying hidden incorrectly, helping form builders use flexible field labels without breaking form behavior.
Original PR description
Before this commit, after selecting a field containing the char "|" for conditional display, the field on which the condition is set will never appear again. This commit enable the use of any characters in form fields Steps to reproduce the bug: - Add a form - Add two fields (A and B) - Rename the field A with a string that contains "|" - Set the field B visibility to "Visible only if" - Set the field A as the visibility condition for field B (field B visible only if field A contains 'hello', for example) - Save the changes - Complete the field A according to the visibility condition (The second field does not appear) task-3893749
Fixes an issue where editing the “Terms and conditions” link on a product page could cause an error. The website editor now correctly handles color removal for links styled with special text classes, making this editing flow reliable for users.
Original PR description
Problem: On website > shop > product page, when trying to edit the link of "Terms and conditions", a traceback occurs. Cause: When applying changes on "Terms and conditions" in `shop/product`, `ColorPlugin.removeAllColor()` is called on the `a` element. Its color was applied by the `text-muted` class. This case in color removal was not properly handled. Solution: In `getFonts`, consider elements that have those special classes (e.g., `text-muted`) when processing color removal. Steps to reproduce: 1. Open website/shop. 2. Open any product page. 3. Open the editor. 4. Select the "Terms and conditions" text. 5. Click edit in the link popover. 6. Click apply. 7. Traceback occurs. opw-5130016 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale product grid now displays product cards more consistently on mobile devices. This prevents card sizing conflicts that could make the sales screen look uneven or harder to use.
Original PR description
This commit fixes an issue related to the `product card` which has an enforced `4 /3` aspect ratio. Currently, there are two different grid layouts in `point_of_sale` depending on the breakpoint. On…
This commit fixes an issue related to the `product card` which has an enforced `4 /3` aspect ratio. Currently, there are two different grid layouts in `point_of_sale` depending on the breakpoint. On Mobile, we use a `3 cols` layout with each col being the same size, which conflicts with the grid layout as it try to enforce a specific `width/height` on the element. On other devices, we use an `auto-fill` rule, which provides way more flexibility for items to grow, but even there the aspect-ratio is not working as the item is sized as the other grid items. To fix this issue, we remove the `aspect-ratio` property, which was not affecting the design of the item and rely on the default grid sizing behaviour, to prevent any issue. task-4965395 | 18.0 and above | This PR | |--------|--------| | <img width="391" height="844" alt="image" src="https://github.com/user-attachments/assets/a191bfcf-20f6-4621-832b-a40ed42c2358" /> | <img width="391" height="844" alt="image" src="https://github.com/user-attachments/assets/7f07000e-b0e5-411e-bce6-12a5072bb854" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sale product catalog now shows the discounted price for a single sale order line, instead of showing the original unit price. This prevents pricing confusion and keeps the catalog display aligned with the actual order total.
Original PR description
Description of the issue/feature this PR addresses: When using the product catalog in sale orders, if a sale order line has a discount applied via the `discount` field, the catalog displays the base…
Description of the issue/feature this PR addresses: When using the product catalog in sale orders, if a sale order line has a discount applied via the `discount` field, the catalog displays the base `price_unit` instead of the discounted price. This creates an inconsistency between what's shown in the catalog and the actual price in the order line. Current behavior before PR: - A sale order line with price_unit=120.00 and discount=15% shows subtotal=102.00 in the order - The product catalog shows price=120.00 (without discount applied) - This only happens when `len(self) == 1` in `_get_product_catalog_lines_data()` - The multi-line case (`elif self:`) correctly calculates the price using pricelist Desired behavior after PR is merged: - The product catalog should show price=102.00 (with discount applied) - Consistency between catalog price and order line subtotal - The discount field is properly considered in the price calculation for single lines - Behavior matches the multi-line case where pricelist correctly calculates discounted prices --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Contact complete addresses now include the second street address line when it is filled in. This ensures email templates and other uses of the complete address show the full mailing address, reducing omissions in customer communications.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
8 changes
Resolved issues and error corrections
The complete contact address now includes the second address line when it is filled in. This ensures emails, templates, and other business documents show the full address accurately.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218
This fixes invoice reports so Mexican fiscal regime information is not shown for companies outside Mexico, even when the Mexican localization is installed. It prevents irrelevant localization details from appearing on invoices and reduces confusion for non-Mexican businesses.
Original PR description
Fiscal regime is displayed in invoice when your company isn't from Mexican but the mexican localization is installed. Issue: https://www.odoo.com/es_ES/my/tasks/5169917 https://www.loom.com/share/040059ba1dd44af780597803416604e2?sid=e57f61d2-2b8b-4d04-8a6a-c29e565d497e MT-12162 @moduon Forward-Port-Of: odoo/enterprise#97370
If the external VAT validation service times out or has a temporary issue, Odoo no longer marks the VAT number as invalid. This prevents valid customer or supplier VAT statuses from being incorrectly cleared due to service outages rather than actual validation failures.
Original PR description
When an exception occurs during the VAT validation check, the field `vies_valid` is currently reset to False. This behavior don't seem correct because an error does not necessarily indicate that the VAT number is invalid, it may simply result from a timeout or a temporary issue on the VIES server. Therefore, this fix ensures that `vies_valid` is only updated based on a valid response from the VIES server and is no longer reset to False when an error occurs. opw-5148922
This update pins a supporting PDF barcode library to a known working version for the Chilean electronic invoicing module. It prevents failures caused by a newer library version having compatibility issues with image processing, helping keep document generation reliable.
Original PR description
The pdf417gen==0.7.1 library must be installed, since its latest version produces a problem with the PIL dependency ImportError: cannot import name 'Resampling' from 'PIL.Image
This fixes a compatibility issue in Peppol partner handling so it continues to work with the older requests library version supported by Odoo 17. It helps avoid failures in deployments using the standard dependency versions.
Original PR description
JSONDecodeError was added in requests 2.28 and odoo 17 should be compatible with requests 2.22 see https://github.com/odoo/odoo/blob/17.0/requirements.txt#L76 no-task
Repair order users can no longer enter a serial number on a new repair line before that line has been saved. This prevents the serial number from disappearing on save and helps ensure tracked products remain correctly assigned.
Original PR description
When creating a repair order, if you add a line and assign a serial number before saving the line, the serial number is removed when saving. Steps to reproduce: - Create a repair order and save it. - Add a repair line with a product tracked by serial number. - Without saving the repair order, add a serial number on the line. - Save the repair order. - You will notice that the serial number is no longer assigned to the repair line. This PR fixes the issue by making the serial number field read-only until the repair line is saved. opw-5156267
This update documents an unused website event speaker biography section so maintainers understand why it remains present in the stable version. It helps avoid confusion during future maintenance without changing how events appear or function for users.
Original PR description
Problem introduced at [1] (see [2]). In stable, this comments the code to explain the dead code presence. In master, that snippet will be removed, as nobody seemed to have missed him for 4+ major versions and its structure is not perfect (overflow hidden...). Thankfully it should not come with any compatibility issue as it was not associated with any JS/CSS). Maybe a new equivalent will be introduced in master later on. [1]: https://github.com/odoo/odoo/commit/b5c87d86cad1aa2b44f805da0b2d6635aeb85b96 [2]: https://github.com/odoo/odoo/pull/68644#discussion_r903721785 task-4084801
Spreadsheet version history now reuses company currency information more efficiently instead of making an extra server request. This fixes a version history issue and improves loading performance for users working with spreadsheets.
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