Daily updates from Odoo
Friday, April 24, 2026
375 changes
6 changes
Resolved issues and error corrections
This update corrects a technical issue where a duplicate record was incorrectly introduced in the French reporting module (l10n_fr_reports). This fix ensures data integrity and prevents potential reporting errors related to audit returns. The change is a minor correction to the existing system.
Original PR description
this forward port wrongly introduced an already existing record https://github.com/odoo/enterprise/pull/114739
This update fixes a technical issue where a key event wasn't being properly sent during a process, causing test failures. The change ensures the necessary parameters are included in the `BUS:OUTDATED` event, improving the stability and reliability of the Odoo system. This resolves a reported bug and confirms the system's continued functionality.
Original PR description
Since [1], the `BUS:OUTDATED` should be sent with the `unregisterMultiTab` parameter. But a call site doesn't send it, leading to test failures. [1]: https://github.com/odoo/odoo/pull/260380 fixes runbot-243238,243240,243239 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 corrects a UI issue that occurred when sign templates included roles with assigned users. A technical problem with how binary data was being handled caused errors and a broken user interface. The fix converts binary data to a standard base64 format, ensuring proper rendering and preventing errors during template loading.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Create sign template with one role. - Set 'assign to' value to that role. - Try to refresh the page or again open the template. Issue: - sign item and roles are not render on template properly and UI get broken. - ConnectionLostError occurs when loading sign template with 'assign to' value on role. Cause: - After recent changes, Binary fields (avatar_128/avatar_1920) now return BinaryValue objects instead of base64 strings. - These objects are not JSON serializable and cause UnicodeDecodeError during RPC response serialization. Solution: - Convert BinaryValue to base64 string using .to_base64() before returning in get_template_items_roles_info. task-6122941
This update fixes an issue where users were incorrectly prompted with a zero-demand warning during immediate receipt validation via barcode scanning. The change bypasses this warning for immediate transfers, streamlining the process and preventing unnecessary interruptions. This ensures accurate and efficient receipt processing.
Original PR description
Issue before this commit: ========================= When validating an immediate receipt, the user gets a zero-demand warning wizard, even though quantities are actually being received. Steps to Reproduce: ========================= - Install the stock_barcode module - Create an immediate receipt. - Validate it. - The zero-demand warning wizard appears. Cause of the issue: ========================= This behaviour was introduced in a [PR](https://github.com/odoo/odoo/pull/241646/changes/0238ff2cdd58524da1d7fccb411a94d2bce73094) to warn users when confirming/validating a picking with zero-demand moves. However, for immediate transfers, demand (product_uom_qty) is always 0, so the condition is always true and the wizard is always shown, even when quantities are being processed. With This Commit: ========================= Avoid showing the zero-demand warning wizard when validating an immediate picking from the barcode interface.
This update corrects a display issue where the tip amount was incorrectly formatted (showing '415' instead of '4,15') when users overpaid in certain locales. The fix ensures the tip amount is correctly displayed based on the user's selected decimal separator, improving the user experience and accuracy of tip calculations.
Original PR description
Steps to reproduce 1. Set language decimal separator to "," and thousands separator to "." 2. Open PoS, create an order (e.g. total 17.85) 3. Pay more than the total (e.g. 22) 4. Open the Tip popup —…
Steps to reproduce
1. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415
Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.
opw-5895622
Forward-Port-Of: odoo/odoo#255273A technical issue preventing the 'Gelato: Order status update' email template from saving correctly has been resolved. The fix addresses a browser normalization problem that incorrectly rendered HTML, causing an error. This ensures the email template functions as expected.
Original PR description
**Steps to reproduce:**
- Go to Technical > Email > Email Templates
- Try to edit and save "Gelato: Order status update"
- QWebError is raised: `KeyError: 'tracking_data'`
**Issue:**
Browser html normalization silently move block elements such as `<ul>` outside `<p>` when rendering the template body_html as it is invalid html. This moved the `t-foreach="ctx['tracking_data']"` evaluation outside the surrounding `<t t-if="ctx.get('tracking_data')">` which triggered the error.
**Fix:**
Removed `p` element to use the outer `div` and avoid the issue for now.
related: https://github.com/odoo/odoo/commit/b24974d64c3afe5febdad9abff9cb23a333f1ada
similar: https://github.com/odoo/odoo/pull/256605
opw-6114223
Forward-Port-Of: odoo/odoo#25954812 changes
Resolved issues and error corrections
This update ensures our system correctly processes new types of data being sent through Peppol, a key European payment network. By adding a common field to track the movement state, we're prepared for future Peppol updates and maintain seamless integration with this important payment system. This enhances our ability to support evolving payment standards.
Original PR description
With the addition of new peppol_move_state for the Application Responses in Peppol, some checks to know wether the move was sent through Peppol were not updated. This commit does that by adding a common field for it. This is usefull as we might add some extra peppol_move_state values in the near future (Peppol supports more response types than we currently offer to our users). Forward-Port-Of: odoo/odoo#258598
This update fixes a confusing error message that appeared when employees changed their contracts and working schedules, particularly when leaves were involved. The fix now includes the original error traceback, making it easier for administrators to understand and resolve the issue related to leave allocations.
Original PR description
A validation error is raised if changing employee's contract with a new working schedule on a period with leaves and the new working schedule changes the duration of these leaves in such a way that the employee no longer has the required allocation for them. This adds to the error message the original error traceback for debuggig purposes. Task: 6105516 Forward-Port-Of: odoo/odoo#258280
This update fixes an issue where styling applied to images (like rounded corners or shadows) was incorrectly carried over when replacing an image with an icon in the To-do app. Now, styling is automatically removed, ensuring icons always display with their intended, clean appearance. This improves the visual consistency of the application.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259611 Forward-Port-Of: odoo/odoo#258060
This update fixes an issue where increasing the quantity of a service product in a sales order incorrectly generated a purchase order with an inflated quantity. The fix ensures the quantity is always calculated and expressed in the sales order's unit of measure, resolving a discrepancy in the purchase order generation process. This prevents over-ordering and ensures accurate purchase order quantities.
Original PR description
Steps to reproduce the bug: - Create a service product "P1": - In the Purchase tab: - Vendor: Azure Interior - Subcontract Service: True - UoM: dozen - Purchase UoM: unit - Create a sales order with…
Steps to reproduce the bug:
- Create a service product "P1":
- In the Purchase tab:
- Vendor: Azure Interior
- Subcontract Service: True
- UoM: dozen
- Purchase UoM: unit
- Create a sales order with 1 dozen of P1
- Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
- Update the quantity from 1 to 2 dozen
Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186
Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178
opw-6049106
Forward-Port-Of: odoo/odoo#260517
Forward-Port-Of: odoo/odoo#255478This update fixes an issue where MTSO procurements were incorrectly estimating available stock due to how free quantities were calculated. The change ensures that stock availability is accurately reflected across multiple levels of a product's bill of materials, preventing over-ordering of components. This improves procurement accuracy and reduces potential stock discrepancies.
Original PR description
When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times. Steps to reproduce:…
When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times. Steps to reproduce: ------------------- * Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule" * Create three products : final, semi, component - final: mtso, manufacture - semi: mtso, manufacture - component: mtso, buy, on hand quantity to 4 * Create a bom for final: - 10 components - 1 semi * Create a bom for semi: - 10 components * Create and confirm a MO for 1 "final" -> Issue the purchase order is only for 12 components and not 16. Observation: ------------- When confirming our MO, it will create a manufacture procurement for the products. The procurement will recursively create procurements and stock moves for each of its components. https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571 Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity: https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647 https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663 And each procurement, if it is of the manufacture type, will create corresponding procurements for their components. Once all the procurements and stock moves have been created, the stock move will confirmed and assigned. https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629 -> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels. opw-5514788 Forward-Port-Of: odoo/odoo#253958
This update fixes a minor issue in the website editor where the 'round corners' option would disappear when a border wasn't present. The change ensures the option remains visible regardless of border settings, improving the user experience and allowing for consistent design choices.
Original PR description
Steps to reproduce: - Open the website editor. - Select a block with the border configurator and round corners enabled. - Set the border width to 0 px. => The Round Corners option is hidden. Before this commit, the change introduced by [1] hid the option when no border was set. This restriction was not needed because a block can use a border radius without a visible border. After this commit, the option remains visible when round corners are supported, even without a border. [1]: 97e8cc8d664e66ba62e8282a67f069805682ae41 task-6089515 Forward-Port-Of: odoo/odoo#260633
This update ensures that Brazilian fiscal documents generated for EDI comply with local tax regulations. The system now incorporates approximate tax values provided by Avalara, which are legally required to be included in all documents, even when no specific tax information is available. This improves accuracy and avoids potential compliance issues.
Original PR description
All fiscal documents are required by Brazil law to include the approximate value of fed, state, and city taxes that affect it. Avalara already provides back these values in their tax calculation response, we just missed sending it to the EDI. This commit takes the information from that response and adds it to the EDI payload to make sure that it is generated properly into the generated documents. We are required to always show this even if there are no informative taxes as such we combine it with the T&C sent already. task-5478059 Forward-Port-Of: odoo/enterprise#113732
This update resolves an error that occurred when users attempted to access ticket links after an attendee was removed from an event. The fix prevents a technical error (IndexError) by gracefully handling empty attendee lists, ensuring ticket links always function correctly.
Original PR description
Currently, an error occurs when accessing the ticket link after the related attendee has been deleted. **Steps to Reproduce:** - Install the **Events** module. - Create a new event. - Create an attendee with a valid email ID. - Make sure the email is sent successfully. - Delete the attendee for the event. - From the received email, try to click on the **"View Tickets"** link. **Error:** `IndexError - tuple index out of range` **Cause:** The controller filters registrations using the provided `registration_ids`, but when the attendee is deleted, the resulting recordset becomes empty. It raises an error when trying to access the first element of an empty recordset. **Fix:** This commit handles empty recordsets by returning early when no registrations are found. sentry-7357927405 Forward-Port-Of: odoo/odoo#256310
This update resolves an issue where downloading attachments from Odoo's mobile apps was failing. The fix ensures that absolute URLs for attachments are correctly handled, preventing errors and restoring the ability to download files from the chatter interface. This improves the user experience for mobile users.
Original PR description
In Odoo 18.4+, downloading attachments from the chatter is broken.
See: https://github.com/odoo/odoo/pull/200099
The `onClickDownload` function now passes an absolute URL to `downloadFile`.
The download function is implemented natively in the mobile apps.
The Android implementation always prefixes the provided URL with the
database origin (i.e.: `https://example.odoo.com`).
`download({url: "https://example.odoo.com/web/content"})` will try to
download `https://example.odoo.comhttps://example.odoo.com/web/content`.
This results in an UnknownHostException.
We can remove the origin from the url before calling the native method.
By doing this on the JS side, there is no need to update the Android app.
opw-6033150
Forward-Port-Of: odoo/enterprise#114832This update ensures that signed documents attached to project tasks or projects are automatically saved to the project's designated Documents folder, rather than defaulting to 'My Drive'. This improves organization and consistency for users managing documents within projects.
Original PR description
Steps to Reproduce --- - Request a signature from a project task or project and complete the signing process. - In the chatter, click "Add to Documents" on the signed attachment. Issue --- Signed documents attached to projects or tasks default to "My Drive" when added to Documents, instead of using the project's configured Documents folder. Current Behaviour --- - Regular task/project attachments correctly preselect the project Documents folder. - Signed attachments fall back to "My Drive". Expected Behaviour --- Signed documents linked to projects or tasks should preselect the project's Documents folder, consistent with regular attachments. Fix --- Extend get_documents_operation_add_destination to handle sign.request attachments linked to project.task or project.project, resolving to the corresponding project Documents folder. task - 5226770 Forward-Port-Of: odoo/enterprise#105600
This update resolves a technical issue that caused the payroll system to crash when employee bank account information was incomplete. The fix ensures the system handles missing data gracefully, preventing errors and maintaining the accuracy of CFDI reports. This improves system stability and data reliability.
Original PR description
Accessing the employee bank accounts using index [0] raised an IndexError when no accounts were defined. Additionally, computing the CLABE flag using len() caused a TypeError when the account number was missing. This change uses a safe recordset slice to avoid accessing empty records and guards the length check to only evaluate when a value is present. It prevents crashes while keeping the original behavior unchanged and avoids sending invalid empty values in the CFDI. Forward-Port-Of: odoo/enterprise#113987
This update resolves an issue preventing users from exporting General Ledger reports (FEC files) when using custom date ranges. The fix ensures date ranges are properly formatted for export, preventing errors and improving report generation reliability. This ensures reports can be exported without interruption.
Original PR description
Since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 we have a custom_ranges option in the date filter. It needs to be sanitized like the other dates in order to avoid errors when JSON-serializing the options for export. Steps: - Install l10n_fr_reports and select FR Company - Activate the 'Fiscal Years' options and create one - Open the General Ledger report - Try to export the FEC file -> Traceback when validating the wizard opw-6107374
11 changes
Resolved issues and error corrections
This fix ensures that the default website correctly updates when the sequence order is changed, particularly in incognito browsing sessions. Previously, website defaults weren't refreshed after reordering, leading to incorrect website selection. The update restores a cache clearing mechanism to maintain accurate website defaults.
Original PR description
**Problem:** Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match). **Steps to reproduce:** 1. Create two…
**Problem:** Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match). **Steps to reproduce:** 1. Create two websites with no domain set 2. Change their sequence order via the handle widget in the backend 3. Open an incognito window 4. The default website shown is still the old one **Current behavior:** The default website does not change after reordering. **Expected behavior:** The website with the lowest sequence should be served as the default. **Cause of the issue:** Commit d6f4af2790a0 replaced `models.Model` with `models.CachedModel` and removed the blanket `self.env.registry.clear_cache()` from the top of `write()`. CachedModel only auto-clears caches for fields listed in `_cached_data_fields`, but `sequence` is not in that list. As a result, `_get_current_website_id` (decorated with `@tools.ormcache`) keeps returning the stale cached website ID after a sequence change. https://github.com/odoo/odoo/commit/d6f4af2790a0abacba6e616b00d999eddc30edc9#diff-5e92e473fa4d3da6db7ef727fb217dad51ef6c2383913edca73fe040a23e82c2L339-L341 **Fix:** Restoring `clear_cache()` scoped to the existing sequence/company_id check ensures the ormcache is invalidated only when relevant fields change, rather than on every write as before. opw-6102426
This update ensures that all Brazilian tax documents generated through EDI comply with local law. It incorporates approximate tax values provided by Avalara, which are now included in the EDI payload regardless of whether actual tax information is available. This ensures accurate and compliant reporting for Brazilian businesses.
Original PR description
All fiscal documents are required by Brazil law to include the approximate value of fed, state, and city taxes that affect it. Avalara already provides back these values in their tax calculation response, we just missed sending it to the EDI. This commit takes the information from that response and adds it to the EDI payload to make sure that it is generated properly into the generated documents. We are required to always show this even if there are no informative taxes as such we combine it with the T&C sent already. task-5478059 Forward-Port-Of: odoo/enterprise#113732
This update resolves an issue where creating a filter with invalid data in Odoo views would cause the application to crash. Now, the system gracefully handles these errors without a crash, although the filter itself isn't active. This improves stability and prevents disruptions to users creating and editing filters.
Original PR description
On some view, create and edit a filter, but put something unparseable by JS in the `context` field eg: `{123}`.
Go back to the view.
Before this commit there was a crash, because the python parser in JS crashed.
After this commit, there is no crash, the filter is visible but not activable.
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#260612This update fixes an issue where the 'Hide lines at 0' setting caused the Trial Balance report to omit its report-level 'Total' line when printed. The change ensures that all report totals, including the root total, are consistently displayed during printing, improving report accuracy and clarity for users.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update resolves an issue where the minimum IS (Insurance Savings) amount was incorrectly calculated in the Swiss payroll module. The fix ensures accurate IS calculations, aligning with Swiss tax regulations and improving payroll accuracy. This impacts the correct processing of employee insurance contributions.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
This update resolves a test failure related to the work order tour, specifically when users interact with form views. The fix ensures all popups are fully closed before the tour concludes, preventing data inconsistencies and improving test reliability. This enhances the overall stability of the Odoo Enterprise system.
Original PR description
**Issue** Currently, there is an async issue with the test `test_shop_floor_disable_serial_create`that may fail with the following error: "Tour finished with a dirty form view being open. Dirty form views are automatically saved when the page is closed, which leads to stray network requests and inconsistencies." **Cause** Although the tour explicitly closes all popups, the last click on the discard button may not be processed before the tour ends: https://github.com/odoo/enterprise/blob/859e65e8c267701bb19dbff9d24a8c80774dbaa6/mrp_workorder/static/tests/tours/tour_shopfloor.js#L332-L333 runbot-242504 Forward-Port-Of: odoo/enterprise#114367
This update corrects a misleading issue in the Z report generated from date ranges. Previously, the report header incorrectly displayed information for a single closed session even when data from multiple sessions (including open ones) was included. This change ensures the report header accurately represents the sessions contributing to the report's data.
Original PR description
Before this commit: - When generating a Z report via date range (config_ids, no session_ids), the header's session name was derived from the closed-session if there was exactly one, which excludes open sessions (stop_at IS NULL). - If an open session had completed orders (state='done') within the date range, those orders were included in the report body while the session itself was absent from the sessions list. - This caused the header to display the closed session's name and title the report as a single-session Z report, even though it contained data from multiple sessions. opw-6123054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259900
This update resolves an issue where deleting a project stage incorrectly navigated users to a different view and displayed archived tasks. The fix ensures the original view remains active, the stage is properly deleted, and the user's intended task list is displayed correctly. This improves the user experience when managing project stages.
Original PR description
# Steps to reproduce 1. Create a project 2. Create a stage 4. Remove the stage # Current behavior Instead of remaining in the project tasks view, it switches to the tasks view filtered with the current project. Additionally, it displays archived tasks because no filter is selected, thereby discarding original ones. This also applies to stage deletion in other views (e.g., My Tasks), where the search filters are completely discarded. # Expected behavior The dialog should be closed, the stage should be deleted, and the original view should remain active. This is done through a soft-reload of the page, ensuring the original view is kept, together with original breadcrumbs, and the stage is visually disappearing. task-5498274 Forward-Port-Of: odoo/odoo#260213 Forward-Port-Of: odoo/odoo#246935
This update resolves a crash that occurred when assigning recruiters in the Odoo Recruitment Kanban view. The issue stemmed from an unnecessary cache parameter in avatar image URLs, which caused errors due to missing data. Removing this parameter ensures the Kanban view functions correctly and reliably.
Original PR description
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The…
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The ?unique= cache related parameter was added to the avatar image URL in the autoCompleteItem slot of KanbanMany2OneAvatarEmployeeField. This parameter relies on write_date being available on the autocomplete suggestion record. However, web_name_search only returns id and display_name, so write_date is undefined on autocomplete suggestion records, causing a crash when accessing autoCompleteItemScope.record.data.write_date.ts. **Bug Solution:** Remove the ?unique= parameter from the avatar image URL in the autoCompleteItem slot, reverting it to its original form. Cache is unnecessary for autocomplete suggestion avatars as they are only visible for the duration of the dropdown interaction. **Task:** 6092768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261040
This update resolves an issue where product category images weren't showing on website B when accessed without being logged into website A. The fix ensures category images use absolute URLs, bypassing domain-based access restrictions, resulting in consistent image display across all websites.
Original PR description
Scenario: - set two website A and B with different domain - create an eCommerce category Y - create and publish a product with category Y, website B - drop category list widget in a page in website B - set in /odoo/system-parameters web.base.url to domain of website A - open the page in website B while being logged out of website A Result: the category Y image is dead. Cause: category images are using domain of "web.base.url", so if that corresponds to a website where the category is not shown (because of the access rule "Hide empty eCommerce categories to public/portal users") then the image will not be shown (unless we are a logged in internal user on the domain of "web.base.url"). Fix: use absolute URL without domain for category image, the same way it is done for other dynamic snippets (eg. Products). opw-6118004 Forward-Port-Of: odoo/odoo#260124
This update corrects a bug where the DIAN web service was incorrectly overwriting customer contact information (names and emails) with fiscal data, leading to data loss and incorrect invoice delivery. The fix now intelligently handles email differences, creating a new contact if needed and giving users control over their data.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005 Forward-Port-Of: odoo/enterprise#114017
3 changes
Resolved issues and error corrections
This update fixes an issue where the 'Hide lines at 0' setting caused the Trial Balance report to omit its report-level 'Total' line when printed. The change ensures that all report totals, including the root total, are consistently displayed during printing, improving report accuracy and clarity for users.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update resolves an issue where the minimum IS (Insurance Savings) amount was incorrectly calculated in the Swiss payroll module. The change ensures accurate IS calculations for Swiss employees, aligning with local tax regulations. This update improves the reliability of payroll reporting for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
This update fixes a problem where opening a restaurant order with an active Fiskaly transaction on a second device would cause duplicate transaction attempts and errors. The fix ensures that transaction state information is properly saved and shared between devices, preventing these errors and improving the reliability of the POS system.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#114911 Forward-Port-Of: odoo/enterprise#114599
6 changes
Resolved issues and error corrections
This update corrects a bug where the DIAN web service was incorrectly overwriting customer contact information (names and emails) with fiscal data, leading to lost sales data. The fix now intelligently handles email differences, creating a separate invoicing contact if needed and giving users control over their existing data.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005 Forward-Port-Of: odoo/enterprise#114017
This update resolves a minor issue in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission) where the minimum IS (Intermediary Swiss Franc) amount was incorrectly calculated. The fix ensures accurate reporting for Swiss tax compliance, preventing potential discrepancies and improving data integrity.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
This update resolves a problem where sales orders using products with different projects for each company would fail to process correctly through the customer portal. The fix ensures the correct company context is used when accessing company-dependent fields, preventing errors and ensuring proper order processing across multiple companies. This improves the reliability of the sales process for businesses using multiple company accounts.
Original PR description
project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup…
project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company. Following examples earlier in the function, call `.with_company` while accessing project_template_id. Steps to reproduce: 1. Install Sales and Project 2. Create second company 3. Create Customer with portal access, under created company 4. Create service product with different projects for each company 5. Create sales order with customer and service product, send to customer 6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console Ticket: opw-6082772 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#260387
This update fixes an issue where the 'Total' line was missing from reports like the Trial Balance when 'Hide lines at 0' was enabled. The change ensures that all report-level totals are always printed, improving the accuracy and completeness of financial reports. This enhancement provides a more reliable view of financial data.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update corrects a previous issue where loyalty point history records only showed the net difference between earned and spent points in a single order. The fix now accurately tracks and records both the gross amount of points earned and the gross amount of points spent, providing a more complete and reliable record of customer loyalty transactions. This ensures accurate reporting and better customer understanding.
Original PR description
When a loyalty card both earned and spent points in the same POS order, the history entry only reflected the net difference instead of the gross amounts. The root cause was that the JS payload sent only a single `points` field representing the net change. Fix by tracking `points_earned` and `points_spent` separately in `couponData` and sending them to the server. opw-6041420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258176 Forward-Port-Of: odoo/odoo#256022
This update fixes a problem in our restaurant POS system where opening an order with a connected Fiskaly transaction on a second device would cause duplicate transaction attempts and errors. The fix ensures that transaction state information is properly saved and shared between devices, preventing these errors and improving the reliability of Fiskaly integration.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#114911 Forward-Port-Of: odoo/enterprise#114599
3 changes
Resolved issues and error corrections
This update resolves an issue where the automated vendor invoice reporting process incorrectly handled multi-company setups. The fix ensures invoices are fetched from the correct company within each business, preventing errors and improving the reliability of reporting. This enhances the accuracy of financial data for businesses using multiple companies.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#113254
This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix involved updating a helper method to ensure users only see the button when they have the appropriate access, improving the user experience and preventing confusion.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#114818 Forward-Port-Of: odoo/enterprise#113481
This update corrects a previous error in Odoo's French reporting module. Accounts 657 and 757, introduced by a recent French accounting reform (PCG 2025), are now correctly classified as current operations, ensuring accurate profit and loss statements. This resolves a mismatch previously impacting financial reporting.
Original PR description
…tions As part of the PCG 2025 reform in France, accounts 657 and 757 were introduced to handle capital gains and losses on the disposal of tangible and intangible assets related to normal, current activities. Previously, Odoo incorrectly categorized these under exceptional items which led to mismatches in the P&L. Source: https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/PCG--1er-janvier-2025.pdf Relevant excerpts: <img width="630" height="372" alt="image" src="https://github.com/user-attachments/assets/88a66dac-1cc0-4a33-a902-edb6b626f18f" /> <img width="631" height="318" alt="image" src="https://github.com/user-attachments/assets/403b65dc-20ba-447e-937d-20575f1f45ab" /> opw-6105764 Forward-Port-Of: odoo/enterprise#114897 Forward-Port-Of: odoo/enterprise#114837
24 changes
Resolved issues and error corrections
This update resolves an issue where the sign request page would crash when attempting to reload a document that had been deleted. The fix ensures the system handles deleted documents gracefully by redirecting the user to a safe view, improving user experience and preventing data errors.
Original PR description
Steps to reproduce: - Open a sign request - Go to Details - Delete the document from the form view - The UI tries to reload the document Issue: The system tries to load a document that has already been deleted. Current behavior: An error is shown and the page crashes when trying to reload the deleted document. Expected behavior: The system should handle the missing document gracefully and redirect the user to a safe view. Fix: Handled the deleted document case properly by returning a valid response and redirecting the user instead of trying to load the removed document. task id- 6095120 Forward-Port-Of: odoo/enterprise#113094
This update resolves an issue where crucial fiscal data was missing from Swedish POS receipts printed from both the online and offline systems. The fix corrects the receipt template and data generation process, ensuring accurate reporting for Swedish accounting requirements. This ensures compliance and accurate record-keeping.
Original PR description
Since the receipt printing refactor that allowed printing receipts from either the frontend or backend, the fiscal data for Swedish blackbox receipts has been broken. In the frontend, the receipt prints but the blackbox data is missing from the footer. In the backend, attempting to print the receipt gives a 500 error. This commit fixes both these issues by correcting the receipt template and data generation. Community - https://github.com/odoo/odoo/pull/260587 Forward-Port-Of: odoo/enterprise#114579
This update corrects a technical issue in the IoT setup process that was preventing proper configuration. The previous default setting of an empty string has been replaced with 'False', aligning with standard Odoo field practices and resolving a software error. This ensures the IoT setup function operates correctly.
Original PR description
Due to the refactoring in odoo/enterprise#111457, the empty string was removed as an option from the IoT subtype selection. However, in the `/iot/setup` controller the empty string was explicitly used as the default value, which now causes an error due to it not being a valid option. This commit fixes the issue by instead using `False` as the default value, as is standard for Odoo fields. Forward-Port-Of: odoo/enterprise#114823
This update fixes an issue where l10n_de_reports incorrectly identified child contacts of German companies as companies themselves. The change ensures that only partners with their own distinct commercial entities (and German VAT numbers) are classified as companies, improving the accuracy of German tax reports. This resolves a potential reporting discrepancy.
Original PR description
Problem: When l10n_de_reports is installed, child contacts of a German company are incorrectly considered as companies as well. Steps to reproduce: 1. Install l10n_de_reports. 2. Create a company with a German VAT number (e.g. DE123456789). 3. Create a child contact under that company. 4. The child contact will be incorrectly considered as a company. Cause: If l10n_de_reports is installed, any partner with a German VAT number (DE + 9 digits) is considered as a company. Since child contacts share the same VAT as their company, they would be considered as companies as well, which is not correct. However, a partner should only be considered as a company if they are their own commercial entity. https://github.com/odoo/odoo/blob/e6bd6b106c376336594edd868c09505032008ac1/odoo/addons/base/models/res_partner.py#L819 Forward-Port-Of: odoo/enterprise#114600
This update removes an outdated requirement that invoices for subscription payments needed a country associated with the payment token. This restriction was causing issues with payment processing and has been resolved. The change simplifies the process and aligns with current payment provider requirements.
Original PR description
Before this commit, a country was mantadory on the payment token when it was used to pay invoices of subscriptions. This behavior was fetched back from internal code in 15.3. This issue was not visible until recently. Some token are fine without country, the provider allows it but the cron fails to process the sale order when the contract is processed. THis commit remove that old constraint. opw-5268156 task-5349998 Forward-Port-Of: odoo/enterprise#114847 Forward-Port-Of: odoo/enterprise#100166
This update resolves an issue where planned hours were incorrectly displayed on public holiday days in the project timesheet reports. The fix ensures the report accurately excludes public holidays, regardless of whether they're linked to a specific schedule, and accounts for timezone differences to prevent date shifting.
Original PR description
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to…
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to 11:59PM with a calendar - Create a planning slot for a resource that overlap with the public holiday - Check the Timesheets / Planning analysis report - Group by employees > day **- Check the date of the public holiday and notice there are still planned hours shown** - Remove the calendar from the public holidays that we created previously - Check the report once again **- Notice the day of the public holiday and the day after has no planned hours** ### Cause: In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule. Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies ### Fix: We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves. opw-5027070 Forward-Port-Of: odoo/enterprise#114757 Forward-Port-Of: odoo/enterprise#111846
This update resolves an issue where the 'Time Off Type' dropdown within the Gantt view of the Time Off app was appearing empty. The fix corrects a technical problem related to how the system initially populated data, ensuring the dropdown displays the correct options for users. This improves the user experience when creating time off requests.
Original PR description
**Steps to Reproduce:** 1. Open Time Off App->Management->Time Off->Gantt View 2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set". 3. Open the "Time Off Type"…
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown. The dropdown appears empty.
**Bug Cause:**
When forceFullDuration is true and request_duration is pre-populated in initial values, the form detects no field changes and skips triggering onchange. This prevents computed fields like allowed_work_entry_type_ids from being evaluated, resulting in an empty domain filter ('id', 'in', []).
**Solution:**
Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option.
By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the Remove the pre-population of request_duration in initial values when forceFullDuration is true. The context value force_full_duration is sufficient to filter the request_duration field to show only "full" option. By not pre-setting the value, the form detects a field change and properly triggers onchange, allowing computed fields to evaluate and populate the allowed_work_entry_type_ids correctly.
**Task:** 6109569
Forward-Port-Of: odoo/enterprise#114658
Forward-Port-Of: odoo/enterprise#114050This update resolves a technical issue that prevented a key test from running correctly, ensuring consistent test results. The change improves the reliability of our reporting processes, preventing potential disruptions to financial reporting. This ensures our financial data is more trustworthy.
Original PR description
This test, when run alone, raised an error telling assigning directly self.env.companies was not the right way of doing this, and it was better to create a new env. For some reason, it didn't raise when run together with other tests ; so, runbot didn't see the issue. This commit aims at soothing the ire of Odoo's mighty tests spirits \o/ Forward-Port-Of: odoo/enterprise#114248
This update adjusts where social media links are stored within Odoo. Previously, they were located on the website, but this has been removed. The links have now been moved to the 'res' company record to align with current website design standards.
Original PR description
Since https://github.com/odoo/odoo/pull/236918, there is no more social media fields on website so we move them to res company to comply with website. Forward-Port-Of: odoo/enterprise#114696
This update clarifies the Helpdesk stage Kanban view by removing the 'Days to Rot' number, which was confusing to users. This change improves the overall usability and understanding of the Helpdesk workflow. It addresses a previous issue where the meaning of this metric was unclear.
Original PR description
Currently, only the “Days to rot” number is displayed, so users cannot understand what the number represents. In this commit, it hide from the helpdesk stage kanban view. task-5485507 Forward-Port-Of: odoo/enterprise#114880 Forward-Port-Of: odoo/enterprise#114781
A bug was causing night shift templates to incorrectly extend shift durations by one day. This update corrects a calculation error within the shift planning process, ensuring shifts accurately reflect the intended working hours. This fix prevents over-extended shifts and improves the reliability of shift scheduling.
Original PR description
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ----------------------------------------…
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ---------------------------------------- - Create a planning shift template form 23h to 1h the next day (2h) - It must have a span over 2 working days - Create a shift and use this template - The shift spans over one more day Cause: ---------------------------------------- In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day. Solution: ---------------------------------------- We should call `plan_days()` without the hour specified so we make sure the first day is included in the count. opw-6134844 Forward-Port-Of: odoo/enterprise#114825 Forward-Port-Of: odoo/enterprise#114616
This update eliminates a misleading confirmation dialog that appeared when adding non-stockable products through the barcode app. Previously, users were prompted to confirm product location, which was unnecessary. The fix streamlines the process by leveraging existing data checks, improving usability and reducing potential user confusion.
Original PR description
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P…
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P as product > Confirm #### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there? ### Expected behavior: Since the product is not storable it should not trigger the dialog ### Cause of the issue: The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant. opw-6110655 Forward-Port-Of: odoo/enterprise#114173
This update corrects a minor issue where the company logo wasn't appearing on the journal audit export template. The fix ensures the necessary 'o_content' class is included in the template, resolving this visual discrepancy. This ensures consistent branding across financial reports.
Original PR description
before this commit, the export template of the journal audit was missing the o_content and so the company logo class was not applied opw-6128819 Forward-Port-Of: odoo/enterprise#114782
This update corrects a bug where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The issue stemmed from incorrect UUID comparisons during invoice payment reconciliation, leading to the button's persistent display. This fix ensures the button disappears as expected after batch payment processing.
Original PR description
- Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114261 Forward-Port-Of: odoo/enterprise#112520
This update corrects a display issue in the Odoo Enterprise portal. Previously, running subscriptions showed the total subscription amount in the sidebar title instead of the next billing amount. Now, users will see the correct next billing amount, providing clearer and more accurate information about their ongoing subscriptions.
Original PR description
Running subscriptions were showing the total amount in the portal sidebar title instead of the next billing amount. Display the next billing amount for running subscriptions. task-6125080 Forward-Port-Of: odoo/enterprise#114083
This update fixes a display issue in reports related to invoices and purchase orders when users are in time zones ahead of UTC. The change ensures that reports accurately reflect the order date in the user's local time, preventing missed invoices due to timezone discrepancies. This improves data accuracy and reporting reliability.
Original PR description
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC,…
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12. So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices after 12 PM. After this commit: To resolve this discrepancy we use the context_today date to get the user local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too. Steps to reproduce (Possible in runbot) : 1. Select etc/GMT-12 timezone in preferences [when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)] 2. Create a PO and Validate the quantity received. 3. Go to accounting>review>bills to receive. 4. the newly created PO won't be listed here. OPW: 6083526 Forward-Port-Of: odoo/enterprise#114763
This update resolves an issue where rental tests were unreliable due to fluctuating timezones. The change ensures a consistent UTC timezone is used for all rental tests, regardless of demo data installation. This improves test stability and reliability.
Original PR description
When demo data is installed, Robodoo's timezone is set to Europe/Brussels. Rental tests expect the environment timezone (`self.env.tz`) to be UTC. However, if Robodoo is the current user and no timezone is set in the context, the environment falls back to the user's timezone. Because Robodoo's timezone changes depending on whether demo data is installed, tests can become unstable. This commit updates the renting app's common test setup to ensure a stable timezone. runbot-242821 Forward-Port-Of: odoo/enterprise#114645
This update resolves an issue where attachments couldn't be downloaded from the Odoo chatter on mobile devices (Odoo 18.4+). The fix ensures that URLs are correctly formatted for download, preventing errors and restoring the ability to access attachments. This improvement impacts mobile users' ability to retrieve files.
Original PR description
In Odoo 18.4+, downloading attachments from the chatter is broken.
See: https://github.com/odoo/odoo/pull/200099
The `onClickDownload` function now passes an absolute URL to `downloadFile`.
The download function is implemented natively in the mobile apps.
The Android implementation always prefixes the provided URL with the
database origin (i.e.: `https://example.odoo.com`).
`download({url: "https://example.odoo.com/web/content"})` will try to
download `https://example.odoo.comhttps://example.odoo.com/web/content`.
This results in an UnknownHostException.
We can remove the origin from the url before calling the native method.
By doing this on the JS side, there is no need to update the Android app.
opw-6033150
Forward-Port-Of: odoo/enterprise#114832This update resolves a problem preventing access to demo data within the accounting module, specifically when demo companies are created. The fix changes how demo user accounts are handled to ensure consistent access across all company templates, addressing a conflict caused by recent code changes related to caching.
Original PR description
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com…
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com trials due to the user seat limit probably) 3. Select the demo company only (unselect the main one) 4. Open Accounting and click the Purchases journal from the dashboard Access Error about reading Marc Demo. Unarchiving him would work around this issue. Why the bug ----------- demo_invoice_deferred and demo_bill_deferred set invoice_user_id to Marc Demo (base.user_demo). Marc Demo belongs to the main company and can't be read from another company when archived. On 19.0 these records only existed in the main company, where Marc Demo is accessible. Commit 9aed0c0135d7b084dee544c6566fad96c62ec1fd migrated the demo to `template`, so now they are created in every company. Still, it only breaks because of commit [3732ca85b03b](https://github.com/odoo/odoo/commit/3732ca85b03b), which added write_date to the avatar widget for cache busting. Before, the widget only needed display_name (read with sudo), so the rule was not checked. The fix ------- Use base.user_admin for demo_invoice_deferred (never archived, stays readable from any company), and False for demo_bill_deferred (a bill has no salesperson). opw-6106870 Forward-Port-Of: odoo/enterprise#113946
This update ensures that VAT numbers in the VIES summary reports are formatted correctly, removing the country code. This is necessary to comply with Czech tax regulations and generate reports that meet official VIES XML requirements, preventing potential reporting errors.
Original PR description
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable…
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable it from the optional columns if needed). - Navigate to Reporting > VIES Summary Report. - Observe the value in the `VAT Number` column (includes country code). - From the dropdown, export the report as XML. **Observation:** In the generated XML file, the `c_vat` field contains the VAT number including the country code (e.g., `CZ12345679`) instead of only the numeric part (`12345679`). **Root cause:** At [1], the VAT number is directly taken from the report lines without removing the country code. **Fix:** This commit ensures that the `c_vat` field contains only the VAT number without the country code, complying with the official VIES XML format requirements. Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part) [1]: https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62 opw-6093259 Forward-Port-Of: odoo/enterprise#114990 Forward-Port-Of: odoo/enterprise#113083
This update resolves an issue where chatter message highlights were appearing unexpectedly on the employee form in the HR payroll module. The change restricts these highlights to only the 'review_state' field, improving the user experience and preventing unnecessary visual distractions. This ensures a cleaner and more focused interface for HR professionals.
Original PR description
The dropdown_selection_badge widget was triggering chatter message highlights on hover for all its usages (e.g. Dimona). Add an opt-in highlight_chatter attribute so only the review_state field on the employee form triggers this behavior. task-6131035 Forward-Port-Of: odoo/enterprise#114138
This update corrects a recent change that removed the currency field from batch payment records. This ensures that monetary amounts are accurately associated with their correct currency, preventing potential accounting errors. The fix improves the reliability of financial reporting within the Enterprise module.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/301f63597b0c21fef16a1941314ac95602c8f01f removed some currency id field from the account bank statement and so the monetary field didn't have the currency anymore task-6131298 Forward-Port-Of: odoo/enterprise#115017 Forward-Port-Of: odoo/enterprise#114369
A recent update caused crashes in the Self-Ordering and Mobile Menu (QR ordering) interfaces. This fix corrects a naming issue within the POS data loading process, ensuring these key features now function correctly. The change updates a field name to align with the current system, resolving the loading errors.
Original PR description
## Overview Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS…
## Overview Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS data loading flow. ## Steps to Reproduce 1. Install `pos_blackbox_be` 2. Open POS 3. Access the Mobile Menu (QR code) or Self-Ordering page ## Current Behavior - A traceback is raised - The interface does not load ## Root Cause The method `_load_pos_self_data_fields` returns the field: iface_fiscal_data_module However, from SaaS-19.1 this field was renamed to: iot_fdm_be_id This mismatch causes the POS self-ordering data loading to fail. ## Fix Updated the returned field to match the new field name. # Before return fields + ['iface_fiscal_data_module'] # After return fields + ['iot_fdm_be_id'] ## Impact - Restores proper loading of Mobile Menu (QR ordering) - Fixes Self-Ordering interface crash opw-6044883 ## Reproduction Video https://drive.google.com/file/d/1R5TYVIXvtts12YLF5iB4GKZirMZePoGr/view?usp=sharing Forward-Port-Of: odoo/enterprise#114357
This update ensures that Brazilian tax documents (EDI) accurately reflect tax amounts provided by Avalara, as required by Brazilian law. Previously, this information was missing, and now it's automatically included in all generated documents, regardless of tax information, to maintain compliance.
Original PR description
All fiscal documents are required by Brazil law to include the approximate value of fed, state, and city taxes that affect it. Avalara already provides back these values in their tax calculation response, we just missed sending it to the EDI. This commit takes the information from that response and adds it to the EDI payload to make sure that it is generated properly into the generated documents. We are required to always show this even if there are no informative taxes as such we combine it with the T&C sent already. task-5478059 Forward-Port-Of: odoo/enterprise#113732
4 changes
Resolved issues and error corrections
This update corrects a bug where the DIAN web service was incorrectly overwriting customer contact information (names and emails) with fiscal data, leading to data loss and incorrect invoice delivery. The fix now preserves commercial contact details, creating a separate invoicing contact only when the DIAN email address differs, giving users control over their data and preventing future issues.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005 Forward-Port-Of: odoo/enterprise#114017
This update fixes an issue where the 'Total' line was missing from printed Trial Balance reports when 'Hide lines at 0' was enabled. The change ensures that all report-level totals, including the root total, are consistently printed, improving report accuracy and usability.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update corrects a flaw in how overtime entries are identified, which previously led to duplicate entries being created. The change ensures overtimes are accurately calculated based on the correct time range, regardless of timezone settings. This improves the reliability of overtime tracking and reporting.
Original PR description
This function searches for overtimes by the date of hr.attendance.overtime.line. This is simply a date and can lead to problems if not using the UTC timezone. Steps to reproduce: 1. Set timezone to…
This function searches for overtimes by the date of hr.attendance.overtime.line. This is simply a date and can lead to problems if not using the UTC timezone.
Steps to reproduce:
1. Set timezone to anything ahead of UTC (Europe/Chisinau) (Not required, but helps)
2. Create a new employee
3. Set the Contract
4. Set Work Entry Source to Attendances
5. Set the timezone of Working Hours to anything ahead of UTC (Europe/Chisinau)
6. Create an attendance for the employee that causes overtime (default anything over 8 hours)
7. Two work entries will be created. One for the default time and one for the overtime.
8. Create an attendance for the next day (no need for overtime)
9. Alter the Check Out time
10. Duplicate overtime work entry created for the day prior
Example:
Searching for Overtimes on April 17th.
date_start = datetime(2026, 4, 17, 0, 0)
date_stop = datetime(2026, 4, 17, 23, 59, 59, 999999)
Translated from Europe/Chisinau time (3 hours ahead):
date_start = datetime(2026, 4, 16, 21, 0)
date_stop = datetime(2026, 4, 17, 20, 59, 59, 999999)
start/stop times are cut to dates as overtime.line.date is just a Date:
start_naive.date() = date(2026, 4, 16)
end_naive.date() = date(2026, 4, 17).
Then, given the domain:
('date', '<=', end_naive.date()),
('date', '>=', start_naive.date()),
Result: all overtimes on April 16th and 17th returned.
This commit aims to change the function to truly return overtimes between the given datetimes (start_dt, end_dt)
opw-5952995This update resolves an issue where the minimum IS (Insurance Savings) amount was incorrectly calculated in the Swiss payroll module. The fix ensures accurate IS calculations for employees, aligning with Swiss tax regulations. This improves payroll accuracy and compliance for businesses using the Odoo Enterprise solution.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
4 changes
Resolved issues and error corrections
This update resolves an issue where the minimum IS (Investment Savings) amount was incorrectly calculated in the Swiss payroll module. The change ensures accurate reporting of IS contributions for Swiss employees, aligning with local tax regulations. This improves the reliability of payroll data and compliance.
Original PR description
Forward-Port-Of: odoo/enterprise#114463
This update fixes an issue where the 'Total' line was missing from reports like the Trial Balance when 'Hide lines at 0' was enabled. The change ensures that all report totals are correctly printed, providing a more complete and accurate view of financial data.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update simplifies the process for creating Unsplash attachments, reducing code complexity and improving security. Previously, broad access rights were required, but now only the necessary permission to set the attachment URL is granted, ensuring better control over data access.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#261056
This update significantly improves the speed of importing large XML bills, particularly those received via Peppol or manual upload. By optimizing the database queries and update processes, the upload time has been reduced from failing to a manageable 11 minutes for a large bill. This enhances efficiency for accounting operations.
Original PR description
### Description: The upload and import process for large XML bills via Peppol or manual upload was inefficient due to two primary bottlenecks. First, the system performed individual queries per line to match products, taxes, and accounts, leading to an N+1 query issue. Second, multiple write operations were executed on each line to update various fields. This commit introduces batching and improve caching for these operations to reduce database call. ### Benchmark: | N° of lines | Before | After | |-------------|---------|-------| | 30264 | Timeout | 11min | ### Reference: opw-5416612
2 changes
Resolved issues and error corrections
This update fixes a previous issue where the General Ledger report displayed journal items out of order, primarily grouped by company instead of date. Now, transactions are correctly sorted by date across all companies, providing a much clearer and more accurate chronological view of financial activity. This improves reporting accuracy and simplifies financial analysis.
Original PR description
### Issue before this commit: Before this commit, the General Ledger report did not correctly order journal items when a company and his branch were involved. Even when entries had different dates,…
### Issue before this commit: Before this commit, the General Ledger report did not correctly order journal items when a company and his branch were involved. Even when entries had different dates, the lines were grouped and displayed primarily by company, resulting in a non-chronological view. ### Steps to reproduce the issue: 1. Download Accounting 2. Create a company branch for your actual company 3. Create 4 invoices (2 for the company with different dates and 2 for the branch with same dates as the company's invoices) 4. Open General Ledger and see that under the account's group the order is per company and not per date ### Cause of the issue: The issue was caused by the SQL query used to retrieve account move lines in the General Ledger (PR that introduce the bug: https://github.com/odoo/enterprise/pull/107638) Specifically, the ORDER BY clause prioritized company-related fields before the transaction date. As a result, the sorting logic first grouped entries by company and only then applied date ordering within each company group, instead of performing a global chronological sort. ### Reason to introduce the fix: The fix ensures that journal items are primarily ordered by date across all companies, providing a correct chronological view of transactions. ### Fix details: It's not possible to reorder the attributes in the ORDER BY clause without braking the test test_general_ledger_export_csv_multi_comp so it has been decided to create this trick to solve only the bug in the visualization of the General Ledger report leaving the bug in the export of csv. opw-6000740
This update fixes an issue where styled headings in the table of content weren't correctly translated when switching languages. The fix ensures that changes to the table of content are also saved, allowing for consistent translation across all languages. This improves the user experience and ensures accurate content display.
Original PR description
Scenario: - drop table of content snippet in a page - in a title (present in the table of content) add some styling such as bold / color - in a secondary language, change the translation of that header - save Result: the heading in the table of content is not translatable. Cause: the table of content entry is translated by translating the corresponding heading. When the heading is changed, it is synced to the table of content entry with the inline style removed. But when we save, we only save the dirty node so we are only saving the original heading. But since the heading translation doesn't match the table of content entry (because the style tag removal), only the heading translation is updated. Fix: when the table of content entry is updated, set it as o_dirty so it is also saved. opw-5413915 opw-5926501