Monday, September 15, 2025
29 changes · saas-18.4
Enhancements to existing features
The Argentina electronic invoicing module now includes renewed demo and testing certificates needed to connect to ARCA's test services. This prevents test invoicing processes from failing due to expired certificates and keeps validation environments available.
Original PR description
Homologation certificates are required to connect Odoo with ARCA's test web services. When they expire, electronic invoicing tests fail, displaying a “Digital certificate expired” warning. In this PR, I'm updating the certificates so we can continue using the testing environment for our tests. Odoo Task 1359 Adhoc Task 57144 Forward-Port-Of: odoo/enterprise#94128
Documents and items in the trash now use their creation date as the default sort order. This keeps lists more stable, since small edits such as adding tags or renaming items no longer move older documents to the top.
Original PR description
As the write_date can be reset by very small changes like adding a tag, updating its name and also during some upgrade, we set the default ordering to create_date. We do similarly for the trash. Task-5025453 Forward-Port-Of: odoo/enterprise#93952 Forward-Port-Of: odoo/enterprise#92840
Improved translations for Spanish Latin American language for some terms in MX localization task-4938338 target: 17.0 -> master Forward-Port-Of: odoo/enterprise#93603 Forward-Port-Of: odoo/enterprise#91875
Original PR description
Improved translations for Spanish Latin American language for some terms in MX localization task-4938338 target: 17.0 -> master Forward-Port-Of: odoo/enterprise#93603 Forward-Port-Of: odoo/enterprise#91875
Resolved issues and error corrections
The website editor now shows the correct size when users choose the Small text option in a banner. This fixes a visual mismatch so content editors can rely on the displayed font size matching the intended design.
Original PR description
Steps to reproduce: 1. Drop a Banner snippet 2. Select the text and change the size to "Small" - The font size is shown as 16px instead of 14px Cause: The "Small" font size was calculated using `em`, while other sizes were calculated using `rem`. Fix: Use `rem` for the small font size as well, ensuring consistent calculation across all font sizes. | Before | After | |-----------------------------|---------------------------------| | <img width="545" height="604" alt="image" src="https://github.com/user-attachments/assets/0f6b754c-e010-490f-aac1-ee0b9ba80d72" />| <img width="545" height="613" alt="image" src="https://github.com/user-attachments/assets/0ee4c756-965e-48c5-8764-3085b49a3c48" /> |
This fixes a small rounding issue in the HTML editor when converting CSS size values between units. Values entered by users are now preserved more accurately after saving, reducing unexpected tiny changes in layout settings.
Original PR description
Before this commit: The generic CSS unit converter was rounding intermediate values to three decimal places, which caused a slight discrepancy when converting values back and forth between units. As a result, the values shown upon saving differed from the originally entered values. For example, converting 19px yielded 1.188rem, which then converted back to 19.008px. After this commit: By increasing the rounding precision from three to five decimal places, round-trip conversions across all supported CSS units now maintain the expected values. For instance, 19px will convert to 1.18750rem and back to 19px. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now shows font size values as clean whole pixels after conversion, instead of small decimal drift such as 45.008 px. This avoids confusion for users adjusting theme settings and makes displayed design values match what they entered.
Original PR description
Steps to reproduce: - Go to Website > Edit - Open the Theme tab - Set the font size to 45 px - Notice the value changes to 45.008 Fix rounding drift in "Font size" inputs. Values are now displayed as whole px after rem > px conversion (e.g. 45 > 45 px instead of 45.008 px).
Payroll work entry processing no longer performs a multi-contract validation that is not applicable. This avoids unnecessary blocking or confusion in a scenario the system does not support.
Original PR description
The multi contract is not possible, so removed the check. task-5073952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The active mobile icon in the website editor now uses a clearer color again. This restores contrast so users can more easily see which mobile view option is selected.
Original PR description
The active state of the mobile icon lost sufficient contrast. This PR restores its previous color to improve visibility.
Barcode operation lines now show the correct product name in their descriptions. This helps warehouse users identify items more reliably during scanning and reduces confusion in stock handling.
Original PR description
Task-4901289
This fixes an issue where invoice attachments from reconciled accounting entries appeared in the regular chatter of related credit notes. Attachments from reconciled moves are now shown only in the bank reconciliation view, keeping standard accounting records cleaner and less confusing.
Original PR description
Problem --------- In odoo/enterprise#85991, attachments from reconciled moves were displayed in the chatter along side the moves' attachments. This change was meant to affect only the bank reco widget. However, its scope reached the standard accounting behavior. STEPS --------- 1. Have 'account' installed 2. Create a move 3. Confirm and create the PDF attachment from the Send&Print 4. Create a credit note from it 5. Confirm the credit note -> The 2 moves are now reconciled and the PDF of the invoice is shown in the chatter of the credit note Objective --------- Only show reconciled moves' attachments in the bank reco chatter. Solution --------- Add a context key that is added when the Bank Reco widget is created and remove it when it is deleted. opw-####### Forward-Port-Of: odoo/enterprise#94442
The Point of Sale now handles cases where no cashier user is available without showing an error. This prevents an unexpected crash and keeps checkout-related workflows running smoothly in that edge case.
Original PR description
When there is no user, you get a traceback when it tries to access user.id. As the code that call getCashierUserId handles the fact that a falsy value is returned, we return undefiened when there is no user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226821
This fixes how Uruguay electronic invoicing reads document numbers that begin with multiple letters. Businesses using these documents will get more accurate electronic document generation and validation, reducing errors in affected credit/debit note and vendor bill flows.
Original PR description
If UY EDI document has latam document number with more than one letter at the beggining, it is needed to take in consideration all the letters and not only the first one. Task Latam side: 1352 Task Adhoc side: 53173 Forward-Port-Of: odoo/enterprise#90696
Event invitation and attendee emails now use embedded image icons instead of web font icons that many email clients cannot show. This keeps location details and related links visible and avoids confusing duplicated or empty pin icons when editing or sending event emails.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed and also because some issues occur with the email editor. This commit replaces i tags with font awesome classes in mail by images. Task-5082165 Forward-Port-Of: odoo/odoo#226332
A small spelling mistake was corrected in the website image shape settings. This helps ensure animated image shape options are recognized consistently and avoids minor display or configuration issues.
Original PR description
Fix typo: change 'anmated' to 'animated' in image shape definitions.
The Website Editor setting for the Terms & Conditions block on shop product pages now behaves correctly. Businesses can hide or show this block as intended, giving them better control over storefront content without unwanted text appearing.
Original PR description
Steps: - Open Odoo 18. - Go to Website > Shop. - Open any product page. - Try toggling the `Terms and Conditions` option in the Website Editor. Issue: - The Terms & Conditions block was always rendered, even when the option was disabled in the editor. Solution: - Checking the terms and conditions views are active or not inside the t-call condition. Result: - The `Terms and Conditions` block only appears when the option is enabled in the Website Editor, and disappears when disabled. OPW: 5021380,4965779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from adding a log note when a Saudi e-invoicing validation error happens before any request is sent to ZATCA. It keeps invoice communication cleaner by logging only actual ZATCA responses, reducing misleading internal messages for users.
Original PR description
In a previous commit e90c35cde2a1f5de5d7bc4db7a525638ca3fab6e, we modified the logic of posting a log note when receiving a response from ZATCA to always log a note of the response. An issue occured because sometimes, Odoo raises user errors before sending a request to ZATCA, In which case, we do not need to log a note. Task-id: 5056724 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#226174 Forward-Port-Of: odoo/odoo#226036
Opening a spreadsheet-based quality step in Shop Floor now works without displaying a traceback. This prevents confusing error messages during manufacturing operations while keeping the spreadsheet step behavior unchanged.
Original PR description
To reproduce: - Make a new BOM for new product P, with 1 operation on assembly line 1 - Add a spreadsheet step to the operation - Make a MO for 1x P - Open shop floor, assembly line 1, click on the spreadsheet step Current behaviour: - The spreadsheet step opens correctly, but we get a traceback Expected behaviour: - The spreadsheet step opens correctly, no traceback task-4965313 Forward-Port-Of: odoo/enterprise#91505
Deleting a message that includes a link preview now also removes the related preview automatically. This prevents leftover previews from staying visible and avoids manual cleanup for users.
Original PR description
**Specifications:** - Ensure link preview is removed when deleting a message. **Purpose:** - Previously, deleting a message with a link preview did not remove the preview, requiring manual intervention. - This fix ensures that when a message containing a link preview is deleted, its associated preview is also removed automatically, improving user experience. task-4678962 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226826 Forward-Port-Of: odoo/odoo#204930
Event searches on the website now include event descriptions when showing the full results page, not just in the search dropdown. This ensures users who press Enter see the same relevant events they were previewed, reducing confusion and missed event registrations.
Original PR description
Purpose ======= Making sure that, when typing a search term, all the results displayed in the search bar dropdown are visible on the page when clicking Enter. Specification ============= Previously, the search bar dropdown was displaying all the events where the name or description matched the search term. However, when clicking Enter, only the events where the name matched were displayed on the page (the ones where only the description matched were ignored). Fixing the issue by considering the description in the event search options. Task-5039221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224414
This fixes calendar file exports for planning shifts that do not have an employee assigned. Shift times now use the correct fallback timezone, preventing calendar invitations from showing the wrong start or end time in cases without demo data.
Original PR description
The test `test_planning_ics_file_without_assigned_employee` failed when running without demo data because the slot timezone was `Europe/Brussels` while the employee timezone was `UTC`.
The previous code in the method `ics_datetime()` converted to the slot timezone and then relabeled it as the employee timezone with `.replace(tzinfo=...)`, which shifted the actual instant.
This change ensures that ICS datetimes are always converted using astimezone to a single target tz:
- employee tz if the slot is assigned,
- otherwise the current user tz or `UTC` as fallback.
The test was also updated to assert the correct fallback `UTC` values:
`DTSTART:20230602T080000Z`
`DTEND:20230602T170000Z`
[runbot-231213](https://runbot.odoo.com/odoo/error/231213)
Forward-Port-Of: odoo/enterprise#93692The spreadsheet app now forces a light appearance because dark mode is not yet supported there. This prevents mixed dark and light styling, giving users a more consistent and readable spreadsheet experience.
Original PR description
Spreadsheet doesn't support dark theme. This fixes some style where dark and light themes are mixed. Task: 5082593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226798
This fix ensures date, date-time, and date range fields can correctly accept a value set by the system, even when it matches the original value. This helps prevent forms from showing outdated typed input instead of the value enforced by business logic, improving reliability in user workflows.
Original PR description
This commit allows date (i.e. date, datetime & daterange) fields to apply a value from the props (e.g. coming from an `onchange`), even if that value is the same as the initial one. Before this commit, it was not possible due to the fact that the date service responsible for the reactivity of the field was updating the input in an incorrect order, causing the field to display the 'input' value, and not the one enforced by the props. Task 4978896 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#225920 Forward-Port-Of: odoo/odoo#225841
This fix prevents an error when users open the invoice lines form view in Studio before saving a new invoice. It improves the invoice customization experience by avoiding a crash in this specific unsaved invoice scenario.
Original PR description
Currently an error occurs when user opens form view for invoice lines using studio. **Steps to replicate:** * Install `accountant` and `web_studio` * Create new invoice but don't save > Open studio…
Currently an error occurs when user opens form view for invoice lines using studio. **Steps to replicate:** * Install `accountant` and `web_studio` * Create new invoice but don't save > Open studio view * Select Invoice Lines > Edit Form View > Error should occur in terminal `ValueError: Expected singleton: account.move()` **Root cause:** * This error occurs because an empty `account.move()` record is passed as `self` to `_prepare_product_base_line_for_taxes_computation` at [1], which expects only a single record. Since the invoice has not yet been created, the recordset is empty. This issue happens only in version `18.4`, not in `18.3` or earlier. The reason is that in `18.4`, compute method [2] is called when opening the form view, whereas in `18.3` it is not. When [2] is called, it sets the `display_type` to `product`, allowing the code to bypass the condition at [3]. In contrast, in `18.3`,since [2] is not called, `display_type` remains `False` despite the code being the same. **Solution:** * To achieve similar behavior as in version `18.3` and skip that line, modify the condition to include a check for `move_id`. [1]: https://github.com/odoo/odoo/blob/0706aaef3894bbee6eea62679a2d89a3ee316f7b/addons/account/models/account_move_line.py#L880 [2]: https://github.com/odoo/odoo/blob/0706aaef3894bbee6eea62679a2d89a3ee316f7b/addons/account/models/account_move_line.py#L485 [3]: https://github.com/odoo/odoo/blob/0706aaef3894bbee6eea62679a2d89a3ee316f7b/addons/account/models/account_move_line.py#L875 **Sentry-6766906181**
This fix aligns the sales down payment test with how Odoo actually updates down payment lines, using the invoice accounting date instead of the sales order creation date. This helps prevent false build failures and improves confidence that invoicing behavior is being validated correctly.
Original PR description
Because the test was asserting against the Sale Order creation date, while Odoo actually uses the invoice’s accounting date when updating the down-payment line. build_error-231505 Forward-Port-Of: odoo/odoo#224989
Receipt instructions now keep the product name when it is part of a longer description. This prevents important reception guidance from being accidentally shortened or made unclear for warehouse users.
Original PR description
Steps to reproduce: - Create a product - Set a description for receipts that uses the product name somewhere in the text - Create a reception for that product Issue: The product name will be removed from the reception instructions. The intended behavior was to avoid displaying the same information if the description was the same as the product's display_name. So we only check that now, rahter than do a replace in the description. Task-4901289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Barcode app now hides a product description when it simply repeats the product name. This reduces duplicate information on reception lines, making barcode operations clearer for warehouse users.
Original PR description
Steps to reproduce: - Create a product - Open the Barcode app - Create a new reception and add the product Issue: The description is displayed even though it's the same as the product name. Since in barcode we don't get the product's `display_name` with its code as they're treated separately, we need to reconstitute it to be sure it's not the same as the description in order to know if we want to display it or not. Task-4901289
This fix updates internal type definition files so recent changes in messaging, live chat, portal, HR, project, and website-related areas stay aligned. It helps developers maintain these features more reliably, with no expected direct change for end users.
Original PR description
* = hr, hr_holidays, im_livechat, portal, project, website_livechat, website_slides Many recent changes did not update d.ts files accordingly. https://github.com/odoo/enterprise/pull/94785
This fixes internal compatibility information for the Knowledge app after recent changes. It helps keep the app's messaging-related code aligned and reduces the risk of developer or integration issues, with no expected visible change for business users.
Original PR description
Recent changes did not update d.ts accordingly. https://github.com/odoo/odoo/pull/227232
The tax return process now checks whether a user can view the company, rather than whether they can edit company details. This prevents Bookkeeper users from being wrongly blocked while still keeping returns unavailable to users without company visibility.
Original PR description
Before:
When generating tax returns, the code checked for write access with `company.has_access('write')`. This could wrongly block users with Bookkeeper access right, who have the rights to generate returns but not to modify company records.
After:
The access check now uses `company.has_access('read')`, ensuring users with sufficient read access can generate returns while still preventing access for users without company visibility.