Daily updates from Odoo
Thursday, June 25, 2026
108 changes
21 changes
Enhancements to existing features
This update introduces a new automated process that runs every Sunday to reset configuration settings related to development tools (devtools). This ensures that features temporarily disabled for production environments are automatically re-enabled before the weekly update on Monday, streamlining the update process.
Original PR description
We add a new cron to re enable disabled features by unsetting devtools keys in configuration. This cron is meant to run every sunday at the end of the day, right before the monday update. Forward-Port-Of: odoo/odoo#270306
Resolved issues and error corrections
This change removes an unnecessary price check from the Peru POS refund test tour. It matters because the tour could fail when the POS configuration currency differed from the company currency, even though the price was not relevant to the workflow being tested.
Original PR description
Before this commit, the tour was checking the price of an article which was not the good one since the currency of the config was not the same as the company one. This commit removes the check of the price which is not even relevant for the tour.
The self-invoicing URL shown on point-of-sale receipts is now generated correctly instead of appearing as an invalid link. This helps customers access their invoice request page without confusion or extra support.
Original PR description
Before this commit: ------------------------- - The self-invoicing URL on the receipt was displayed as `undefined/pos/ticket`. After this commit: ------------------------- - The self-invoicing URL is now generated correctly and displayed properly on the receipt. Task-6271261 Forward-Port-Of: odoo/odoo#271762 Forward-Port-Of: odoo/odoo#270052
This change makes a website test tour wait for the correct element before starting a drag-and-drop action. It prevents occasional test failures caused by the tour acting on the wrong target, improving reliability of website testing.
Original PR description
The tour `conditional_visibility_4` has non-deterministic failure, that appears to be caused by the `drag_and_drop` step dragging the element that was the target before the click of the previous step. This commit adds a step to ensure the target is the expected element before the "drag" step starts. runbot-242425 Forward-Port-Of: odoo/odoo#271760
The Mozambique demo company now uses a valid NUIT number. This prevents validation errors when newer standard number checks are applied, helping demo data load correctly and avoiding build failures.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
This update fixes an issue where rental prices weren't correctly formatted on the website, appearing without the necessary slash separator. The fix ensures that rental prices and durations are displayed clearly and accurately, improving the user experience for customers renting products. This resolves a visual inconsistency.
Original PR description
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product…
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product on the website. - Open the product page on the website and click` Add to Cart`. Issue: --- - In the product configurator, the rental price is displayed without the `/` separator between the price and the rental duration period. Cause: --- - The string used to generate the rental duration label does not include the `/` separator. Fix: --- - Add the missing `/` separator to the rental duration label so that rental prices are displayed correctly. Before: --- <img width="974" height="185" alt="image" src="https://github.com/user-attachments/assets/64a88a60-bcc0-4657-97fd-584da57d0aff" /> After: --- <img width="967" height="188" alt="image" src="https://github.com/user-attachments/assets/b4d50019-1db4-4817-a8ce-446cc3c55df4" /> opw-6293015 Forward-Port-Of: odoo/enterprise#121246 Forward-Port-Of: odoo/enterprise#120223
This update fixes an issue where customer addresses in the Field Service kanban view would be cut off and displayed incorrectly due to a design element that didn't properly constrain the address width. The fix ensures that long customer addresses now fit neatly within the kanban card, improving readability and usability. This improves the visual presentation of customer information.
Original PR description
Steps to reproduce: - 1. Open the Field Service planning view in kanban. 2. Make sure a shift's customer has a long address (long street lines). 3. Look at that shift's card in the kanban view. Issue: - The customer address overflows the card and is clipped at its right edge instead of staying within the card boundaries. Cause: - The customer is rendered with the `many2one` widget and `show_address`, which marks each address line `text-truncate`. Truncation only works inside a width-bounded container, but the field root `.o_field_many2one` is an inline-flex item with the default `min-width: auto`, so it grows to fit the longest address line instead of shrinking to the card. As a result, `text-truncate` never engages and the address spills past the card. Fix: - Add the `min-w-0` class to the partner field so the flex item shrinks to the available card width. task-6272209 Forward-Port-Of: odoo/enterprise#119248
This update fixes an issue where the sandwich rule incorrectly excluded public holidays from leave calculations. Now, when 'Include Public Holidays as Working Day' is selected, the system accurately determines the correct leave duration, including weekend days as part of the calculation. A new test case has been added to ensure this fix works as expected.
Original PR description
Problem: When a time off type is configured with "Include Public Holidays as Working Day", the sandwich rule was still treating public holidays as non-working days. This caused the sandwiched weekend days to not be included in the leave duration. Example: Employee applies leave from May 15 (Friday, Public Holiday) to May 18 (Monday). Expected duration is 4 days since May 15 is a working day and May 16-17 (weekend) should be sandwiched. Instead, only 1 day was calculated. Fix: Now when "Include Public Holidays as Working Day" is enabled, the correct number of days are calculated in the sandwich rule. Also added a test case to verify that public holidays are correctly treated as working days during sandwich rule evaluation. Task-4570118 Forward-Port-Of: odoo/odoo#271261 Forward-Port-Of: odoo/odoo#266624
This update ensures the Clickall tool, used for automated accounting dashboard testing, correctly handles the new version 2 (v2) of Odoo Fin's favorite institutions endpoint. By adding a mock, we prevent the tool from making direct requests to production servers, maintaining a safe and isolated testing environment.
Original PR description
This commit follows up on [1] by extending the Odoo Fin request mock to cover the new version 2 (v2) favorite institutions endpoint. Previously, a mock was introduced to prevent the Clickall tool from making real external HTTP requests to `production.odoofin.com` when displaying the accounting dashboard. This update ensures that the newly introduced v2 URL is also safely intercepted, keeping the automated tests fully isolated from production servers. runbot-234936 [1] : https://github.com/odoo/odoo/commit/c6451015f1b01c3e1defe4a576989fd4bfdf2cdb Forward-Port-Of: odoo/odoo#271804
This update fixes a previous issue where commission losses were incorrectly calculated for employees on long-term sickness or partial incapacity leave. The change ensures that these employees are not subject to commission deductions, aligning with standard payroll practices. This update improves accuracy and fairness in commission calculations for a specific employee group.
Original PR description
Partial incapacity and long term sickness are not elligible to loss on commissions. Forward-Port-Of: odoo/enterprise#121514
This change optimizes the automated posting of invoices by preventing the cron job from repeatedly rescheduling entire batches when individual invoices fail to post. Previously, a batch failure triggered thousands of unnecessary retries. Now, failed invoices are simply marked as unpostable, reducing system load and improving performance.
Original PR description
Before this change, cron jobs triggering `_autopost_draft_entries` would gracefully handle batch-level failures by logging the error and retry one by one. As a result, `_process_job`, with success 0 done and remaining number, marked the cron run as partially completed and triggered `_reschedule_asap`. When a batch contained only problematic records, the cron job could be rescheduled thousands of times per day. With this change, if a move in the batch fails to post, we set its `auto_post` to `no`, together with the existing message-posting logic in the chatter, to prevent repeated retries for failed records. Related ticket: opw-6303194 opw-5364851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271509
This update fixes a visual bug where outdated cluster bubbles remained visible on the company map after zooming or panning. The issue stemmed from a technical error in how the map library handled removing old cluster icons. This change ensures that clusters are properly updated and removed, providing a cleaner and more accurate map display for users.
Original PR description
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times…
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times => stale blue cluster bubbles remain on the map Cause: ====== On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level. `ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map, https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation. Solution: ========= Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon. opw-6128531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270733
This update resolves a problem where the Italian POS fiscal printer would intermittently stop printing orders due to unsupported characters in product or payment method names. The fix replaces these characters with spaces, ensuring complete and accurate printing of fiscal receipts, as outlined in official EPSON documentation.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089) Forward-Port-Of: odoo/enterprise#121538 Forward-Port-Of: odoo/enterprise#120169
This update resolves an issue where attendees received duplicate emails when rescheduling meetings. The fix prevents a nested calendar event write, which was causing the original and subsequent updates to trigger multiple notifications. This ensures attendees only receive one notification for meeting date changes.
Original PR description
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a…
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a meeting activity using the calendar. 5. Add the created contact as an attendee of the meeting. 6. Return to the lead and click the Reschedule button on the activity. 7. Select the same meeting and change its start date to a future date. Issue: - Attendees receive the meeting date-change email twice. Root cause: - When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event. https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779 https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33 - This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails. Solution: - Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling. opw-6209956 Forward-Port-Of: odoo/odoo#269950 Forward-Port-Of: odoo/odoo#266675
This update fixes a display issue in the Helpdesk module where ticket labels in list and form views didn't match the labels shown in the Kanban view. The fix removes outdated label fields from the views, ensuring all ticket views show the correct, up-to-date state selections.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707This update resolves an issue where users without fleet access could not import UBL invoices referencing vehicles. Now, users with vendor bill import permissions can successfully import UBL invoices containing vehicle references, improving data import flexibility. This ensures accurate recording of transactions regardless of user access rights.
Original PR description
When a user has no rights to access the fleet models but is allowed to import vendor bills, he should be able to import a bill (UBL) with referenced vehicle(s) inside. task-6289956 Forward-Port-Of: odoo/odoo#269447
This update resolves a bug where JSON data couldn't be displayed when clicked in the l10n_in_edi module. The issue stemmed from a change in how binary fields handle data, requiring a conversion to the correct binary format. Now, JSON data is correctly displayed.
Original PR description
**Description of the issue this PR addresses:** This issue was introduced after the refactoring of binary fields [odoo/odoo#244421](https://github.com/odoo/odoo/pull/244421) ,where Binary fields now expect proper binary data and treat string values as base64. The JSON data was passed as a string to a binary field. After the BinaryValue change, this string was treated as base64, which caused a decoding error. **Before this Commit:** Clicking the JSON button resulted in an error: `binascii.Error: Only base64 data is allowed` Due to this, the JSON data could not be viewed. **After this Commit:** JSON data is now converted into the correct binary format using Odoo’s binary handling `(odoo.tools.Binary)` and it displays correctly. [Related Commit](https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1#diff-d3b35dffff8313ee07a08bceb336f03d6130bf001e3b0daa32b098cefcf95c3b) [Full Error Details ](https://pastebin.com/v12sD2vf)
This update resolves a technical issue that could cause errors in the planning module when start and end dates are not specified. By adding a check, the system now avoids attempting planning operations when this critical information is missing, ensuring smoother and more reliable planning processes. This improves the overall stability of the Enterprise version.
Original PR description
Add a guarding condition to the auto-plan or send behavior to avoid doing those operations when no start/end dates are defined --- Task-6312650
This update resolves a potential issue during Odoo upgrades where errors could occur when rules were being processed. The fix prevents errors when fields needed for rule evaluation aren't immediately available, ensuring smoother and more reliable upgrades. This improves the overall stability of the Odoo system.
Original PR description
In a [recent fix], the `_get_all_rules()` method was changed to skip the models that are not yet loaded (during upgrades). However, some rules can be added to an existing model by another module. In that case, the rule is processed even though the fields used in that rule are not yet loaded. This leads to a traceback during upgrades because `optimize()` is trying to access those fields. This commit adds the rule without pre-evaluating it if an `ValueError` is raised during the optimization step. [recent fix]: https://github.com/odoo/odoo/pull/267676
This update resolves a bug in the testing process for SEPA Direct Debit payments. The test was failing because the payment status was incorrectly identified as 'reconciled' instead of 'paid'. This change ensures the payment is validated only when it's in the correct 'paid' state, improving test reliability.
Original PR description
The `test_expiry` test creates a payment via the `pay_with_mandate` method. Depending on eg. the installed modules, the resulting payment ends up either `paid` or `reconciled`. Afterwards, the test tries to validate the payment, which requires that it not be in the `reconciled` state. This causes an error linked below. This PR adds a condition to ensure the payment is in the `paid` state before attempting to validate it. Error: https://runbot.odoo.com/odoo/error/240557 Forward-Port-Of: odoo/enterprise#112224
This update fixes a minor issue within the Odoo composer tool that prevented users from correctly placing the cursor at the end of lines when adding mentions. The fix adds a special character to ensure proper browser handling of text editing, improving the user experience. This ensures users can accurately format their messages.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271802 Forward-Port-Of: odoo/odoo#269699
15 changes
Enhancements to existing features
This update reduces unnecessary error noise when checking connected devices that are not the expected type. It also makes the code more precise and easier to maintain, which helps keep logs clearer for support and operations teams.
Original PR description
We remove the stack trace from the exception reading FDM response to avoid polluting the logs when probing non FDM ports. We also now catch a more precise `IndexError` instead of `Exception` as it wasn't necessary to catch this wide. We also caught the opportunity to ruff the file.
Resolved issues and error corrections
The Mozambique demo company now uses a valid NUIT tax number. This prevents validation errors in updated standard number checks and keeps demo data working correctly.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
This update resolves a technical issue preventing the Spanish E-Invoice module (l10n_es_edi_verifactu) from functioning correctly during upgrades. The fix ensures the necessary 'certificate' module is loaded first, preventing a critical error that blocked the module's operation. This ensures a smoother upgrade process and correct functionality for users utilizing the Spanish E-Invoice feature.
Original PR description
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to…
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises: ``` TypeError: Model 'certificate.certificate' does not exist in registry. ``` ### Cause `models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`. ### Notes - Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op. - Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first. Forward-Port-Of: odoo/odoo#271827 Forward-Port-Of: odoo/odoo#271496
This update resolves an issue where outdated cluster bubbles remained visible on the company map after zooming or panning. The fix corrects a technical error in how the map's cluster icons were managed, ensuring that old icons are properly removed when the map updates. This improves the visual clarity and accuracy of the map for users.
Original PR description
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times…
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times => stale blue cluster bubbles remain on the map Cause: ====== On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level. `ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map, https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation. Solution: ========= Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon. opw-6128531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270733
This update ensures the Clickall tool, used for automated accounting dashboard testing, correctly handles requests to the new Odoo Fin v2 favorite institutions endpoint. By extending the existing request mock, we maintain isolation from production servers and prevent potential issues during testing, ensuring reliable automated test results.
Original PR description
This commit follows up on [1] by extending the Odoo Fin request mock to cover the new version 2 (v2) favorite institutions endpoint. Previously, a mock was introduced to prevent the Clickall tool from making real external HTTP requests to `production.odoofin.com` when displaying the accounting dashboard. This update ensures that the newly introduced v2 URL is also safely intercepted, keeping the automated tests fully isolated from production servers. runbot-234936 [1] : https://github.com/odoo/odoo/commit/c6451015f1b01c3e1defe4a576989fd4bfdf2cdb Forward-Port-Of: odoo/odoo#271804
This update resolves an issue where event titles were sometimes saved as blank ('(no title)') when created quickly through the calendar. The fix ensures that all event data, including the title, is saved correctly, regardless of how the event was created. This improves the user experience and prevents data inconsistencies.
Original PR description
When creating an event using the quick create form from the calendar view if the user saves the record while the title is still being edited (using alt+c) the record will be saved with the default title: "(no title)" The code currently relies on the record data being up to date by the time onRecordSave is reached. However in the case of a text field, it is only saved when blurred. While there is a mechanism to blur the field when saving using a hotkey, it is completely asynchronous from the save logic of the form. To ensure all fields have comitted their data at save time, the framework has a mechanism to "request changes" which notifies all fields to update the record with their latest value and waits for them to do so. We can simply reuse this mechanism to ensure the data is up to date at recordSave time already, as we don't expect fields to have any changes after it. task-6321702 Forward-Port-Of: odoo/odoo#271473
This update fixes an issue where the composer in Odoo (used for creating emails) wasn't correctly handling text editing after inserting mentions. Specifically, it added a small character (a zero-width no-break space) to ensure the cursor moved to the end of the line, improving the user experience. This ensures users can accurately edit and format their emails.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271160 Forward-Port-Of: odoo/odoo#269699
This update resolves an issue where a key feature of our website tours was intermittently failing. The fix ensures the tour correctly identifies the target element before the drag-and-drop action, making the tour more reliable and consistent for users. This improves the overall user experience.
Original PR description
The tour `conditional_visibility_4` has non-deterministic failure, that appears to be caused by the `drag_and_drop` step dragging the element that was the target before the click of the previous step. This commit adds a step to ensure the target is the expected element before the "drag" step starts. runbot-242425
This update resolves a bug where the 'Suggest Forecasted Demand' button disappeared when the 'Forecasted Stock' row was hidden in the Master Production Schedule. This ensures the button is always visible, allowing users to accurately adjust forecasted demand. This fix improves the usability of the planning module.
Original PR description
Steps to reproduce:
1. Install Manufacturing.
2. Enable 'Master Production Schedule' in the Settings.
3. Go to [Manufacturing -> Planning -> Master Production Schedule].
4. Ensure 'Demand Forecast' and 'Forecasted Stock' rows are enabled from the dropdown.
5. Observe the edit pencil button next to 'Forecasted Demand' is visible.
6. Hide 'Forecasted Stock' using the rows filter dropdown.
Issue:
The edit pencil button ("Suggest Forecasted Demand") next to the 'Forecasted Demand' row disappears when the 'Forecasted Stock' row is hidden.
Expected behavior:
The edit pencil visibility should not be affected by the 'Forecasted Stock' row.
opw-6240596
Forward-Port-Of: odoo/enterprise#120208This update fixes an issue where quality alerts weren't created when receiving inbound emails without a company assigned. The fix ensures that a default company ID is used, preventing errors and guaranteeing that all email-based quality alerts are properly recorded. This improves the reliability of our quality tracking system.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#118516 Forward-Port-Of: odoo/enterprise#109947
This update ensures that all tax unit members, not just the main company, have read access to tax return checks. This allows for quicker resolution of issues related to failing checks, improving overall operational efficiency and reducing potential delays.
Original PR description
Before this commit: Tax Unit Members other than main company have read access to tax returns but don't have read access to tax return checks. After this commit: Tax Unit members other than main company are given read access to tax return checks also, so they can fix checks failing because of them. task-5951364 Forward-Port-Of: odoo/enterprise#113118
This update fixes a display issue in the Helpdesk module where ticket labels in list and form views didn't match the labels shown in the Kanban view. The fix removes outdated label fields from the views, ensuring all ticket views now accurately reflect the selected state values. This improves consistency and clarity for users.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707This update fixes a display issue where the Incoterm (shipping term) wasn't showing on purchase quotation reports. After a recent code update, the fix ensures that this important information is now correctly presented, improving clarity for purchasing teams. This ensures accurate reporting and better understanding of shipping costs.
Original PR description
After a refactor the incoterm and location didn't show on the purchase quotation Task-id: 6206523
This update fixes an issue where custom inline shadows weren't correctly recognized by the HTML builder, leading to incorrect shadow displays. Now, elements with inline shadows are properly detected, and cleaning custom shadows also removes Bootstrap shadow classes. This ensures consistent and accurate shadow rendering across Odoo.
Original PR description
Before this PR, , since [1], elements with an inline `box-shadow` and no custom shadow class were not detected as custom shadows by the builder option. This could make existing snippets show the wrong shadow state. After this PR, elements with an inline `box-shadow` are treated as custom shadows by the builder option, and cleaning the custom shadow also removes Bootstrap shadow classes. [1]: https://github.com/odoo/odoo/commit/55890082db7879bef3a976c84ab336bdacf76818 task-6251151
This update resolves an issue where the CoA reload process could inadvertently create duplicate reports. The CoA framework is now responsible for managing existing records, ensuring data integrity and preventing redundant report generation. This change improves system efficiency and accuracy.
Original PR description
It is the burden of the CoA framework to check for that. See community commit for more information. Forward-Port-Of: odoo/enterprise#121643
11 changes
Enhancements to existing features
The check status button is now disabled for users who do not have permission to update the check. This prevents access errors when the main company is not selected and makes the experience clearer and smoother for users.
Original PR description
Before this commit: Only main company of tax unit have write access on check, so when main company is not selected and user tries to change status of check, access error is thrown. After this commit: Disable check status button if user don't have write access on check. task-5951364
This update improves how dialogs are styled so the browser does less work when the page is resized, scrolled heavily, or sorted in tables. The result is smoother performance and quicker visual updates without changing the user experience.
Original PR description
Avoid using the :has() selector and use a specific style on the `documentElement` instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase. It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The mailing theme selector now refreshes both the title and the preview when switching between favorite templates for different target models. This prevents users from seeing a mismatched preview and helps them choose the right mailing template more reliably.
Original PR description
Overview ------ When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first…
Overview ------ When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first show the template X with the correct title and preview, however when switching to model Y, the theme selector will show the title of the tempalte Y but the preview is always the one of template X. How to reproduce ------ 1. Create a new mailing for a target model X (e.g. `mailing.contact`) 2. Set a content for that mailing (you can choose from the existing themes) 3. Set that mailing as a favorite (using the favorite star button) 4. Create a new mailing for another target model Y. 5. Redo steps 2. and 3. 6. Create a new mailing, and set the target model to X (You should see the mailing X in the theme selector with the correct title and preview) 7. Change the target model to Y. Expected Behavior ------ Both the title and the preview of the mailing X in the theme selector should change into the title and the preivew of mailing Y. Current Behavior ------ The title of the template is changed into the one of Y however the preview remains the one of mailing X. Cause of The Issue ------ After the first mount of the `FavoritePreivew` component, when the template changes in the props, the body content of the preivew is not updated with the new value. Task-6332946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The page limit note in the website generator has been updated to use more general wording instead of a fixed number. This gives the system more flexibility to adjust page limits later without misleading users.
Original PR description
Page limit note fixed by being more general instead of stating a blatant 200. This gives us more leeway to control the nbr of pages IAP side.
This update extends an existing test safeguard so the accounting dashboard checks also block the newer Odoo Fin v2 endpoint. It helps keep automated tests fully isolated from live services, reducing the risk of unintended external requests during testing.
Original PR description
This commit follows up on [1] by extending the Odoo Fin request mock to cover the new version 2 (v2) favorite institutions endpoint. Previously, a mock was introduced to prevent the Clickall tool from making real external HTTP requests to `production.odoofin.com` when displaying the accounting dashboard. This update ensures that the newly introduced v2 URL is also safely intercepted, keeping the automated tests fully isolated from production servers. runbot-234936 [1] : https://github.com/odoo/odoo/commit/c6451015f1b01c3e1defe4a576989fd4bfdf2cdb Forward-Port-Of: odoo/odoo#271804
The Forecasted Demand edit button now stays visible even when the Forecasted Stock row is hidden in Master Production Schedule. This fixes a confusing display issue so users can still access forecast suggestions without changing unrelated row visibility.
Original PR description
Steps to reproduce:
1. Install Manufacturing.
2. Enable 'Master Production Schedule' in the Settings.
3. Go to [Manufacturing -> Planning -> Master Production Schedule].
4. Ensure 'Demand Forecast' and 'Forecasted Stock' rows are enabled from the dropdown.
5. Observe the edit pencil button next to 'Forecasted Demand' is visible.
6. Hide 'Forecasted Stock' using the rows filter dropdown.
Issue:
The edit pencil button ("Suggest Forecasted Demand") next to the 'Forecasted Demand' row disappears when the 'Forecasted Stock' row is hidden.
Expected behavior:
The edit pencil visibility should not be affected by the 'Forecasted Stock' row.
opw-6240596
Forward-Port-Of: odoo/enterprise#120208This change prevents the system from creating empty draft manufacturing orders for products that have no bill of materials. In these cases, replenishment rules will handle the request instead, which avoids unnecessary records and confusing production tasks.
Original PR description
Steps to reproduce: - unarchive the MTO route - Create a storable product "P1" with the MTO + Manufacture routes but set no Bill of Materials on it - Create a sales order with one unit of P1 and confirm it Problem: An empty draft MO is created even though no Bill of Materials exists. When no BoM is available, manufacturing orders should not be created, only replenishment rules are expected to handle this case. Fix: Added an early `continue` in `_run_manufacture` to skip MO creation when no BoM is found. opw-6174886 Forward-Port-Of: odoo/odoo#263108
This update resolves an issue where new modules could fail to install correctly when containing data for deleted records. The fix corrects a technical error within the `l10n_sa_edi` module, ensuring smoother and more reliable module installations. This prevents data loss and improves the overall stability of the system.
Original PR description
Installing a new module should be safe even when the module contains new data for records that have been deleted. It is not the responsibility of the localization to make sure of that. The fix in `l10n_sa_edi` had 2 issues: * calling `self.env.ref` instead of `self.ref` * Checking for the existence of records even in the case of installing the CoA for the first time on a company, which obviously doesn't contain anything. This results in always ignoring the data.
This update resolves an issue where the CoA reload process unintentionally modified existing financial reports. The CoA framework is now responsible for managing these records, ensuring data integrity and preventing unexpected changes. This change improves the stability and reliability of financial reporting within the system.
Original PR description
It is the burden of the CoA framework to check for that. See community commit for more information.
This update resolves a technical error preventing the Spanish E-Invoice module (`l10n_es_edi_verifactu`) from functioning correctly during upgrades. The fix ensures the necessary 'certificate' module is loaded first, preventing a system error that blocked the module's operation. This ensures a smoother upgrade process and reliable functionality for users.
Original PR description
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to…
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises: ``` TypeError: Model 'certificate.certificate' does not exist in registry. ``` ### Cause `models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`. ### Notes - Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op. - Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first. Forward-Port-Of: odoo/odoo#271827 Forward-Port-Of: odoo/odoo#271496
This update fixes an issue where quality alerts weren't being created when receiving emails without a company assigned. The fix ensures that a default company is now automatically applied, preventing errors and guaranteeing that all incoming emails are properly recorded within the quality alert system. This improves data accuracy and reporting.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#118516 Forward-Port-Of: odoo/enterprise#109947
5 changes
Resolved issues and error corrections
This update streamlines the calculation of French VAT within the Odoo system. By removing unnecessary dependencies on account move data, the system now computes VAT more efficiently, reducing potential delays and improving overall performance. This change addresses a previous build error and prevents unnecessary recalculations when partner information is updated.
Original PR description
- This removes dependency on account move fields to company : Build error 939448 - This removes dependency on account move fields to commercial_partner_id fields (avoid recompute all moves on partner info change) Forward-Port-Of: odoo/odoo#271822 Forward-Port-Of: odoo/odoo#269701
This update corrects a problem within the planning module's automated testing process. The fix ensures that test data is self-contained, preventing issues with undo operations affecting previously allocated hours. This improves the reliability of our planning test suite.
Original PR description
Fix by creating the planning role directly within the test, making it self-contained. runbot error-939985 Forward-Port-Of: odoo/enterprise#121111
This update fixes a display issue in Helpdesk where ticket state labels in list and form views didn't reflect the most recent changes made in the Kanban view. The fix removes outdated reference fields, ensuring all views show the correct, up-to-date state labels for improved consistency and accuracy.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707This update ensures that custom reports attached to invoices display their intended names in email attachments, rather than using a default CFDI-based filename. The change resolves an issue caused by how the system handles localization overrides, improving the clarity and accuracy of invoice attachments for users.
Original PR description
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard…
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard **Invoice PDF** report. * Open the duplicated report and make any modification to it. * Enable **Developer Mode**. * Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**. * Go to **Settings → Technical → Email → Templates** and create a new invoice email template. * Add the custom report to the template's **Dynamic Reports**. * Create and confirm an invoice for a **Mexican company**. * Click **Send** and select the newly created email template. Observed behavior: * The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment. Cause: * `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`. However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated. Fix: * Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain. * Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call. This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic. opw-6228268 Forward-Port-Of: odoo/odoo#271489
This update ensures that partner bank accounts are usable within all child companies, even if the partner is associated with a parent company. Previously, this functionality was limited, causing potential disruptions for users managing multiple company branches. This change improves efficiency and simplifies bank account management across the Odoo system.
Original PR description
Even when a partner has the 'company_id' filled with the parent company, his bank account should be usable in the child companies. This was done in odoo/odoo#262173 from 19.2 but we need to backport it in stable task-6309694 Forward-Port-Of: odoo/odoo#271470
34 changes
New functionality added to Odoo
This update adds a new command introduced in the recent o-spreadsheet update to the list of publicly available commands. This ensures users can easily access and utilize the latest functionality within the spreadsheet module. It's a straightforward addition to improve usability.
Original PR description
Last o-spreadsheet update added a new command, so we need to add it to the public command list.
Enhancements to existing features
The POS blackbox module was updated to follow a change in how POS sessions are identified. This ensures the module keeps working correctly when checking whether a session exists, which helps avoid issues with future orders.
Original PR description
This commit adapts the pos_blackbox_be module to the changes in the community PR. The change is that the has_active_session is now defining if a config has a session that is opened or in closing_control but to check if a session exists, we have to check current_session_id instead of has_active_session. task-id: 6034751 Community PR: https://github.com/odoo/odoo/pull/254408
This update allows users to easily duplicate existing website appointment menus, streamlining the process of creating similar appointment pages. Previously, this functionality required a manual step. This change improves efficiency and simplifies website management for the team.
Original PR description
The corresponding community PR makes it possible to duplicate multi-level template menus but The duplication function needs to be explicitly called. Task-6030210
Resolved issues and error corrections
This change removes an unintended extra padding in the bank reconciliation widget. It makes the layout look more consistent and improves the display of statement lines for users working in accounting.
Original PR description
Since this commit: https://github.com/odoo/odoo/commit/185b70434091d7c20b3993d59dad6490a8a77a6e it seems that kanban record have an extra padding to it. This pr will remove it in the bank rec widget at least. no task id
This change updates how automated tests clean up test components so they remove whole test apps only when appropriate. It prevents tests from accidentally tearing down shared pieces of the interface, which makes the test suite more stable and reduces flaky failures.
Original PR description
- Community: https://github.com/odoo/odoo/pull/271765 Before this commit, 'destroy' was used to destroy individual components in unit tests. The issue is that this helper is meant to destroy the entire app, which creates weird situations when several components are spawned under the same app in a same test. This commit ensures the 2 following scenarios: - the previous component is entirely replaced, and 'destroy' is used legitimately; - or multiple components have been aggregated under a common parent, and are then mounted/unmounted through reactivity.
This update streamlines the layout of quantity buttons within the Odoo inventory barcode interface. Previously, a confusing button arrangement and inconsistent delete functionality caused user friction. Now, the layout is more intuitive, and the delete button's behavior has been clarified to only remove lines from the view, improving the user experience.
Original PR description
This commit improves the layout of quantity buttons in barcode in both cases of physical inventory and transfers. ### Before this commit: 1- The fulfill button disappeared if `quantity done == demand…
This commit improves the layout of quantity buttons in barcode in both cases of physical inventory and transfers. ### Before this commit: 1- The fulfill button disappeared if `quantity done == demand - 1` which causes the increment and decrement buttons to shift their positions, that caused confusion to the user. 2- The delete button (red trash button) in case of physical inventory count was used to set the count of the product to 0 and remove the line from barcode view. 3- The "?" button (to mark the quantity as not set yet while inventory count) appeared whether the quantity on line was set to a number >= 0. 4- The button for registering components was among the lower buttons (increment, decrement, and fulfill). ### After this commit: 1- The fulfill button still disappears when `quantity done == demand - 1` but an empty spacer replaces it, which causes other buttons to hold positions. 2- The delete button now only appears when the user adds a product by themselves using the form or scanning the product (not while the product is in an inventory request). Also the functionality is of the button is now different, it just removes the line from the barcode view without affecting the inventory count at all. 3- The "?" button now only appears if the quantity = 0. 4- The button for registering components is no next to the edit button. Upgrade PR: https://github.com/odoo/upgrade/pull/10224 Task-6095725
This update resolves an issue where the website link wasn't correctly populated when creating a lead through the AI-powered CRM tool. The fix ensures that the visitor's website information is accurately captured, improving the lead generation process. This prevents missing website data from being associated with new leads.
Original PR description
see: https://github.com/odoo/odoo/pull/252766 ERROR: Subtest TestAiCrmLivechatTools.test_create_lead_tool_from_livechat (login='public_user') Traceback (most recent call last): File…
see: https://github.com/odoo/odoo/pull/252766
ERROR: Subtest TestAiCrmLivechatTools.test_create_lead_tool_from_livechat (login='public_user') Traceback (most recent call last):
File "/data/build/odoo/odoo/tools/safe_eval/evaluation.py", line 431, in safe_eval
return unsafe_eval(c, globals_dict, None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "ir.actions.server(272,)", line 1, in <module>
File "/data/build/odoo/odoo/tools/safe_eval/runtime.py", line 659, in safe_call
return callee(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/ai_crm/models/crm_lead.py", line 16, in _ai_create_lead
self.create(self._ai_prepare_lead_creation_values({
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/ai_crm_livechat/models/crm_lead.py", line 21, in _ai_prepare_lead_creation_values
if 'website' in self.env and (visitor := channel.livechat_visitor_id):
^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'discuss.channel' object has no attribute 'livechat_visitor_id'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/data/build/odoo/odoo/tests/common.py", line 2949, in with_users
func(self, *args, **kwargs)
File "/data/build/enterprise/ai_crm_livechat/tests/test_ai_crm_livechat_tools.py", line 17, in test_create_lead_tool_from_livechat
tool.with_context({'discuss_channel': livechat_channel})._ai_tool_run(None, {
File "/data/build/enterprise/ai/models/ir_actions_server.py", line 288, in _ai_tool_run
self._run_action_code_multi(eval_context=eval_context)
File "/data/build/odoo/odoo/addons/base/models/ir_actions.py", line 1012, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", filename=str(self))
File "/data/build/odoo/odoo/tools/safe_eval/evaluation.py", line 437, in safe_eval
raise ValueError('%r while evaluating\n%r' % (e, expr))
ValueError: AttributeError("'discuss.channel' object has no attribute 'livechat_visitor_id'") while evaluating "ai['result'] = record.sudo()._ai_create_lead(name, contact_name, description, email, phone, team_id, tag_ids, priority, country_id, state_id, city, zip_code, street, job_position)"This update resolves an issue where users assigned to sign requests ('Own Templates' group) were encountering an 'Access Error' when attempting to sign documents. The fix utilizes `sudo()` to correctly access document counts, ensuring these users have the necessary permissions to open and sign documents. This improves the user experience for sign requests created with the 'Own Templates' access right.
Original PR description
Steps to Reproduce: 1. create a new user (UserB) and grant the 'User: Own Templates' access right. 2. send a new Sign Request to UserB. 3. log in with the UserB account and try to sign the document. Issue: An 'Access Error' message is displayed instead of opening the document to sign. Cause: `go_to_document` and `go_to_signable_document` read `self.template_id.document_ids` to compute `document_count`, and the `sign.template` record rule for `group_sign_user` only grants access to the template owner. Users assigned to sign request created from that template do not have access to the template itself, so reading `document_ids` raises an `AccessError` before the document can be opened. Solution: Used `sudo()` in both methods to compute document_count.
This update resolves an issue preventing proper grouping in the resource search view based on job position. The fix ensures that users can now filter and group resources accurately, improving search efficiency. This enhancement streamlines resource management within the Enterprise module.
Original PR description
In a recent commit, we added the job position to the resource search view. However, the group by was not working because the field was not stored. This is now fixed in this commit. task-6329358
A previous bug caused an unwanted 'Uninstall modules' prompt to appear after saving settings, specifically when the Website Form module was installed. This fix ensures the module remains installed regardless of the Website Form setting, as it's now essential for displaying Field Service information in the portal. This prevents unnecessary user disruption.
Original PR description
Steps to reproduce: - 1. Install `website` and `planning_field_service` (so `website_planning_field_service` auto-installs). 2. Open Settings and click Save. Issue: - An "Uninstall modules" wizard…
Steps to reproduce: - 1. Install `website` and `planning_field_service` (so `website_planning_field_service` auto-installs). 2. Open Settings and click Save. Issue: - An "Uninstall modules" wizard pops up offering to remove `website_planning_field_service`. Cause: - Since the module is now `auto_install` with its `post_init_hook` removed, it is installed alongside `website` and `planning_field_service` while the setting remains disabled by default. On Save, `set_values` re-derives the `module_website_planning_field_service` field from a company `search_count`, setting it to False when no company has the feature enabled, even though the module is installed. Base `execute()` then sees `module_* = False` on an installed module and re-offers the uninstalls. Fix: - Make `set_values` install-only: enabling the setting still installs the module, but disabling it no longer attempts to uninstall it. The module is now also used to show or hide Field Service information in the portal, so it must remain installed even when the Website Form feature is disabled. task-6330718
This update fixes an issue where shift report PDFs displayed unnecessarily large pills for single-line shift names. The change ensures shift pill sizes are now correctly optimized for single-line names while still accommodating longer names that wrap to multiple lines. This improves the visual clarity and consistency of shift reports.
Original PR description
### Steps to reproduce: 1. Go to Planning. 2. Create a shift with a short name that easily fits on a single line. 3. Click Actions > Print to generate the PDF report. 4. Observe the printed shift pill. ### Issue: Single-line shift pills look unusually large because they take up unnecessary vertical space on the printed report. ### After: The pill now correctly shrinks to fit a single-line name natively, while still expanding downward if a longer name wraps to a second line. task-5062148
A recent update to Odoo's user interface broke the way certain fields, specifically the VAT field, are displayed. This fix corrects the broken XPath expressions, ensuring the VAT field is correctly rendered across multiple Odoo localization modules. This resolves a display issue impacting financial reporting.
Original PR description
The refactor of identifiers on both the partner and company views broke some xpaths. This commits aims at repairing those. See https://github.com/odoo/odoo/pull/262274 See https://github.com/odoo/enterprise/pull/115838 task-none
This update resolves an issue where sign templates with auto-filled fields would incorrectly display placeholders instead of the actual values, or fail to generate documents. The fix ensures falsy auto-filled values are properly preserved, preventing errors and guaranteeing accurate sign document generation.
Original PR description
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the…
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the document for signing. - Complete the signing flow. Issue: - Readonly sign items linked to auto-filled values could not properly handle falsy values. Empty values could trigger the error "Some required items are not filled" and completed sign requests displayed the sign item placeholder instead of the actual auto-filled value. - completed document generation could fail when rendering falsy values for textarea sign items. Cause: - Falsy auto-filled values were ignored during constant item population and replaced by the sign item placeholder. Additionally, readonly constant items were included in required field validation and completed sign requests continued to display placeholders when the stored value was empty. - document rendering assumed sign item values were always strings for textarea sign items but when auto field is empty it value can be False. Fix: - Preserve falsy values when populating readonly constant items, exclude constant items from signer validation, and hide placeholders for empty auto-filled constant items when displaying completed sign requests. - Normalize falsy values to prevent crashes and allow completed documents to be generated correctly. Forward-Port-Of: odoo/enterprise#121299 Forward-Port-Of: odoo/enterprise#121009
This update fixes a scheduling issue with semi-monthly payrolls. Previously, payslips were incorrectly aligned with the month's halves, resulting in overlapping periods. The change now ensures payslips start on the 16th of the month, accurately reflecting the payroll schedule.
Original PR description
Issue: ---------------------------------------- The start date of semi-monthly payslips on second half of the month is the 15 which is also the end date of the first half of the month. Steps to reproduce: ---------------------------------------- - Have an employee with a semi-monthly payroll - When in the first half of the month, create a payslip for this employee - The payslip is from 1st to 15th - Do the same when in the second half of the month - The payslip is from 15th to end of the month Cause: ---------------------------------------- In `_schedule_period_start()` we set the start date to th 15th for semi-monthly payslips. Solution: ---------------------------------------- Set it to the 16th. opw-6281556 Forward-Port-Of: odoo/enterprise#120887 Forward-Port-Of: odoo/enterprise#120172
This update fixes an issue where the system incorrectly rejected zero measurements from caliper devices in IoT data. This ensures accurate reporting of measurements, particularly when a device isn't detecting anything. The update also includes a minor typo correction.
Original PR description
Fix a check on the IoT response that incorrectly rejected valid measurements of 0 from caliper devices Also fix a typo opw-6184669 Forward-Port-Of: odoo/enterprise#121226 Forward-Port-Of: odoo/enterprise#121116
This update resolves an issue where users were encountering access errors when using the timesheet suggestion dropdown. The fix prevents the timer from suggesting tasks the user no longer has permission to view, ensuring a smoother timesheet experience. This improves usability and prevents potential disruptions for users.
Original PR description
Steps to reproduce: - 1. Log in as a user who can see their own timesheets and has already logged time on tasks that are now in projects they can no longer read (e.g. Marc Demo in the demo data). 2. Open the Timesheets timer in the systray and check in. 3. Click the task field to open the suggestions dropdown. Issue: - An access error is raised when the task dropdown is opened. Cause: - The timer's `project.task` `name_search` override suggests recently used tasks via `account.analytic.line.sudo()._get_recently_used_records()`. The sudo surfaces task ids the user can no longer read. `name_search` returns them, raising the access error. Fix: - Filter the aggregation result so only tasks the user can read are returned. task-6319815 Forward-Port-Of: odoo/enterprise#121345
A minor typo in the payroll warning system was causing incorrect alerts. This update corrects the typo, ensuring that payroll warnings are accurately identified and displayed to users. This resolves a potential disruption to payroll reporting.
Original PR description
The DMFA submission payroll warning was incorrectly matched by _get_payroll_translation because of a small typo task-6326554
This update resolves an issue where PrintRec components could receive incorrect data values. Previously, these components weren't properly validated, which could lead to unexpected behavior. This fix ensures data integrity for PrintRec components, particularly when used in production environments.
Original PR description
This commit fixes the props validation of PrintRec* components since they can receive `false` on some property. Before the components were not validated because they were mounted with a production mode app.
This update resolves a technical issue impacting work order duration calculations. A recent code change shifted a related function, but a critical component – accounting for travel time – was missed. This fix, triggered by a runbot error, ensures accurate work order duration reporting.
Original PR description
get_duration was moved from mrp_workorder to mrp in odoo/odoo#267113 and odoo/enterprise#118753 However, _intervals_duration missed the trip This solves runbot error 940411
This update resolves a technical issue impacting the performance of the Gantt chart within the Enterprise module. Specifically, a variable name was corrected to enhance the functionality and stability of the underlying planning service. This change ensures smoother chart operation for users.
Original PR description
task-6200248
This update resolves a stability issue in the point-of-sale tour. Previously, the tour could fail due to asynchronous order processing, leading to duplicate requests. By adding a delay to ensure requests are fully completed, this fix prevents race conditions and improves the reliability of the tour.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#121237 Forward-Port-Of: odoo/enterprise#110909
A recent update to the Odoo Enterprise system (version 19.2 and later) caused a test for the 'hr_holidays_gantt' module to fail. This was due to an issue with a payroll-related field in the test's configuration. This fix ensures the test runs successfully, maintaining the functionality of the holiday Gantt chart.
Original PR description
__ ## Error description When the test runs with only the module `hr_holidays_gantt` installed, it fails. ## Origin of the issue There's a payroll related field in the `read_specification` variable. ### Note The error is only triggered since 19.2. __ original commit: https://github.com/odoo/odoo/pull/256636 Forward-Port-Of: odoo/enterprise#121119
Features or functions removed from Odoo
This update removes redundant app creation within Odoo, streamlining the system and reducing potential errors. By eliminating unnecessary app instances, we minimize the risk of configuration issues and simplify debugging, ultimately improving stability.
Original PR description
See commit messages for detail - https://github.com/odoo/odoo/pull/267998
Code cleanup and technical improvements
This change updates the VoIP softphone interface to use the newer input binding approach required by the latest framework version. It helps keep the calling experience compatible and maintainable as the platform evolves, without changing the user-facing behavior.
Original PR description
As part of the migration from `owl 2` to `owl 3`, this commit replaces uses of `t-custom-model` with `t-model` or `t-model.proxy`.
The return check screen was updated to use the newer embedded action structure introduced elsewhere in the product. This keeps the interface working consistently after the internal refactor, with no expected change to business behavior.
Original PR description
Following the refactoring of embedded actions, this commit adapts the AccountReturnCheckControlPanel to utilize the new logic. Changes: - Created a new `AccountReturnCheckEmbeddedActions` component that extends `EmbeddedActionsPanel`. - Moved the `isEmbeddedActionVisible` method to AccountReturnCheckEmbeddedActions. - Moved the XML replacement for the embedded actions dropdown to the new component's template. - Registered the new embedded actions panel within the control panel components. Task~4277541 Related: odoo/odoo#269040
Replaced \`useLayoutEffect\` with \`onMounted\` because \`useLayoutEffect\` is deprecated in OWL3. The effect used an empty dependency array (\`() => []\`), meaning it ran exactly once after the first render — which maps directly to \`onMounted\`. No reactive tracking or DOM measurement was needed, so \`onMounted\` is the correct and minimal replacement. The \`useLayoutEffect\` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out: - @docu
Original PR description
Replaced \`useLayoutEffect\` with \`onMounted\` because \`useLayoutEffect\` is deprecated in OWL3. The effect used an empty dependency array (\`() => []\`), meaning it ran exactly once after the first render — which maps directly to \`onMounted\`. No reactive tracking or DOM measurement was needed, so \`onMounted\` is the correct and minimal replacement. The \`useLayoutEffect\` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out: - @documents/kanban_view/Check actions with preview - @documents/kanban_view/Download button availability - @documents/kanban_view/Ensure previewer shows correct name after renaming a document see runbot build: https://runbot.odoo.com/runbot/batch/2593689/build/114684050
This update removes an outdated code element (`useLayoutEffect`) that was causing instability in the Knowledge module. Replacing it with `onMounted` ensures the module functions reliably and aligns with current Odoo standards. Successful automated tests confirm the change.
Original PR description
Replaced `useLayoutEffect` with `onMounted` because `useLayoutEffect` is deprecated in OWL3. The effect called `toggler.click()` once when the toggler element became available on mount. `onMounted` is the correct replacement: the toggler ref's el is present at mount time, so a single `onMounted(() => this.toggler.el?.click())` fires synchronously at the same lifecycle point, matching the original timing without the deprecated hook. The useLayoutEffect refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing: - @knowledge/options_dropdown/Move Article - FAIL: WebSuite.test_unit_desktop (in html_editor,knowledge suite) - FAIL: MobileWebSuite.test_unit_mobile (in html_editor,knowledge suite) see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596678/build/114854269
This update replaces an outdated code component with a modern version compatible with Odoo's latest framework (OWL3). This ensures the appointment screen functions correctly and avoids potential issues with deprecated code. The change was verified through automated testing, confirming the functionality remains intact.
Original PR description
Replaced `useLayoutEffect` with `useEffect` (OWL3) because `useLayoutEffect` is deprecated in OWL3. The single `useLayoutEffect` was reacting to `this.props.actionName`: when `actionName ===…
Replaced `useLayoutEffect` with `useEffect` (OWL3) because `useLayoutEffect` is deprecated in OWL3. The single `useLayoutEffect` was reacting to `this.props.actionName`: when `actionName === 'manage-booking'` it makes an async `data.call` to open the booking gantt view, then dispatches `doAction` / `switchView`. This is not derived state and does not load data into component state — it dispatches an action, making OWL3 `useEffect` the correct replacement. OWL3 `useEffect` auto-tracks reactive values read in its body, so `this.props.actionName` is tracked automatically without an explicit dep array. The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing: - `@pos_appointment/unit/screens/action_screen/ActionScreen => useEffect`: Expected gantt view action, received null - `FAIL: TestFrontend.test_appointment_kanban_view_date_filter`: Tour failed at 'Go to kanban view' step - `FAIL: TestUi.test_pos_restaurant_appointment_tour_basic`: Tour failed at 'Check that the booking gantt view is shown' see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596700/build/114854622
This update improves the way mock server data is structured and serialized, aligning it with recent changes in the Odoo Enterprise platform. Specifically, the mock models used in various modules (ai, approvals, voip, whatsapp, etc.) have been updated to use a new field list DSL and `as_dict()` serialization, ensuring better compatibility and data consistency. This change enhances the reliability of the mock server environment for testing and development.
Original PR description
Enterprise companion of the community commit "[REF] mail, *: match mock server Store to python implementation". Migrate the mock server mock models to the new `_store_<name>_fields` field list DSL and `as_dict()` serialization. https://github.com/odoo/odoo/pull/271117
This update simplifies the underlying model structure within Odoo's Web Studio. As part of a larger migration to a newer version (Owl 3), the team has replaced older model definitions with more modern `t-model` and `t-model.proxy` structures. This change improves the long-term maintainability and stability of Web Studio applications.
Original PR description
As part of the migration from `owl 2` to `owl 3`, this commit replaces uses of `t-custom-model` with `t-model` or `t-model.proxy`.
This update centralizes the configuration for printing IoT reports using a standardized registry. This change enhances flexibility and maintainability by allowing for easier updates and modifications to report printing methods for IoT printers, without requiring direct code changes.
Original PR description
we now use the registry to define the method to print reports using IoT printers. see odoo/odoo#271560
This update simplifies the codebase by replacing older model structures (`t-custom-model`) with newer, more efficient ones (`t-model` and `t-model.proxy`) as part of the ongoing migration to Owl 3. This change improves the underlying system's performance and maintainability.
Original PR description
* = [ai_website] As part of the migration from `owl 2` to `owl 3`, this commit replaces uses of `t-custom-model` with `t-model` or `t-model.proxy`.
This update simplifies the underlying data structure within the Enterprise module by replacing older model types with newer, more efficient `t-model` and `t-model.proxy` structures. This change is part of a larger migration from `owl 2` to `owl 3`, ensuring the system remains current and optimized for future development.
Original PR description
As part of the migration from `owl 2` to `owl 3`, this commit replaces uses of `t-custom-model` with `t-model` or `t-model.proxy`.
This update changes how processors within Odoo handle data transformation. Previously, processors were limited in returning falsy values, now they can explicitly return null or undefined to signal no processing or a deliberate choice. This allows for more flexible and controlled data flow within Odoo's modules.
Original PR description
*: knowledge, web_studio Previously, `processThrough` used `|| item` to fall back to original value if a processor returned a falsy value. This prevented processors from intentionally returning falsy values (e.g. null, undefined). Now each processor is responsible for returning a value explicitly: - Return the transformed value if processing occurred. - Return the original item if no processing is needed or processing is in place. - Return null/undefined to intentionally pass a falsy value. Community PR: https://github.com/odoo/odoo/pull/255801 task-6030633
2 changes
Resolved issues and error corrections
This update resolves an error that occurred when the 'Company Car (To order)' option was enabled in the salary configurator, specifically when the module wasn't set up with demo data. The fix ensures the system checks for both the option being enabled and a car model selected before attempting to process the data, preventing a critical error.
Original PR description
## Steps to Reproduce: 1. Install `l10n_be_hr_contract_salary` without demo data. 2. Create a Belgian company and switch to it. 3. Create an employee. 4. Create a contract for the employee. 5. Click Generate Offer and open the Salary Configurator. 6. Enable the 'Company Car (To order)' option. ## Error: `AttributeError: 'NoneType' object has no attribute 'split'` ## Cause: When the salary configurator is used without demo data, no car model is selected. The method assumes that select_wishlist_car_total_depreciated_cost always contains a value and directly calls split() on it, resulting in an error, when the field is None. ## Fix: This commit checks that both the company car option is enabled and a car model has been selected before trying to extract the model ID. sentry-7554712017 Forward-Port-Of: odoo/enterprise#121527 Forward-Port-Of: odoo/enterprise#121138
This update resolves an issue where the website generator tool in version 19.0 was limited to importing only 100 pages. This change ensures the tool accurately imports the correct number of pages, improving website creation functionality. This fix addresses a limitation impacting website design and content management.
Original PR description
The tool for 19.0 could only import up to 100 pages so matching it with the comment.
9 changes
Enhancements to existing features
The option to send a PDP response is no longer shown as a large button on the invoice/bill screen. It is now available in the settings menu, since canceling and reposting a document already triggers the same result and the interface is less cluttered.
Original PR description
No real need to show a big button for sending a response in PDP as cancelling and posting an invoice/bill would do the same, so we move it to the cog wheel menu task-6274220
Resolved issues and error corrections
This update corrects a test case that used an invalid Belgian VAT number, which started failing after a stricter validation update in a supporting library. The test still checks for a VAT mismatch, but now uses a valid VAT number so it remains reliable across environments.
Original PR description
This commit fixes a Belgian VAT validation check in `test_import_partner_retrieval_bank_account_number` as the provided vat number isn't a valid one. It keeps the spirit of the test by still having vat number mismatch, but with a valid value. The python-stdnum library used for this validation added a stricter check since version 2.2, which is used in Ubuntu Resolute 26.04. References: - https://github.com/arthurdejong/python-stdnum/commit/7ca9b6ce7b1f2b4d1bf164c2af83a8a77bc919d2 runbot-939796
This update resolves an issue where importing UBL files containing invoice lines with zero quantity and amount would cause a division-by-zero error, leading to import failures. The fix ensures the system handles these zero-value lines correctly, improving the reliability of UBL import processes.
Original PR description
**PROBLEM** When importing a ubl with a line with an invoiced qty of 0 and an amount of 0, there is division by zero. **STEP TO REPRODUCE** 1. upload a ubl file with an empty line as a vendor bill (there is one in the bugfix ticket). 2. notice the import fails because of a division by zero. The division by zero was introduced by https://github.com/odoo/odoo/pull/265261 opw-6260558
This update corrects a test failure within the French invoicing module (l10n_fr_pdp) that occurred when only the basic Invoicing module was installed. The fix adds the necessary 'in_payment' state, which was present in the full 'enterprise' version of the Accounting module. This ensures the test suite runs correctly and avoids potential disruptions.
Original PR description
The `in_payment` state does not exist in community with only the Invoicing module installed. It is added in `enterprise` in the Accounting module. runbot.build.error-939451
This update corrects a previous issue where the GT Document Type field was incorrectly required when creating vendor bills for vendors outside of Guatemala. The change ensures the field is only mandatory for Guatemalan vendors, streamlining the billing process and improving usability for international transactions. This resolves a user experience problem.
Original PR description
Currently, the GT Document Type field is required when creating vendor bills for non-Guatemalan vendors. **Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a GT Company. -…
Currently, the GT Document Type field is required when creating vendor bills for non-Guatemalan vendors. **Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a GT Company. - Create a new vendor bill for a vendor whose country is not Guatemala. **Observation:** The `GT Document Type` field is required even though the selected vendor is not based in Guatemala. **Root Cause:** At [1], `_compute_l10n_gt_edi_available_doc_types` only checks the company country and ignores the vendor's country, causing GT available document types to be computed for foreign vendors as well. As a result, `l10n_gt_edi_available_doc_types` is populated and the view at [2] incorrectly makes `l10n_gt_edi_doc_type` required. **Fix:** This commit ensures the GT Document Type field is only required for Guatemalan vendors. [1]: https://github.com/odoo/enterprise/blob/7a80db5b5550bf75e4ce5337e869c42386c8a71c/l10n_gt_edi/models/account_move.py#L144-L171 [2]: https://github.com/odoo/enterprise/blob/7a80db5b5550bf75e4ce5337e869c42386c8a71c/l10n_gt_edi/views/account_move_views.xml#L27 opw-6315872
This update resolves an issue where the system incorrectly imported invoice quantities from UBL files. Specifically, it ensures that the 'invoiced_quantity' and 'base_quantity' values in imported invoices accurately reflect the quantities specified in the original UBL document. This prevents discrepancies in order data.
Original PR description
…ase_quantity equal to zero **STEP TO REPRODUCE** 1. Import the 2fact ubl from the bugfix ticket. 2. Notice some line are imported with quantity = 1, but the quantity invoiced in the ubl is 0. opw-6260558
This update fixes a crash that occurred when Odoo's subscription module was run outside of its normal web environment (like in tests or cron jobs). The fix ensures the system correctly handles situations where an active HTTP request isn't present, preventing a runtime error.
Original PR description
When executing code outside of a web thread (such as in unit tests, cron jobs, or CLI commands), an actual HTTP request does not exist, leaving the global `request` proxy unbound. In these scenarios, the unbound proxy evaluates to False. Because of Python's `and` evaluation, the expression `request and request.params...` returned the unbound proxy itself instead of None. This caused a RuntimeError later when the proxy was compared to other values. We now explicitly check `request.env` to verify an active request exists, properly falling back to None when there is no HTTP context. runbot-938513
This update ensures that custom reports attached to invoices display their intended names in email attachments, rather than a default CFDI-based filename. The fix addresses an issue where localization overrides were preventing the correct report name from being used, leading to duplicate attachments. This improves the clarity and usability of invoice attachments.
Original PR description
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard…
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard **Invoice PDF** report. * Open the duplicated report and make any modification to it. * Enable **Developer Mode**. * Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**. * Go to **Settings → Technical → Email → Templates** and create a new invoice email template. * Add the custom report to the template's **Dynamic Reports**. * Create and confirm an invoice for a **Mexican company**. * Click **Send** and select the newly created email template. Observed behavior: * The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment. Cause: * `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`. However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated. Fix: * Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain. * Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call. This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic. opw-6228268
This update ensures that partner bank accounts are usable within all child companies, even if the partner is associated with a parent company. Previously, this restriction limited functionality. This change improves efficiency and simplifies processes for users managing multiple company branches.
Original PR description
Even when a partner has the 'company_id' filled with the parent company, his bank account should be usable in the child companies. This was done in odoo/odoo#262173 from 19.2 but we need to backport it in stable task-6309694 Forward-Port-Of: odoo/odoo#271470
3 changes
Resolved issues and error corrections
This update resolves a technical issue where the Intrastat report generation would fail when a company record lacked a country ID. The fix ensures a safer fallback mechanism in the SQL query, preventing errors and improving report reliability. This ensures accurate reporting for all companies.
Original PR description
When there is no `country_id` on the company we get `False`. The generated query then fail at: ``` ... CASE WHEN (code.country_id IS NULL OR code.country_id = false) THEN code.code ELSE NULL END AS commodity_code, ... ``` with: ``` ERROR: operator does not exist: integer = boolean LINE 12: ... WHEN (code.country_id IS NULL OR code.country_id = false) T... ```
This update fixes an issue where recurring subscription revenue was incorrectly displayed as 'To Invoice' even after invoices were fully processed. The change ensures that invoiced amounts are accurately deducted from revenue calculations, providing a more precise view of subscription income. This improves financial reporting accuracy.
Original PR description
**Steps to reproduce:** - Create a Sale Order for a service product with a recurring plan - Confirm it - Go to the Project Dashboard and observe MRR shown under "To Invoice" - Create an invoice for the subscription and post it - Go back to the dashboard **Issue:** Even after fully invoicing a subscription, its value is still shown under `to_invoice` in the revenues section. **Fix:** The profitability computation was not deducting the already invoiced amount from the total expected revenue. We now subtract the `amount_invoiced` from `amount_to_invoice`, ensuring that fully invoiced subscriptions no longer appear under `to_invoice`. task- 4797525
This update resolves an issue where creating and modifying contact records with blog posts would sometimes cause an error. The fix ensures that website URL calculations are skipped for temporary blog posts, preventing the system from attempting to generate URLs for records that don't yet have a permanent ID. This improves the stability and reliability of the contact form.
Original PR description
Steps to reproduce: 1. Install Blog, Contacts, and Studio 2. Open Contact form page and a new page with many2many field "Blog Post" 3. Save and create a contact record with email and a blog post. 4. Save and try to modify the email. Issue: `ValueError: Cannot slug non-existent record` Cause: - Since[1] Invisible fields also trigger `onchange` and compute methods during view processing. In this flow, `blog.post` records can be handled as transient `NewId` records. `_compute_website_url` was calling `slug(blog_post)` unconditionally, but `slug()` only accepts persisted records with a real id. Thus ValueError Solution: - Skip the website URL computation for non-persisted blog posts. - backport of https://github.com/odoo/odoo/commit/62ced8ac646fc781da24346f12c5dc9b9a0c592d [1] - https://github.com/odoo/odoo/commit/db63cb770365be1f81ba051fe6ca5a246dbc9036 opw-6175092