Tuesday, July 14, 2026
28 changes · saas-19.2
New functionality added to Odoo
This pull request updates the Odoo localization files to include translations for the 'payment_payu' feature. This addition allows Odoo users to integrate with PayU, a popular payment gateway, expanding payment options for their business. It’s a standard I18N update to support new functionality.
Original PR description
Forward-Port-Of: odoo/odoo#275865
Enhancements to existing features
Signature requests started from other apps now include the template name alongside the related record name. This makes request names, file names, and email subjects easier to recognize and less likely to be confused with the signer's name.
Original PR description
When requesting a signature from another app, the request name, filename and email subject only showed the linked record name, which often read as the signer's name. The template name is now added so all three follow the same "<prefix> - <template> - <record>" format. task-6317174 Forward-Port-Of: odoo/enterprise#122963
Resolved issues and error corrections
The AI-powered SEO autofill now generates page metadata in the website page's language instead of the user's account language. This helps multilingual websites produce correctly localized SEO titles and descriptions, improving consistency for visitors and search engines.
Original PR description
The SEO "Fill with AI" autofill used the user's language for generation. On a website whose language differs from the user's, the generated seo metadata was therefore in the wrong language. This commit fixes this by using the page language instead. Forward-Port-Of: odoo/enterprise#123447
The Sendcloud delivery settings now use the term “Use Multicollo” instead of “Use Batch Shipping.” This aligns Odoo’s wording with Sendcloud’s terminology, reducing confusion for users configuring multi-package shipments.
Original PR description
In order to avoid confusion for the customer, "Use Batch Shipping" was renamed to "Use Multicollo".This way it is consistent with the terminology used by Sendcloud. task-6048477 Forward-Port-Of: odoo/enterprise#122920 Forward-Port-Of: odoo/enterprise#122133
This update adds the Belgian CODA extension number entry to the translation configuration. It helps ensure this module can be properly handled by the translation system, with no expected change for day-to-day users.
Original PR description
This commit will add l10n_be_coda_extension_number in the weblate json file. no task id Forward-Port-Of: odoo/enterprise#124053
This update makes the database authentication module available for translation work, helping improve localization for users in different languages. It also corrects minor wording issues and cleans up an internal error handling case that was not reachable from the user interface.
Original PR description
The aim of this commit is to allow the translator to work on this module translation and fix a typo that was made. Task-id: None Forward-Port-Of: odoo/enterprise#124038
Obox modules are now included in the translation setup, so their user-facing text can be translated. This helps users in different languages get a localized experience instead of seeing untranslated labels.
Original PR description
When the Obox modules were added in odoo/enterprise#110834 they were not also added to `.weblate.json`, meaning they will not be translated. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#124025
Printing an appraisal form from the action menu no longer includes the open menu in the printed document. The print action now waits briefly so the menu can close first, producing cleaner and more professional appraisal printouts.
Original PR description
When printing the appraisal form from the action (cog) menu, the drop down menu itself was incorrectly showing up in the printed document. This happened because the browser started printing immediately before the menu had time to close. By adding a small delay before triggering the print action, the menu now has time to completely close, so it no longer appears in the final print. task-6369240 Forward-Port-Of: odoo/enterprise#123242
Sendcloud shipping labels now correctly handle delivery address numbers that include a dot, such as 12.345. This prevents incomplete house numbers from being sent to Sendcloud and helps avoid incorrect label formatting for affected deliveries.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123820 Forward-Port-Of: odoo/enterprise#123266
Signature certificates now show the actual applicant email used during recruitment offer signing instead of a placeholder address. This prevents confusing or incorrect audit records when applicants are not yet linked to user accounts.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#123998 Forward-Port-Of: odoo/enterprise#123767
Belgian payroll contract templates now carry over three previously missing fields when creating contract versions. Simulation versions are also prevented from triggering Dimona-related actions, helping avoid unintended administrative reporting during testing.
Original PR description
Three fields were missing in the copying process from the contract template
This fix prevents an error when opening Dimona information for Belgian payroll records if an employee's private street address is missing. It helps HR users continue their workflow without being blocked by a technical traceback.
Original PR description
action_open_dimona guards on `self.employee_id.private_street` but then runs re.findall on `self.private_street`
This fix updates an internal payroll test so it uses its own employee data instead of reusing an existing sample employee with unrelated payroll values. It helps ensure Indian payroll percentage calculations are validated consistently without changing actual payroll behavior for users.
Original PR description
Use a dedicated employee/version for the percentage computation test instead of Rahul, whose existing payroll values affect copied version data. Define the test amounts in common and reuse `employee.version_id` in the test, so percentages are derived from amounts without changing payroll behavior. task-6340923 Forward-Port-Of: odoo/enterprise#122883 Forward-Port-Of: odoo/enterprise#121918
Worldline payment terminal receipts are no longer inserted into the Point of Sale customer receipt. This keeps POS receipts clearer and avoids showing unnecessary duplicate terminal details to customers.
Original PR description
This PR removes the terminal receipt from Worldline we are currently inserting in the Point Of Sale receipt We don't adapt the driver code to get the receipt as we cannot change C method prototypes task-6373975 Forward-Port-Of: odoo/enterprise#123770
This update removes a reference to a payroll user group that does not exist in the Belgian payroll fleet module. It prevents configuration errors and keeps field access rules aligned with available user roles.
Original PR description
The group hr_group_user does not exist and shouldn't be linked to these fields. task-6369268 Forward-Port-Of: odoo/enterprise#123238
This update corrects an issue where the customer's address wasn't displayed on the left side of invoices when using specific layouts. Previously, the address was incorrectly positioned on the right. This change ensures invoices consistently display the customer's address in the desired location, improving invoice presentation.
Original PR description
Issue: On an invoice PDF, using a layout with the address on the left. If a contact has a delivery address, but the option "Customer address" is not set, address will be displayed on the right instead of the left. Steps to reproduce: - Create a customer - Add a Delivery address to the customer - Ensure "Customer Address" is not set in the settings - Choose a layout with the address on the left (bubble, wave, ...) - Create an invoice to the customer - print the PDF Current behavior: - Customer address is on the right Expected behavior: - Customer address is on the left Cause: Address is displayed on the right if there is an information bloc . The information bloc was set to an empty div. Therefore, as it is set, address was displayed on the right. opw-6334130 Forward-Port-Of: odoo/odoo#273418
This update fixes a problem where the order tour would intermittently fail to load correctly, particularly when a message was pinned. The fix ensures the tour waits for the pinned message to fully scroll before attempting to navigate, preventing a race condition that caused timeouts.
Original PR description
Jumping to the pinned message highlights it and asynchronously scrolls it into view. On a slow browser that scroll can land right after the tour scrolls to the bottom and pull the thread back up to the pinned message. The load-newer observer callback, which awaits the highlight scroll before re-checking visibility, then finds the bottom sentinel hidden and drops the fetch of the following messages, so the final :count(60) step never matches and times out. Wait for the pinned message to be scrolled into view and for its highlight to clear (its scroll is then finished) before scrolling to the bottom, so the jump scroll no longer competes. https://runbot.odoo.com/odoo/error/941509 Forward-Port-Of: odoo/odoo#275289
This update resolves a bug where changing the website logo option (image to text) didn't consistently hide the logo. The fix ensures the logo is correctly hidden when the 'Company Logo' option is toggled, improving the user experience. This was caused by a configuration issue that has now been corrected.
Original PR description
Steps to reproduce: - Enter in edit mode - Click on the navbar logo - Change "Logo" option from "Image" to "Text" - Toggle "Company Logo" in "Visuals" option - Traceback appears: it should hide the logo This commit awaits `loadConfigKey` so `websiteLogoParams` reads the loaded config; otherwise the button targeted the wrong brand view and collided on the `#o_fake_navbar_brand` xpath. task-6284593 Forward-Port-Of: odoo/odoo#275363
A recent test failure in our holiday accrual system was caused by an incorrect calculation of holiday allocations in 2027 builds. This update adds a temporary fix to ensure the date remains consistent, preventing the over-allocation of holiday days. This ensures accurate holiday accrual calculations moving forward.
Original PR description
Problem ------------------------ test_department_accrual_allocation was failing due to the allocation being calculated as 26 days instead of 21 in faketime builds set to 2027. This was because the accrual plan was set to accrue 21 days per year and carry over 5 days from the previous year. Since the allocation was created on Jan 1st 2026, all 2027 builds were calculating the allocation to have 5 extra days. Solution ---------------------- Added freeze_time for 2026-03-01 to ensure the date stays the same. runbot-939344 task-6344033 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#274154 Forward-Port-Of: odoo/odoo#272728
This update resolves a technical problem within the mass mailing module that was causing errors to appear even when the component was already finished. This fix ensures smoother operation and prevents potential disruptions to email campaigns.
Original PR description
Commit [1] introduced an erroneous `!` operator before status, that would throw loading errors even if the component was already destroyed (those errors should be masked). [1]: https://github.com/odoo/odoo/commit/51c7846f99eb061a1d71ca5d9967f5b01f5551a1 Forward-Port-Of: odoo/odoo#275785
This update resolves an issue where triple-clicking within inline editable content in the HTML editor caused the selection to extend beyond the intended area. The fix ensures that triple-clicks accurately select and highlight the intended editable content, improving the user experience.
Original PR description
Problem: Triple-clicking inside an inline `contenteditable="true"` element causes the selection to extend outside of it. Cause: Inline `contenteditable="true"` elements are not considered when looking for the closest block boundary, allowing the browser selection to expand beyond the editable content. Solution: Treat `contenteditable="true"` elements as block boundaries when searching for the closest block. Steps to reproduce: - Add an inline `contenteditable="true"` element inside an editable area. - Triple-click inside it. - Observe that content outside the `contenteditable` element is also selected. task-6255094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267487
This update resolves an issue where Chrome was incorrectly suggesting previously filled values in selection fields. The change prevents the browser from offering autocomplete suggestions, ensuring a cleaner and more predictable user experience when creating new records. This improves data entry consistency and reduces potential user confusion.
Original PR description
Chrome keeps suggesting autocompletion on empty selection field. https://github.com/odoo/odoo/commit/5e7bc4ab851dba3d2e0b965f69e06cfeacec5674 is the commit introducing `autocomplete="selectMenuAutocompleteOff"` and I don't know why this value has been chosen but Chrome seem to consider this token as invalid Steps to reproduce: - Put a selection field on a form view with Studio - Create a record, complete the selection field and save - Create a new record and click on the selection field Current Behaviour: Chrome keeps suggesting the previously filled values Desired Behaviour: No autocomplete from the browser. Forward-Port-Of: odoo/odoo#274527 Forward-Port-Of: odoo/odoo#274086
This update ensures that the Pos Cashmatic module's text is properly translated into other languages. By adding the module to the translation files (.weblate.json), the system will now display the correct text for users in different regions. This improves the user experience and expands the module's accessibility.
Original PR description
This commit add the pos_cashmatic module inside the .weblate.json file so that the srings are translated. 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#275863
This update fixes a visual issue in the API keys kanban view where scope and expiration information for scoped keys were displayed together, creating a cluttered appearance. The change separates these details into distinct lines for better readability and clarity. This ensures that key information is presented in a more organized and user-friendly manner.
Original PR description
The API keys kanban rendered the "Scope:" and "Expires on:" hints as two adjacent inline <small> elements. For a scoped key both are visible, so they were displayed stuck together, e.g. "Scope: rpcExpires on: ...". Render each hint as a block so they stack on their own lines. Keys without a scope are unaffected since the scope hint stays hidden. Description of the issue/feature this PR addresses: Current behavior before PR: <img width="980" height="414" alt="image" src="https://github.com/user-attachments/assets/6cd8b338-1d2e-4abb-a90b-03218aaef941" /> Desired behavior after PR is merged: <img width="979" height="389" alt="image" src="https://github.com/user-attachments/assets/83ffa680-ffb8-415f-af3f-8e53cb8e8351" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275869
This update adds a check to ensure contact emails entered during the French PDP registration process are valid. Previously, invalid emails could cause errors later, leading to a poor user experience. This change improves data quality and prevents potential issues for users.
Original PR description
No verification was done on the contact email in the wizard but if the email is invalid the user would have an error later task-6344324 Forward-Port-Of: odoo/odoo#274065
This fix prevents a crash in the HTML editor when users type URL-like tokens (automatically converted to links). The issue, specific to Safari, caused a 'IndexSizeError' preventing further input. By re-anchoring the selection, the editor now correctly handles these tokens and allows users to continue typing.
Original PR description
Typing in an HTML field (e.g. a contact's Internal Notes) and validating a URL-like token with Enter or Space can crash the editor with "IndexSizeError: The index is not in the allowed range",…
Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).
The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.
```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
setStart@[native code]
createEditorSelection@.../web.assets_web.min.js:12239:15
getSelectionData@.../web.assets_web.min.js:12242:145
updateActiveSelection@.../web.assets_web.min.js:12230:92
@.../web.assets_web.min.js:12218:873
handler@.../web.assets_web.min.js:14366:121
```
Steps to reproduce:
1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.
Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#275587
Forward-Port-Of: odoo/odoo#270910This update fixes an issue where discount lines in the TBAI XML export were incorrectly showing negative import values. The fix ensures that all monetary values, including discounts, are consistently represented as positive numbers, aligning with the system's expected format. This ensures accurate reporting and compliance with tax regulations.
Original PR description
Step to reproduce: - install pos_discount and l10n_es_edi_tbai_pos with demo data - start pos, add a product and a discount of 10% - fulfill the order - go to backend and open that order - from…
Step to reproduce: - install pos_discount and l10n_es_edi_tbai_pos with demo data - start pos, add a product and a discount of 10% - fulfill the order - go to backend and open that order - from "TicketBai" page, open the "TicketBAI Post File" xml file Observation: - `ImporteUnitario` and `ImporteTotal` were exported as positive values for discount lines. cause: - Commit [1] assumed tax details are always positive. - This is not generally true, in case we have price_unit < 0 - The logic relied on `is_refund`, which depends on `qty * price`. - `_l10n_es_tbai_get_values` then multiplied values by `-1` again for refunds. https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L177-L181 - For discount lines, `is_refund = True` and `price = -10`, resulting in `-10 * -1 = 10`. Fix: - Ensure tax detail values are always returned as positive values, matching the assumption introduced in commit [1] [1] https://github.com/odoo/odoo/commit/03d55104e49aa65aa4c6475e199747fe9132e754 opw-6226003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275451 Forward-Port-Of: odoo/odoo#265777
This update fixes a display issue where the 'To Review' invoice filter in the dashboard incorrectly showed multiple invoices. The change ensures that the filter only displays invoices that have been fully posted, providing a more accurate and reliable view of outstanding invoices for users. This improves data clarity and efficiency.
Original PR description
Steps to reproduce: Have one invoice Posted, To Review Have one invoice Draft, To Review Dashboard will only says 1 To Review When clicking the link it shows 2 invoices After this commit- We append the domain of the filter with only posted moves task-6385625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr