Friday, February 27, 2026
45 changes · saas-18.3
Resolved issues and error corrections
This update addresses minor technical issues within the Odoo web framework (Hoot) to improve stability and reliability. Specifically, it corrects a problem with how data is transmitted, fixes a reporting issue with test results, and restricts a potentially problematic feature. These changes ensure smoother operation and prevent unexpected errors.
Original PR description
### [FIX] web: Hoot - backport fixes This commit backports the following fixes that have been applied in further versions: - add correct mime type to XHR blob responses [1]; - fix missing diff from failed test results [2]; - wrap 'raw' value option in a dictionnary to limit unintended use, use 'raw' as a default for text-based matchers [3]. [1] 9156bf1 [2] 2216a0b [3] 3080362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the XML templates used for Dutch SBR and ICP tax reports to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local regulations and improving the reliability of financial data.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update fixes an issue where a POS order could incorrectly apply a pricelist even if it wasn't the customer's standard pricelist. This occurred when the order was linked to a previously paid order. The change ensures that only valid, available pricelists are applied to POS orders, improving order accuracy and preventing potential pricing errors.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248365 Forward-Port-Of: odoo/odoo#247029
This update fixes an issue with invoices generated for SII (Chile's tax authority) by ensuring the correct XML tags are used for withholding information. The change updates specific template elements to align with SII's invoice format requirements, preventing potential errors during invoice confirmation. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update fixes an issue where Odoo incorrectly displayed records after a user switched companies. Previously, the system didn't immediately update the URL needed for the correct record view, leading to incorrect displays. Now, the system reliably directs users to the correct record after a company change, ensuring a smoother user experience.
Original PR description
Have a flow where an action act_window is executed and wants to open a record in the form view, but that record is not in one of the companies that the current user is logged in. The ORM will crash with an access denied, that the JS catches cleverly (see odoo/odoo@6213c40932236101b529b82f0ea9fce1829c8c24) and tries to reload on that failed action after altering the allowed companies. Before this commit, this flow was imperfect because the url (that allows to reload at the right place) was not written immediately. So, more often than not, we ended up on the wrong view after reload. After this commit, we end up in the right action after reload. 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#250401
This update corrects a bug that caused time off reports to incorrectly open as allocation records. The issue stemmed from a misalignment in the database query used to generate the reports, leading to incorrect record identification. This fix ensures that time off requests are now correctly displayed and opened within the intended time off reporting interface.
Original PR description
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#249015
This update fixes a confusing error message users received when attempting to generate leads without sufficient credits. The system now correctly handles the scenario where credits are unavailable, providing a clearer message and preventing users from needing to manually adjust filters. This improves the user experience and ensures smooth lead generation.
Original PR description
Before this commit, when the user uses CRM to generate new leads and does not have credits, the error message they would get is "Your request did not return any result (no credits were used). Try removing some filters." This commit fixes this in _perform_request by instead of expecting InsufficientCreditError raised it now expects the credit_error flag to be set. task-5925047 Forward-Port-Of: odoo/odoo#250433
This update corrects a technical issue preventing invoices sent via Peppol from passing validation. The system was incorrectly using 'UNSPSC' instead of the required 'TST' code for commodity classifications. This change ensures compliance with Peppol standards and allows invoices to be successfully transmitted.
Original PR description
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**.…
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**. **Observed behavior:** * Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”* * The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`. **Cause:** * The `listID` attribute was set to the literal string **'UNSPSC'**. * According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'. **Fix:** * Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node. * Update and extend tests to validate the correct scheme identifier. * Same for CPV code from the documentation i's code is also changed to 'STI'. ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ opw-5948723 Forward-Port-Of: odoo/odoo#249788
This update fixes an issue where the VAT Book download was only generating for the primary company, even when related branches (with the same CUIT) were selected. Now, when multiple companies with the same CUIT are chosen, the VAT Book download will include data for all of them, ensuring accurate reporting for businesses with multiple branches.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#101898This update fixes an issue where table menu buttons were not visible or positioned correctly within the HTML editor. The change ensures the table menu functions as expected, providing a better user experience for creating and editing tables. It addresses a technical configuration problem within the HTML editor's internal workings.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. ENT PR: https://github.com/odoo/enterprise/pull/108874 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/odoo#250645
This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines a key configuration within Studio's editor, ensuring proper functionality and addressing a previous bug related to missing overlay definitions. This enhances the user experience within the Studio report editor.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. - Also Before `localOverlayContainers` was not defined in studio, so power buttons did not appear in studio reports. Now that `localOverlayContainers` is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250889 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Forward-Port-Of: odoo/enterprise#108724
This update resolves a technical issue where certain attributes weren't being properly set on model classes, leading to slower tests and occasional failures. Fixing this improves the stability and reliability of our test suite, ensuring smoother development and deployment of new features. This primarily impacts the chart_template area.
Original PR description
Followup / fixup to #249005, as these can / do cause trouble due to overlogging (mostly the chart_template one). Forward-Port-Of: odoo/odoo#250575
This update prevents archived subtasks from being duplicated when a parent task is copied. Previously, duplicated tasks incorrectly included inactive subtasks, leading to unnecessary clutter. This change ensures a cleaner and more efficient task management experience.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#250738 Forward-Port-Of: odoo/odoo#248167
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend. The issue stemmed from a misinterpretation of data keys, leading to incorrect gift card counts. This ensures all gift cards are properly recorded, improving order accuracy and preventing revenue loss.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320 Forward-Port-Of: odoo/odoo#249951 Forward-Port-Of: odoo/odoo#249066
This update resolves a display issue in the Email Marketing app where test emails were incorrectly showing as 'removed' in Chatter. The fix ensures that test messages are automatically removed when sent, preventing this misleading display and maintaining a clean Chatter view. This improves the user experience when testing email campaigns.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Click on the test button to send a test mail to any mail - Go to the first contact…
**Steps to reproduce:**
- Go to Email Marketing app
- Create a mailing campaign
- Set its recipients to Contact
- Click on the test button to send a test mail to any mail
- Go to the first contact record
- Chatter will show `This message has been removed` message
**Issue:**
Previously, message created for testing were ignored by the Chatter as they were empty. As we now keep empty messages visible but with removed content display, they shows up on related records.
```py
record = self.env[mailing.mailing_model_real].search([], limit=1)
```
**Fix:**
Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to `False` to trigger the `unlink` logic.
```py
def unlink(self):
# cascade-delete the parent message for all mails that are not created for a notification
mail_msg_cascade_ids = [mail.mail_message_id.id for mail in self if not mail.is_notification]
res = super(MailMail, self).unlink()
if mail_msg_cascade_ids:
self.env['mail.message'].browse(mail_msg_cascade_ids).unlink()
return res
```
related: https://github.com/odoo/odoo/commit/21f92550f83cbd38df2c223c65c61bd16dc8e2b0
opw-5502787
Forward-Port-Of: odoo/odoo#247805This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to 'unsure data,' which is now simply removed. This ensures seamless processing of incoming payments and prevents disruptions to key business operations.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
A recent issue caused live chat sessions to crash when multiple sessions were started quickly. This fix eliminates a dependency on outdated data, ensuring stable session creation. The update improves the reliability of our live chat functionality.
Original PR description
Since [1], a crash could occur when starting several live chat sessions quickly. Before this PR, the `thread` getter depended on `savedState`. In [1], `thread` became a field on the live chat service. There can be a slight delay where thread has been cleared, but saved state still exists. The `_createThread` method shouldn't rely on `savedState` to determine if there is a thread. [1]: https://github.com/odoo/odoo/pull/173197 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#250626
This update corrects a technical issue in the Spanish reporting module (l10n_es_reports) where an unnecessary date scope was added. This change ensures reports are generated accurately and efficiently, resolving a potential data processing problem. The fix was implemented as a straightforward correction.
Original PR description
In the Forward Port of this PR: https://github.com/odoo/enterprise/pull/108575 A date_scope was wrongly added opw-5363664 Forward-Port-Of: odoo/enterprise#108886
This update fixes a minor issue in the employee departure wizard by switching to a more reliable archiving method. Previously, toggling active status caused problems; now, archiving ensures employees are properly removed from the system, aligning with best practices and related enterprise updates. This improves data accuracy and stability.
Original PR description
When archiving an employee from the departure wizard, use the action_archive method instead of toggle_active. Related to odoo/enterprise#100437 task: 5354002 Forward-Port-Of: odoo/odoo#250632 Forward-Port-Of: odoo/odoo#247224
This update corrects a bug that prevented users with RTL languages (like Arabic) from dragging and dropping snippets into the web editor. The fix adjusts the code to correctly identify drop zones based on the RTL language setting, ensuring functionality for all users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#247759
This update fixes an issue where newly hired employees were incorrectly inheriting their private email address as their work email. The fix clears the employee's work_email field during the contract signing process, ensuring it reflects the correct work email provided by the applicant. This prevents data inconsistencies and improves data accuracy.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
This update resolves an issue where kiosk users couldn't add products with descriptions and no attributes to their order. The fix ensures these products are correctly recognized as valid and allows users to add them to the cart, improving the kiosk ordering experience. This prevents a frustrating user experience and ensures all products can be ordered.
Original PR description
Steps to reproduce: ------------------------------- - Install pos_self_order - Open kiosk - Select product that has description and no attributes. - Attempt to add it to the cart. Issue: ----------------------- - Add to Cart button remains disabled despite product being available. Cause: ------------------------- - The system incorrectly treated the product as having incomplete selection. Fix: --------------------- - Ensure such products are treated as valid and can be added to the cart. Task-4868023
This update fixes an issue where QR code payment links on invoices were incorrectly showing the full outstanding amount, particularly for installment-based invoices. By using the default values for the payment link wizard, the links now accurately reflect the next payable installment, ensuring accurate payments.
Original PR description
The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount. Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again. By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment. task-5401335
This update corrects a problem with how VAT tax schemes are calculated for Romanian customers. Previously, an empty company registry caused errors. The fix re-introduces specific logic for Romanian CIUSRO invoices to ensure accurate VAT calculations, addressing a critical issue for Romanian businesses using Odoo.
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250110
This pull request corrects a minor typographical error within the Odoo sale module's configuration settings. This ensures consistent and accurate display of sale options for users, improving the overall user experience. The fix addresses a small, non-functional issue that could have caused confusion.
Original PR description
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#249973
This update fixes a bug where employees with scheduled future attendances couldn't check out. The fix ensures that only past attendance records are considered when determining the employee's checkout status, preventing errors and restoring normal kiosk functionality. This resolves a critical issue impacting employee workflow.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867 Forward-Port-Of: odoo/odoo#248875
This update fixes a potential issue with after departure payments to work. Now, if a previous payslip isn't linked, a clear error message is displayed to the user instead of a technical error. This ensures accurate payment processing and avoids confusion.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107386
This update clarifies the event booking process for existing partners. When booking, the system now suggests both 'Sign In' and 'Create an Account' options, ensuring partners have clear guidance regardless of their portal access. This improves the user experience and streamlines the registration process.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This update fixes an issue where the number of available time off allocations wasn't accurately reflecting allocations started in the previous year. The fix ensures that all valid allocations, regardless of their start date, are correctly counted on the time off type page, improving reporting accuracy. This resolves a discrepancy between the smart button and the allocation details.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#250378 Forward-Port-Of: odoo/odoo#248482
This update fixes an issue where Point of Sale session messages were consistently displayed in English, regardless of the user's selected language. The fix ensures that all cash-related messages within POS sessions are now translated accurately based on the user's language preference, improving the user experience for international customers.
Original PR description
**Problem:** When opening or closing a POS session, chatter messages display untranslated English text regardless of the user's language setting. **Steps to reproduce:** 1. Set user language to any non-English language (e.g., Spanish) 2. Open a POS session and register cash in/out operations 3. Close the session 4. Check the chatter messages - labels appear in English **Current behavior:** Messages display in English: "Opening cash difference", "Opening cash expected", "Opening cash counted", "Closing difference", etc. **Expected behavior:** Messages should be translated according to the user's language setting. **Cause of the issue:** The hardcoded strings were not wrapped in the translation function `_()`, preventing them from being translated. **Fix:** Wrap the concatenated strings with `_()` to enable proper translation of all cash details messages. opw-5185310 Forward-Port-Of: odoo/odoo#244501
This update fixes a limitation in the eCommerce search bar's placeholder text, preventing it from being translated. The change replaces a technical method with a standard translation-friendly format, ensuring all placeholder text can now be localized. This improves the user experience for international customers.
Original PR description
The placeholder of the search bar for attributes in eCommerce was not translatable, because it was using a Python expression to set its value. This commit replaces the Python expression with a t-attf-placeholder, which allows the placeholder to be translated. opw-5978276
This update fixes a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file, resolving compatibility issues with the PyPDF library. This ensures consistent and reliable test results.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update ensures taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, now it defaults to using standard product tax rules. This ensures accurate tax reporting for all UrbanPiper transactions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#108405 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix ensures that multiple 'Back' clicks don't trigger redundant saving operations, preventing incorrect quantity calculations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#108881 Forward-Port-Of: odoo/enterprise#103130
This update fixes an issue where creating multiple email templates using favorites could lead to errors due to excessive HTML nesting. The fix prevents unnecessary wrapper application when using favorites, ensuring smoother template creation and preventing potential crashes. This improves the stability of our email marketing functionality.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a new mailing - Click on empty mail body and add only a Heading block - Set a subject, save it and click `Add to Templates` (favorites) - Create another mailing which use the first one as its template - Repeat the operation multiple times - Error will be raised at some point due to the depth of the template html **Issue:** Unnecessarily nested `div` are created when using favorites to create new `mailing.mailing` records, if those favorites are themselves based on other favorites etc., it later can lead to a recursion error when rendering the template. **Fix:** Check if the template comes from the favorites to avoid reapplying the wrappers on it. This seems to be solved in 19.0 with the refactoring (https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86) opw-5275187 Forward-Port-Of: odoo/odoo#249476 Forward-Port-Of: odoo/odoo#238489
This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then re-approved, the total leave days were sometimes miscalculated. The fix ensures that all leave periods, including holidays and weekends, are accurately counted according to the sandwich leave rule.
Original PR description
## Steps to reproduce:- 1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday. - According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday). 2. Now refuse the Friday to Monday leave and re-approve again. 3. Now the leave count is updated to 5 days as it should be 6 days! ## Root cause:- On approve action the neighbor leaves where not recomputed. ## Fix:- - Override `_l10n_in_update_neighbors_duration_after_change` on approve action. - Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed. task-[5446346](https://www.odoo.com/odoo/action-4043/5446346) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244235
This update fixes an issue where archived accounts could be incorrectly assigned as default journal accounts. Previously, the system allowed assigning accounts regardless of their active status. Now, the system strictly uses only active accounts for journal defaults, maintaining data consistency and preventing potential errors in financial reporting.
Original PR description
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account…
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account is assigned by the onchange method. ### Issue: - Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange] (https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals. - This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts. ### Solution: - Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior. OPW-5501539 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request addresses several issues within the Hoot testing framework, focusing on improving test reliability and execution speed. Specifically, it fixes errors in test logging, ensures proper test failure reporting, and cleans up test environment setup to prevent issues between tests.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250382 Forward-Port-Of: odoo/odoo#247137
This update resolves a technical issue where keypress events were incorrectly triggering within Odoo's Hoot component. The fix ensures that keypresses are handled correctly, improving the overall responsiveness and functionality of the Hoot feature. This change primarily impacts the user experience.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#108516 Forward-Port-Of: odoo/enterprise#107286
This update optimizes how Odoo handles locale data, reducing unnecessary file system checks. Previously, the system was repeatedly searching for locale files even when they weren't being used, leading to slower performance. This change improves efficiency and reduces resource consumption.
Original PR description
`babel.Locale.parse` checks if a locale is valid by calling `os.path.exists` on the resolved filename for the locale (this is done in `babel.localedata.exists`). Babel does have a locale cache which it checks, but currently that cache is only populated when the locale is actually loaded[^1], therefore in cases where we instantiate a significant number of locales but never actually need to load locale data (e.g. formatting a significant number of datetimes, in qweb, using only non-localised patterns) this results in severe FS traffic for no reason. [^1]: python-babel/babel#1254 has been submitted to fix this issue Forward-Port-Of: odoo/odoo#250888 Forward-Port-Of: odoo/odoo#249795
This update resolves an issue where loyalty reward products were sometimes hidden within the Point of Sale (PoS) system. This change ensures that reward products are always visible and selectable during transactions, improving the customer experience and preventing lost sales. The fix was part of a larger effort to maintain the stability and reliability of the Odoo POS module.
Original PR description
Before this commit, a product used as a loyalty reward could be hidden in the PoS. opw-5918550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248925 Forward-Port-Of: odoo/odoo#248481
This update fixes a rounding issue that occasionally occurred in point-of-sale invoices. The change prevents unnecessary rounding, ensuring more accurate and reliable financial reporting. This update was a backport of a previous fix, addressing a minor but important detail in our POS system.
Original PR description
Backport of https://github.com/odoo/odoo/pull/247223. opw-5890586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249954 Forward-Port-Of: odoo/odoo#249834
A slow process for adding attribute values to products was identified and resolved. The update replaces inefficient database queries with faster methods, significantly reducing loading times from 8 minutes to 2-3 minutes. This improves the user experience for customers managing many product attributes.
Original PR description
opw-4876370 Issue: A customer who uses many attribute values complained that the "add to products" button on product attribute values in their database was really slow (8 minutes or so). Upon investigation I found parts of the involved functions used iteration over a set of records, which proved notably slower to psql searches. Fix: Replacing the code with what I believe is equivalent operations making use of the `search` method to filter through the sets much quicker. Behaviour after fix: The process takes 2-3 minutes when running this commit on the aforementioned database, but it's still a major improvement compared to the previous time. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232149
This update resolves a problem where archived employees incorrectly retained their appraisal dates, causing scheduling conflicts. The fix ensures that archived employee appraisal dates are cleared, preventing future issues when managing appraisal plans for companies.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108702 Forward-Port-Of: odoo/enterprise#100437
This update resolves a problem where updating a Bill of Materials (BoM) in a draft manufacturing order would incorrectly delete and then attempt to recreate related work orders, leading to errors. The fix ensures that work orders are only removed when they are no longer needed due to BoM changes, improving stability and preventing data inconsistencies.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#249336