Daily updates from Odoo
Monday, July 13, 2026
57 changes · saas-19.4
New functionality added to Odoo
This update provides Russian translations for the Chart of Accounts data within the Odoo localization module for Uzbekistan. Recognizing the widespread use of Russian in Uzbek accounting, this change expands Odoo's usability and adoption among local users. This supports a key market and improves the overall user experience.
Original PR description
This change adds Russian translations for the Chart of Accounts data in the l10n_uz module. Standard practice is to enable only a country's official statutory language in localization modules However, the business reality of Central Asia particularly Uzbekistan justifies an exception: Russian is widely used in accounting practice there, and supporting it will significantly improve adoption among local users. task-6229114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274137 Forward-Port-Of: odoo/odoo#269320
Enhancements to existing features
Uzbekistan financial reports now include Russian translations alongside Uzbek. This helps businesses in Uzbekistan use Odoo reports more easily in a commonly used business language, improving local adoption.
Original PR description
Uzbekistan's business environment requires Russian in addition to the official Uzbek language to ensure adoption. While localizations typically activate only statutory languages, Central Asian market realities justify this exception. task-6229114 -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#122901 Forward-Port-Of: odoo/enterprise#120250
Updates to sales commission planning and reporting aim to make commission setup and achievement tracking clearer. This helps sales managers better monitor performance and manage commission plans with improved views and report behavior.
Odoo can now use official daily exchange rates from the Central Bank of Azerbaijan for automatic currency updates. This helps businesses using AZN translate foreign-currency accounting and tax transactions more accurately, including rates quoted for larger nominal amounts.
Original PR description
This commit adds the Central Bank of Azerbaijan (CBA) as a supported service provider for automatic currency rate updates. Purpose: To ensure multi-currency accounting entries and taxable transactions are accurately translated into the national currency (AZN) using the official exchange rate defined by the CBA for the transaction day. Functionality: -Enables fetching official daily exchange rates directly from CBA via XML. -Automatically handles rates defined for different nominal quantities (e.g., rates quoted per 100 units instead of 1 unit). Backport of: https://github.com/odoo/enterprise/pull/122626 task-6112867 Forward-Port-Of: odoo/enterprise#123436
Work order planning views now focus on planned work by default, reducing the chance of accidental replanning and keeping completed manufacturing dependencies out of planning charts. Shop floor card options now better match enabled settings, and engineering change cost comparisons are more accurate for operation changes.
The AI app now marks an upcoming retired Google embedding model as deprecated and automatically refreshes older embeddings that used deprecated models. This helps keep AI-powered features reliable without manual intervention when providers phase out older models.
Original PR description
The model gemini-embedding-001 will be deprecated soon, so this commit is: - Deprecating that model. - Introducing an autovacuum to recompute embeddings that were done using embedding models that have been deprecated. task-6004597
This pull request enhances the user experience for subcontracting workflows in Odoo. It simplifies the interface by renaming key columns and removing irrelevant fields, making it easier for users to manage subcontracting operations. These changes improve clarity and reduce potential confusion.
Original PR description
Small UX improvements for subcontracting, includes following changes: - Custom Operation Dependency should not be displayed/set if type of the BOM is subcontracting/kit. - Column name was changed from Free to use / On Hand subcontractor location to Subcontractor Stock - Manufacturing Readiness should not be displayed/set if type of the BOM is subcontracting/kit. task-6320074
Resolved issues and error corrections
Belgian holiday attest payslips now show the employee's private address correctly in the required places after termination. This prevents missing address details on documents for current and prior year holiday attestations.
Original PR description
[FIX] l10n_be: missing employee address on holiday attest Bug reproduction: Belgium -> create employee -> fire the employee -> look to the holiday attest payslips (N and N-1) -> private address of the employee is missing in 2 places in payslip Bug cause: o.employee_id.work_contact_id work contact id was used in report but we can just use private_street, private_city etc. instead. Bug solution: Use private_street, private_city etc. fields directly from the employee model. task - 6361457
This fixes a display issue in the Sign app where template tags could overlap the header when longer translated text made the header taller. The layout now adapts better to different languages and content lengths, improving readability and avoiding a cluttered header.
Original PR description
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and…
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings. - Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position. - Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements. - This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations. 19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486 Before fix: <img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" /> After fix: <img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" /> Forward-Port-Of: odoo/enterprise#120590 Forward-Port-Of: odoo/enterprise#118937
Fixed an issue where FedEx outbound shipping labels lost their reference field when return label creation was enabled. This ensures the original shipment label shows the expected reference information while still supporting return labels.
Original PR description
Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. <img width="438" height="148" alt="image" src="https://github.com/user-attachments/assets/42acce7b-6177-4f8f-81d3-ad6dfd3e4bb2" /> Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. Expected outcome (after fix) ---- <img width="428" height="146" alt="image" src="https://github.com/user-attachments/assets/0d22e147-da90-4aa4-b3ca-2d996c7cc147" /> ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#118659
The Delivery Sendcloud test suite was adjusted so mocked tests run during regular continuous integration instead of only in nightly checks. This helps catch delivery integration issues earlier, including corrected expectations around multi-package shipment weight handling.
Original PR description
Test class was tagged as external although calls are mocked. This means errors were only caught in nightly and not by CI. Removing the tag requires fixing some of the tests. For `test_multicollo`, we send the average weight of packages instead of the total since 97f82442c9fee7dcb3e8c5e9bacddcd6bb864e11. Forward-Port-Of: odoo/enterprise#121665 Forward-Port-Of: odoo/enterprise#111660
The social CRM feed now shows the correct post actions instead of an empty menu. Feed refreshes are also more reliable because batch requests are given more time to complete.
Original PR description
Bug 1 === Since b75755ea8ac65ce5ce973412e3c4194fa1bd6fd3 , the menu on the stream post could be visible but empty. The reason is that we checked for `this.isConvertibleToLead` instead of `this.isConvertibleToLead()`. We take advantage of this bug fix to correctly overwrite the condition without replacing the entire button (which can break other module overwriting the same element). Bug 2 === Sometimes, when refreshing the feed view, an error occurs because the request timeout. To fix it, we increase the timeout when doing requests in batch. Task-6254983 Forward-Port-Of: odoo/enterprise#118329
This fixes Envia delivery failures for some Colombian cities whose postal codes were stored with fewer digits. The system now formats these codes correctly, helping shipments to and from affected locations such as Antioquia process more reliably.
Original PR description
Issue ----- Delivery does not always work from/to some cities in Colombia, like Antioquia. Cause ----- There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian…
Issue ----- Delivery does not always work from/to some cities in Colombia, like Antioquia. Cause ----- There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian localisation were padded in https://github.com/odoo/enterprise/blob/390acf532e8932fd9b9a708382a5e36cdbb35754/delivery_envia/models/envia_request.py#L726-L727 However, some of the colombian cities listed in `l10n_co_edi/data/res.city.csv` have 4 digit codes (like `SANTA FÉ DE ANTIOQUIA`, code `5042`). https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/l10n_co_edi/data/res.city.csv#L12 These 4 digit codes have to be right-padded to 5 characters before the left-padding to match the official colombian zip codes. See colombian gov official document (PDF download) where the code is actually `05042`. https://www.dane.gov.co/files/censo2005/provincias/subregiones.pdf ----- Ticket: opw-6248252 Forward-Port-Of: odoo/enterprise#123344 Forward-Port-Of: odoo/enterprise#120164
This update aligns a Hong Kong payroll employee rental field so it behaves consistently across related employee records. It prevents automated payroll tests from failing and helps maintain reliability in payroll configuration handling.
Original PR description
The readonly value inconsistency between l10n_hk_rental_id field in the employee's model and the one in the version's model was provoking some tests to fail. Related runbot error: https://runbot.odoo.com/odoo/error/241956 task-6306032 Forward-Port-Of: odoo/enterprise#120673
This fixes Chilean export invoice PDFs so customs information stays in the correct columns even when origin or destination port details are missing. It prevents package quantities from appearing under the wrong heading, improving document accuracy for customers and compliance workflows.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#122906 Forward-Port-Of: odoo/enterprise#121923
This fixes an issue in the Belgian CODA cleanup module where bank statement import data could be read in the wrong format after a related update. It helps prevent import errors and ensures bank statement information is processed correctly.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
The payroll payrun chatter panel and button now appear only on the intended payrun screens. This prevents confusing extra controls from showing in other payroll views, such as Time Offs, improving clarity for users.
Original PR description
The global `PayRunChatterService` was leaking state across shared views, causing the chatter panel and button to appear on views accessed outside the PayRun layout (e.g., via the main Payroll > Time Offs menu). Fix this by introducing a `useEffect` hook in `PayRunLayout` that checks for a valid `payrun_id` or `payRunReactive` state on view render. If absent, the chatter service state is explicitly reset and closed. The control panel button is also wrapped in a contextual `t-if` check, fully isolating the feature to its intended screens. Task : 6347871
This fixes an issue where the cursor could jump backwards while typing in the Studio XML editor. The editor now keeps cursor position reliably per editing session, making report and view editing smoother and less disruptive for users.
Original PR description
Steps to reproduce the issue: -> Open studio -> Edit any view -> Edit xml => Cursor moves backwards when typing Some components inside of the report editor were managing the cursor position based on the document manually. Rendering timings could cause the cursor to move while typing. This commit internalizes the cursor position in the CodeEditor and keep track of them based on the sessionsId, making sure that the cursor position is always correct and only changing when switching between sessions while also making the component API simpler. Community: https://github.com/odoo/odoo/pull/274681
Subscription products that allow one-time purchases now correctly display the original price crossed out next to the Buy Once price. This makes discounts or pricing differences clearer to shoppers and improves price transparency on product pages.
Original PR description
Version - saas-19.1 Steps to reproduce: - Enable 'Accept One Time Sale' on a subscription product - Open the product page on the website Issue: For subscription products with one time sale enabled, the original price was not shown as a strikethrough next to the Buy Once price. Fix: - Captured and exposed the original price to the template before it gets overwritten during subscription price processing - Added the missing strikethrough element to the Buy Once section of the product page Task ID - 6260207 Forward-Port-Of: odoo/enterprise#119488
This fixes how the Belgian payroll 274 declaration shows the total exemption amount. The correction ensures the displayed amount matches the underlying payroll calculation, reducing confusion when reviewing declarations.
Original PR description
The total exemption amount (only used for display) was wrongly computed. Forward-Port-Of: odoo/enterprise#123965 Forward-Port-Of: odoo/enterprise#123714
This fix reverts a previous Belgian payroll change that caused an item to appear twice on the employee form. It keeps employee records cleaner and helps payroll users avoid confusion when reviewing benefit information.
Original PR description
- A previous change has been reverted to avoid appearing twice. Forward-Port-Of: odoo/enterprise#123906
The Odoo Box point of sale module is now included in the translation setup. This allows the module’s text to be translated for users in different languages, improving localization coverage.
Original PR description
In odoo/enterprise#118646 the `obox_point_of_sale` module was added in stable, but the `.weblate.json` file wasn't updated, meaning it cannot be translated. This commit fixes the issue. Forward-Port-Of: odoo/enterprise#124037
Payslip email activity now records a neutral sent-by-email message instead of incorrectly saying a payslip was re-sent the first time it is sent. The note is also added only once per payslip, avoiding duplicate chatter entries when sending payslips for multiple employees.
Original PR description
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when…
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when the payslip is being sent for the first time. The log call also runs inside the loop over the employees and goes through all the payslips of the wizard on each pass, so when the wizard sends payslips of several employees every payslip gets the same note once per employee. This started with the rework of the wizard in https://github.com/odoo/enterprise/commit/39e0488a7e076ee648b47cc3d1cad41cadfd692e **Fix:** The wizard cannot tell a first send from a resend. There is no field on the payslip that keeps track of a previous send, and the chatter cannot be used for that either because the mail sent automatically on validation can be deleted after sending. The fix changes the log in action_send() to say the payslip has been sent by email, which is true in both cases, and moves it out of the employee loop so each payslip gets exactly one note. **Steps to reproduce:** 1. In Payroll > Configuration > Settings, set "Send payslips to employees" to When Paid and save 2. In Payroll > Payslips, create an off-cycle payslip for an employee, click Compute, then Validate 3. Go back to the settings and set "Send payslips to employees" to When Confirmed 4. On the payslip, click Pay, then Mark as Paid 5. Click Print so the payslip document is generated 6. Click Send By Email and send the mail 7. Check the payslip chatter => The chatter shows "The payslip has been re-send to the employee." while the payslip was never sent before Ticket [link](https://www.odoo.com/odoo/project.task/6324204) opw-6324204 Forward-Port-Of: odoo/enterprise#123298
Employees and payroll teams can now access the payslip correction option directly from a payslip. This restores expected payroll workflow behavior and helps users correct payslip issues without needing to navigate elsewhere.
Original PR description
The payslip correction should also be available on the payslip. This is a backport of commit 117f0117a839cd29cb9f52aaf52b1e25efe1e314 task-6374294 Forward-Port-Of: odoo/enterprise#123558
The payroll pay run warning for missing payslips now works correctly again. This helps payroll teams catch incomplete pay runs before processing, reducing the risk of missed employee payments.
Original PR description
The missing payslip in a payrun warning wasn't triggered correctly because we were filtering on the schedule pay of the payrun and this field was removed in a previous PR. task-6329134 Forward-Port-Of: odoo/enterprise#121641
Fixed an issue where subscription product pages could fail when a discount was set directly on a recurring plan without a pricelist. Customers can now view the product page and see the correct discounted recurring price instead of an error.
Original PR description
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to…
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to reproduce:** 1. Create a subscription product with a recurring plan. 2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price). 3. Open the product page on the website. **Current behavior:** The page fails with a 500: Internal Server Error during price computation. **Expected behavior:** The page loads and shows the discounted recurring price. **Cause of the issue:** For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion. **Fix:** Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record. opw-6306105 Forward-Port-Of: odoo/enterprise#121466
Draft planning entries in My Planning now display with the expected hatched styling instead of looking like confirmed entries. This makes it easier for users to distinguish draft plans at a glance and avoid confusion when reviewing schedules.
Original PR description
Issue: Calendar entries appear plain even when they should appear hatched. (ex. while in draft status) Steps to reproduce: If you create any planning and set it to draft. Then go to Planning > Planning > My Planning, the newly created plan should be in hatched but it becomes plain. Cause: In the view planning.slot.my.calendar there was missing the element that causes the views to become hatched when in draft status. Solution: Added said element. opw-6260055 Forward-Port-Of: odoo/enterprise#119153
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 Description of the issue/feature this PR a
Original PR description
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 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#275791 Forward-Port-Of: odoo/odoo#274019
This update fixes a situation where the 'Invoice' button was incorrectly displayed in the repair module. Now, the button will only appear after a repair has been successfully completed, ensuring users only see relevant options. This change is part of the v19.4 release and will be cleaned up in subsequent versions.
Original PR description
This button should appear only when a repair is done. Note: the existing mechanism wil be cleaned post v19.4 release task: 6379961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the Peppol demo mode wasn't correctly applied to databases that had previously been neutralized. Previously, the system defaulted to production mode, leading to incorrect document registration. This fix ensures the demo mode is properly set when installing Peppol on a neutralized database, preventing unintended data transmission to the live Peppol network.
Original PR description
When Peppol is installed on a database that was already neutralized (ex: a staging database where the feature is enabled after the neutralization happened), the account_peppol.edi.mode parameter is not set: data/neutralize.sql only runs at neutralization time, not when the module is installed afterwards. The demo/ data that also sets this parameter is not loaded on databases without demo data (real production/staging databases). As a result, _get_peppol_edi_mode() falls back to 'prod' and the neutralized database registers and sends documents against the live Peppol network. Steps to reproduce: - Neutralize a database on which Peppol is not installed yet - Install the account_peppol module - Open the Peppol settings / registration wizard: the mode is Production instead of Demo Force the demo mode in the pre_init_hook when the database is neutralized, mirroring data/neutralize.sql opw-6307710 Forward-Port-Of: odoo/odoo#275210 Forward-Port-Of: odoo/odoo#273019
This update resolves a minor issue where pressing the Tab key within a link preview in Odoo would cause a technical error. The fix ensures smooth navigation within link previews, improving the user experience. This change was part of a larger effort to maintain stability and usability.
Original PR description
Since [1] elements within the link preview can be focused. However, when pressing tab an error is raised. This commit prevents this error from happening. [1]: https://github.com/odoo/odoo/commit/34db19f4a2b42d7e41205d7d793f5b3f408c19af task-6366337 Forward-Port-Of: odoo/odoo#275638 Forward-Port-Of: odoo/odoo#274682
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment handling for invoices sent via UBL and other methods. This improves the reliability of invoice delivery.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the process of verifying EU VAT numbers when creating new companies. Previously, a redundant verification step was performed twice, impacting performance. This change consolidates the verification to a single call, optimizing the system and reducing potential delays.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes an issue where employees were incorrectly showing as having no remaining holiday days after being allocated time off. The fix ensures that the system accurately reflects available leave balances by correctly passing the target date through the calculation process, even when using sudo contexts.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update corrects a visual inconsistency in the website's accordion controls. A previous change unintentionally created duplicate styling rules, leading to different colors when the accordion was open or closed. This fix ensures a consistent and professional look across all accordion elements.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update fixes an issue where the cursor position in the Odoo Code Editor would jump unexpectedly while typing. By internalizing the cursor tracking, the editor now accurately reflects the user's typing, providing a smoother and more reliable editing experience. This improves usability for developers working within Odoo.
Original PR description
Steps to reproduce the issue: -> Open studio -> Edit any view -> Edit xml => Cursor moves backwards when typing Some components inside of the report editor were managing the cursor position based on the document manually. Rendering timings could cause the cursor to move while typing. This commit internalizes the cursor position in the CodeEditor and keep track of them based on the sessionsId, making sure that the cursor position is always correct and only changing when switching between sessions while also making the component API simpler. Enterprise: https://github.com/odoo/enterprise/pull/123244
This update removes a confusing message ('Connect your software...') from sales quotations that was appearing in PDFs for customers with portal access. The change ensures all quotes, regardless of customer portal usage, present a clean and professional look. This improves the customer experience and aligns with the standard portal button design.
Original PR description
Steps to reproduce: 1. Install Contacts and Sales 2. Open any of the contacts, click on the gear icon at the top and click on "Grant portal access" 3. Grant access to all contacts 4. Create a Sale Quotation for that contact and print it Issue: The sentence 'Connect your software... ' appears in the pdf when sending the quote to a contact who was portal access, while it does not appear if the contact does not have portal access Expected behavior: Should not appear regardless of whether the customer has a portal account or not since they have it appear as a smart button in their portal. opw-6308357 Forward-Port-Of: odoo/odoo#275469 Forward-Port-Of: odoo/odoo#272893
This update strengthens the website's wishlist feature by preventing unauthorized users from subscribing to products that don't exist or using existing user accounts. It now validates product availability and requires users to sign in before subscribing, reducing potential security risks and misuse of user data.
Original PR description
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This…
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts. Current behavior before PR: Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock). Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user. No validation is enforced, leading to potential security issues. Desired behavior after PR is merged: Adding a subscription for a non-existent or unavailable product raises a ValidationError. Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first. Backend validation prevents misuse of registered user emails and improves security. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275422 Forward-Port-Of: odoo/odoo#271880
This update corrects a technical issue where an empty distribution model was being flagged for merging. The fix removes unnecessary merging logic, streamlining the process and preventing errors. This ensures smoother operation within the analytic accounting module.
Original PR description
It is possible to have an empty distribution model, there is therefore ne need to merge it, especially since it raises when doing this ```python self.env['account.analytic.plan'].mapped(lambda p: p._column_name()) ``` Forward-Port-Of: odoo/odoo#275839
This update brings the latest version of the spreadsheet component to Odoo 19.4. It addresses several technical issues related to chart rendering, conditional formatting, and named ranges, ensuring a smoother and more reliable spreadsheet experience for users. Multiple developers collaborated on this update to improve stability and performance.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c83d4aa59 [REL] 19.4.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c83d4aa59 [REL] 19.4.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9b3aee7f3 [FIX] named range selector: select hidden named range [Task: 6171849](https://www.odoo.com/odoo/2328/tasks/6171849) https://github.com/odoo/o-spreadsheet/commit/30ead68b5 [IMP] dashboard: fix dark mode background [Task: 6349211](https://www.odoo.com/odoo/2328/tasks/6349211) https://github.com/odoo/o-spreadsheet/commit/79c5f8589 [FIX] conditional_formatting: handle zero color scale midpoint [Task: 6312961](https://www.odoo.com/odoo/2328/tasks/6312961) https://github.com/odoo/o-spreadsheet/commit/c92559567 [FIX] charts: handle undefined values in treemap chart [Task: 6329404](https://www.odoo.com/odoo/2328/tasks/6329404) https://github.com/odoo/o-spreadsheet/commit/4a3e3c7fc [FIX] config: filter-out claude folder from prettier [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue where duplicated printers in the Point of Sale module would lose their configured IP address, defaulting to 0.0.0.0. The fix ensures that when a printer is duplicated, it retains the original IP address, simplifying setup and improving the user experience. This prevents potential connectivity problems with POS hardware.
Original PR description
Steps to reproduce: ==== - Configure a printer from printers menu. - Duplicate the printer. Issue: ==== - The duplicated printer's IP address is reset to `0.0.0.0`. Cause: ==== - copy_data()` unconditionally overrides `printer_ip` with `0.0.0.0`. Fix: ==== - Stop overriding `printer_ip` so the duplicated printer inherits the original IP address by default. task-6365809 Forward-Port-Of: odoo/odoo#274964
This update fixes several issues within the HTML editor's file box functionality. Specifically, it prevents the powerbox from appearing within file boxes, ensures plain text is pasted correctly, and resolves cursor behavior problems. These changes enhance usability and stability when working with files in the editor.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275765 Forward-Port-Of: odoo/odoo#268827
This update resolves an issue where pressing the space key in the Contact app could cause a technical error. The fix ensures the system handles optional settings correctly, preventing the error and improving the user experience. This change enhances stability and reliability for Contact record management.
Original PR description
**Steps to reproduce:** - Go to Contact app - Open any record - Press "Space" key - Traceback: `Cannot read properties of undefined (reading 'groupId')` **Issue:** `quickCreateState` props is undefined (as it is optional). **Fix:** Add check to safely handle such cases. [introduced by] https://github.com/odoo/odoo/commit/22c07c7dcb2a93d9ebef5a83e48aa3d252128519 opw-6377425 Forward-Port-Of: odoo/odoo#275329
A recent update to the website builder was causing slow updates due to a delay in fetching image sources. This fix resolves the issue by ensuring images have the correct source data, preventing performance bottlenecks and improving the builder's responsiveness. This impacts the user experience when editing website content.
Original PR description
Commit [1] introduced a cache for images' src in `_getValidSrc`. An undefined src will work but block the thread for a moment (up to seconds in some cases) until `fetch` returns a 404. The bug can be seen from the website builder: - Open the builder - Open your dev tools on the "network" tab - Click on the website logo => a failed fetch (404) appears and blocks the builder from being updated quickly. It happens because the element doesn't have any `dataset.originalSrc` (in this case, because it is an image field). [1]: https://github.com/odoo/odoo/commit/5164080cbadddaa7052dd4d2f997b944bd7a16e8 task-6247171 Forward-Port-Of: odoo/odoo#275078
This update fixes an issue where the ECPay payment portal displayed in simplified Chinese when Odoo was set to traditional Chinese. The fix ensures the portal correctly uses traditional Chinese (zh_TW) for users in Taiwan, aligning with the Odoo locale setting. This improves the user experience for our customers using the traditional Chinese language.
Original PR description
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in…
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal should show up in traditional Chinese (zh_TW) also. ## Steps to reproduce: In Odoo 19.0, 1. Install modules: payment_ecpay, website, ecommerce 2. Change the company and website language to Traditional Chinese (zh_TW). Make sure the currency is in TWD (Taiwanese Dollar) 3. Add ECPay as a payment method 4. Add some test products and checkout with ECPay 5. Observe the language on ECPay portal website, and payload in V5 package in network tab ## Cause of the issue: Initially the locale mapping was wrong, mapping CHI to zh. There's no "zh" locale, must either be "zh_TW" or "zh_CN". So when the Odoo locale is set to traditional Chinese (zh_TW), it included Language=CHI in the payload and redirect to ECPAY, making ECPay think that we're trying to request the simplified Chinese site. Caused by commit: 76c81d6f67b54940879b1020068c7140c4f2199b ## Fix: Fixed the language mapping following ECPay developer docs, and what language code to be included in the payload sent to ECPay from current Odoo locale. opw-6270820 --------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269206
This update fixes a formatting issue in Odoo's logs that was displaying extremely long, precise numbers for request times (like milliseconds). By rounding these times before they're logged, the logs now show more readable and manageable values, making it easier to identify potential performance bottlenecks. This improves the clarity and usefulness of our operational logs.
Original PR description
The per-request access log formats query_time and remaining_time with %s, so unless they are rounded first they are rendered as the full float repr, e.g. "0.0016751289367675781" for a sub-millisecond request. Round query_time and remaining_time once, before `colored_extra` is copied from `extra`. 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 resolves an issue where the 'ICE' field on customer records in the Odoo portal was not saving correctly. The change ensures that this critical field is properly updated, preventing it from remaining empty after customer modifications. This improves data accuracy and functionality for users.
Original PR description
After this PR https://github.com/odoo/odoo/pull/262274 ICE field on frontend was no longer saving on customer and because of that it always stays empty after save. Handle `additional_identifiers` field on portal to properly set those values in `additional_identifiers` fiels. task-5208254
This update resolves an issue where clearing the search in the Threads panel caused unexpected behavior and excessive data loading. By ensuring the search results are consistently rendered, the system now correctly displays the intended list size, improving the user experience. This fix prevents performance issues and ensures a smoother browsing experience.
Original PR description
The Threads panel resets its search results in a layout effect, so clearing the search empties `searchTerm` one render before the full sub-channel list is restored. During that transient render the load-more sentinel (`t-if="!searchTerm"`) re-mounts next to the still short filtered list; the IntersectionObserver can catch it visible and fetch an extra page, making the list overshoot its expected size. The `count(31)` tour step then never matches, jumping straight to 61. Read the displayed list straight from the record while browsing so the list and the sentinel flip together in the same render, leaving no window where the sentinel sits next to a short, filtered list. https://runbot.odoo.com/odoo/error/941492
This update fixes a visual glitch (flickering) in the call settings dialog when switching between tabs. The change improves the user experience by ensuring the dialog renders smoothly and consistently. Additionally, the underlying code was refactored for better efficiency and to automatically update device selections.
Original PR description
Purpose Prevent height flickering in the call settings dialog when changing tabs. Before this commit, the DeviceSelect component awaited asynchronous work in `onWillStart`, blocking the rendering of…
Purpose Prevent height flickering in the call settings dialog when changing tabs. Before this commit, the DeviceSelect component awaited asynchronous work in `onWillStart`, blocking the rendering of tab content and causing the settings dialog height to flicker when switching tabs. After this commit, the asynchronous work is still started in `onWillStart`, but its promise is no longer awaited before rendering. This allows the tab content to render immediately while the asynchronous initialization completes in the background, eliminating the flicker. This commit also refactors the DeviceSelect component by: - Replacing the proxy-based state with signals. - Computing `selectedDevice` from `userDevices` instead of updating it on every device change. This ensures the selected device label stays in sync automatically when `userDevices` changes (e.g. due to permission changes or newly detected devices), reducing duplicated state. | | | |-|-| | BEFORE | <img width="800" height="446" alt="ezgif-1545762edb9521cb" src="https://github.com/user-attachments/assets/d453dec7-007e-4bc3-a04b-125208d7a8e2" /> | | AFTER | <img width="800" height="446" alt="ezgif-1db5bef8c163cf2d" src="https://github.com/user-attachments/assets/bdf05366-3490-414b-ac83-2b1e35c6309c" /> |
This update resolves a bug preventing website settings changes to the robots.txt file from being saved correctly. The fix ensures the system accurately identifies the target website, allowing users to properly edit and apply robots.txt configurations. This improves website SEO and crawling functionality.
Original PR description
Steps to Reproduce: 1. Visit the '/robots.txt' URL and check its content. 2. Go to website settings through the configuration menu. 3. Switch to debug mode. 4. Click on the 'Edit robots.txt' option under the 'Tracking & SEO' block. 5. Make an edit in the wizard and save your changes. 6. Reopen the wizard to modify the content. Observed Issue: The changes made using the 'Edit robots.txt' option are not reflected at the '/robots.txt' URL and are also not visible when the content is re-edited. Explanation: The `env.context` no longer contains the `website_id`. The robots.txt editor wizard relied on `env.website` to read and write the current website's robots.txt content. Since the website is no longer available in this context, the wizard cannot determine which website to operate on. This commit passes the target `website_id` through the action context, allowing it to initialize and save the wizard content into particular field. task-6365217
A technical issue preventing the generation of the Return Slip report for return pickings has been fixed. This change ensures the report can be reliably printed, preventing errors and improving the usability of the Stock module. The fix addresses a 'KeyError' caused by accessing a variable before it was defined in the report template.
Original PR description
Issue before this commit: ========================= Printing the return slip report for a return picking raised a traceback. Steps to reproduce: =================== - Install the Stock module with demo data. - Create a return picking. - Click on the Action menu and print the Return Slip report. Result: A traceback is raised with: KeyError: 'picking' Cause: ====== The 'stock.return_label_header' template accesses the 'picking' variable before it is defined, resulting in a 'KeyError' during report rendering. This issue was introduced by PR: https://github.com/odoo/odoo/pull/234112 With this commit: ================= Define the 'picking' variable before calling the template that uses it, preventing the traceback.
This update adds email verification to the French PDP registration wizard. Previously, invalid email addresses could cause errors later in the process. This change ensures data integrity and a smoother user experience by preventing issues caused by incorrect contact information.
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 update corrects an issue where the spreadsheet function incorrectly identified account codes based on partial matches. The change improves the accuracy of account lookups within the spreadsheet, ensuring users can correctly associate transactions. This resolves a potential error in reporting and data analysis.
Original PR description
Adjusting spreadsheet account lookup by name to exclude partial matches. Adjusting a related test to verify. task-6354503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where a new database index wasn't being used by Odoo's internal queries. The change ensures the index is correctly utilized by both specific queries and those generated by the Odoo ORM, improving query performance. This primarily impacts the project and to-do modules.
Original PR description
The index added by 778c09f4ffb4 works for the specific query it was meant to improve. Unfortunately, it cannot be used by ORM-generated queries, which is unfortunate. The reason is that the ORM generates queries with `IS TRUE` or `IS NOT TRUE` for boolean fields. Because `=` and `IS` do not have the same semantics, postgresql cannot use the index for ORM-generated queries. = -> eval(NULL = True) -> NULL IS -> eval(NULL IS TRUE) -> FALSE By changing both the index and the query to use `IS TRUE`, the index is now used by both the specific query and the ORM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275681
This update fixes a discrepancy in the default tax date obligation for Serbian VAT invoices. Previously, the system defaulted to a 'By Issuance Date' setting, which wasn't compliant with Serbian law. Now, it correctly defaults to 'By Delivery Date' as mandated by Article 16 of the Serbian VAT Law, ensuring accurate tax reporting.
Original PR description
According to[ Article 16 of Serbia's VAT Law](https://www.paragraf.rs/propisi/law-on-value-added-tax.html#:~:text=of%20Tax%20Obligation-,Article%2016,-A%20tax%20obligation), the tax obligation arises at the time of delivery of goods/services by default. 'By Issuance Date' only applies to a narrow set of services under Article 16(2a) Before: l10n_rs_tax_date_obligations_code defaulted to '3' (By Issuance Date) After: defaults to '35' (By Delivery Date) Upgrade: odoo/upgrade#10657 task-6348377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273608
Features or functions removed from Odoo
The Belgian payroll rules now stop applying the elderly worker reduction in Brussels starting in the third quarter of 2026. This keeps payroll calculations aligned with the updated regional rules and updates related checks accordingly.
Original PR description
removed the reduction for everyone in BXL starting Q3 2026 and adapted the tests task - 6331080
This update removes the 'Pay on Invoice' payment provider option from invoices. This change simplifies the payment process and aligns with best practices, as offering 'Pay on Invoice' for standard invoices was deemed unnecessary. It’s a minor adjustment to improve clarity and usability.
Original PR description
Paying an invoice with the pay-later provider "Pay on Invoice" doesn't make sense. Removing it from the list of available providers in such documents.