Friday, April 24, 2026
37 changes · saas-19.3
New functionality added to Odoo
This update adds support for a new type of Swedish blackbox device – Skattedosan – alongside the existing CleanCash support. This expansion allows Odoo to integrate with a wider range of point-of-sale systems used in Sweden, improving data capture and reporting capabilities.
Original PR description
The current Swedish blackbox driver is only for the CleanCash models of blackbox, however these are no longer produced as the company that makes them no longer exists. The blackboxes that are readily available today are branded as either Skattedosan or PosPlus, but they both come from the same company and use the same protocol. This commit adds a second Swedish blackbox driver that supports these Skattedosan blackboxes, using the same commands as the existing driver such that the frontend code does not have to change. Enterprise - https://github.com/odoo/enterprise/pull/114579 Protocol spec: https://skattedosan.se/images/CU_blackbox__API.pdf task-5212572 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260587
Resolved issues and error corrections
This update resolves an issue where automated tests, particularly those involving multiple modules, would fail due to incorrect test instance data. The fix ensures that test instances are properly initialized, allowing tests to run reliably. A more permanent solution is being considered to prevent this issue in the future.
Original PR description
Regenerating the test instance on retry works in most cases but fails when the test instance contains relevant data about what to test, which is the case for cross module tests and test params. Combined with an error while disabling autoretry this caused the hoot test to retry with an empty list. Fixing the issue by setting the relevant flags. This is a quick fix to reenable the test but a more robust solution would be to make sure ALL test instance existing attributes are properly copied before starting the test, or forbidding to set them on the instance before running them. Forward-Port-Of: odoo/odoo#261130
Code cleanup and technical improvements
This update removes redundant and outdated usage of the 'tracking_disable' context keys within Odoo tests. The changes improve test clarity, reduce potential issues related to tracking, and streamline the testing process. This simplifies the codebase and makes tests more reliable.
Original PR description
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in…
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in mind when asked to authors or when reading commit messages. Partly because people tend to copy-paste code patterns without really understanding the purpose of those. See individual commits for more details. USAGE IN TESTS Lots of tests use the 'tracking_disable' or 'mail_notrack' context keys. However I bet most of those are there just because they were copy pasted, and without any thinking about the usage * it is used on non-thread models (which shows writer did not check what it was about); * it is copy-pasted in multiple unit tests creating one data each time (which shows performance are not the matter here as the writer could use a setupClass); * most usage is done when creating records, although there is no tracking at create time. And even if someday tracking at create comes back it would not be a performance issue on a test db compared to current test workload (too much tests, tours that are slow, ...). It also deactivates creation message log and initial follower (if not root) but those insert should be fast; * mail.thread is part of the real life stack and should be tested in functional addons. It notably has an impact on followers which means ACLs, partner_id field setup, field computation and invalidation, cache usage, ... Better remove most of them, and keep only relevant one (e.g. batch creation, simulating environment like Payroll, ...). Task-6094598 Followup of Task-3645865
This update prevents customers without a portal account from seeing the 'Pay Now' button in follow-up emails. This change avoids confusion and ensures customers aren't directed to a process that won't integrate with their invoices. It simplifies the customer experience by aligning the button's availability with their account status.
Original PR description
If a customer has no portal account, the pay now button added to follow-up emails won't allow them to access any invoices on the portal. Even if they register afterwards, a separate account will be created and they won't have access to those invoices. To avoid confusion, this commit hides the pay now button when the customer has no portal account. task-6075621 Forward-Port-Of: odoo/enterprise#114698 Forward-Port-Of: odoo/enterprise#112891
This update resolves an issue where the 'cancel' button within the spreadsheet functionality didn't trigger the expected confirmation dialog. Now, when a user clicks the cancel button, the confirmation process is correctly initiated, ensuring a smoother and more reliable user experience. This improves data integrity and user satisfaction.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 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#260061
This update resolves an issue where the 'cancel' button within the documents spreadsheet functionality wasn't properly triggering the cancellation process. The fix ensures that clicking the cancel button now correctly removes the user's changes and returns them to the previous state. This improves the user experience and data integrity.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 Forward-Port-Of: odoo/enterprise#112987 Forward-Port-Of: odoo/enterprise#112304
This update prevents employees in Mexico from receiving early, unstamped payslip emails. Previously, a first email contained an incomplete payslip, followed by a second email with the finalized, stamped version – creating confusion. Now, emails are only sent with the stamped payslip after the CFDI is generated.
Original PR description
Currently, when a user confirms a payslip batch (hr.payslip.run), the base payroll module queues the PDF generation and sends an email to the employee with their payslip immediately. For Mexican payslips, this means the employee receives the email with an unstamped payslip (without CFDI UUID). Later, when the CFDI is generated, a second email is sent with the stamped version, confusing the employee. This commit prevents the email from being sent for Mexican payslips if the CFDI has not been generated yet, ensuring only the stamped payslip is emailed. Forward-Port-Of: odoo/enterprise#114731
This update resolves an issue where shared helpdesk ticket links would fail when the user who originally sent the message had been removed. The fix ensures that the link generation process handles deleted users gracefully, preventing errors and improving the reliability of shared links. This ensures a smoother experience for users sharing and accessing helpdesk tickets.
Original PR description
Currently, an error occurs when opening a shared helpdesk ticket link if the message author has been deleted. **Steps to Reproduce:(v19.2)** - Install Contacts and Helpdesk modules (with demo data). - Log in as "**Marc Demo**". - Create a helpdesk ticket and send a message via the chatter. - Log in as **Admin**. - Delete the demo user and the related partner from Contacts. - Go to Helpdesk > All Tickets and open the created ticket. - Click "**Share Ticket**" and open the generated link in another browser. Error: `ValueError - Expected singleton: res.partner()` **Cause:** When the partner linked to `message.author_id` is deleted, the recordset becomes empty, which raises a singleton error. Fix: This commit ensures that the author details are only included when the message author exists. sentry-7337698605 Forward-Port-Of: odoo/odoo#260767 Forward-Port-Of: odoo/odoo#254175
This update resolves an issue where deleting a document from a sign request would cause the page to crash. The fix now gracefully handles deleted documents by redirecting the user to a safe view, ensuring a stable user experience. This improves reliability and prevents data loss.
Original PR description
Steps to reproduce: - Open a sign request - Go to Details - Delete the document from the form view - The UI tries to reload the document Issue: The system tries to load a document that has already been deleted. Current behavior: An error is shown and the page crashes when trying to reload the deleted document. Expected behavior: The system should handle the missing document gracefully and redirect the user to a safe view. Fix: Handled the deleted document case properly by returning a valid response and redirecting the user instead of trying to load the removed document. task id- 6095120 Forward-Port-Of: odoo/enterprise#113094
This update fixes a display issue where invoices and bills created in time zones ahead of UTC (like GMT-12) were not appearing correctly in reports. The change ensures that dates are accurately reflected, resolving a discrepancy that prevented timely reporting. This improves the accuracy of financial data.
Original PR description
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC,…
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12. So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices after 12 PM. After this commit: To resolve this discrepancy we use the context_today date to get the user local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too. Steps to reproduce (Possible in runbot) : 1. Select etc/GMT-12 timezone in preferences [when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)] 2. Create a PO and Validate the quantity received. 3. Go to accounting>review>bills to receive. 4. the newly created PO won't be listed here. OPW: 6083526 Forward-Port-Of: odoo/enterprise#114763
This update simplifies how the system processes XML data for Slovak reports, reducing unnecessary complexity and improving performance. By using the standard XML parsing library, we've eliminated a custom configuration that was causing overhead. This change ensures more efficient report generation.
Original PR description
Removes the custom XMLParser configuration in favor of the default etree parser. This reduces unnecessary overhead and ensures we are using the standard library's recommended defaults for processing XML content. Forward-Port-Of: odoo/enterprise#114828
This update resolves an issue where images from CORS-protected sources weren't being optimized to WebP. By fixing this, the system now automatically converts multiple images, including those with CORS restrictions, to WebP, leading to faster loading times and reduced bandwidth usage for our users. This enhancement improves the overall performance and efficiency of the platform.
Original PR description
Since [1], when users select multiple images through the media dialog, subsequent images of a CORS protected image are not converted to webp. This commit fixes that issue. Related to task-5405262 [1]: https://github.com/odoo/odoo/commit/422b073bcc6406c76339a1ccaa0c40dc3f42801c Forward-Port-Of: odoo/odoo#261055
This update corrects an issue where emails sent from the applicant refusal wizard in the HR recruitment module were not populating with the correct applicant details. The fix ensures that the email subject and body now accurately reflect the chosen template and the specific applicant information, improving communication and accuracy in the recruitment process.
Original PR description
Issue: ---------------------------------------- The `applicant.get.refuse.reason` wizard displays the mail body with the placeholders, not the values actually sent. Steps to reproduce: ---------------------------------------- - Open Recruitments and go to an applicant form view - Click "Refuse" - Select the template "Job already fulfilled" - The subject and the mail body have placeholder values Cause: ---------------------------------------- We don't render the body for the wizard, only when we send the mails. Solution: ---------------------------------------- Render the body when we get it from the template. This only works if `applicant_ids` have one value. Otherwise, we display the placeholders because the values can be different from an applicant to another. opw-6082883 Forward-Port-Of: odoo/odoo#258874
This update resolves an issue where users without 'write' access to products couldn't print labels. The fix adds necessary permissions to allow read-only users to generate product and variant labels, improving usability for a wider range of users. This ensures consistent label printing functionality.
Original PR description
Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels Steps to reproduce: 1. Install Sales 2. Log in as Marc Demo…
Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels Steps to reproduce: 1. Install Sales 2. Log in as Marc Demo 3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu 4. An access error is raised Same issue happens for Product Variants Issue: https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`: https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239 Solution: Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2 opw-6111333 Forward-Port-Of: odoo/odoo#260513 Forward-Port-Of: odoo/odoo#260342
This update resolves a technical issue preventing the settings view tests from running correctly. The change ensures the tests wait for the search debounce timer to complete, allowing the tests to pass reliably. This improves the stability of the settings view.
Original PR description
Before this commit, the settings view tests were failing because a 500ms debounce was added to the search functionality in 1. This commit ensures that the test waits for the debounce timer to finish before continuing with the assertions. [1] https://github.com/odoo/odoo/commit/2c246214e62a9bd2ee7bd372cac99b55ed565a83
This update resolves an error that occurred when generating W2 reports without specifying an end date. The fix ensures the system defaults to the current year when no end date is provided, preventing a file generation failure. This ensures users can consistently create W2 reports without encountering this issue.
Original PR description
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined. Steps to replicate: - Install `l10n_us_hr_payroll`. - Open Payroll > Reporting > W2 Report. - Click…
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.
Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.
Error:
```
File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```
Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.
Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.
[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248
No ID
Forward-Port-Of: odoo/enterprise#114363
Forward-Port-Of: odoo/enterprise#113408This update fixes a problem where newly created events would unexpectedly have their website visibility turned off. The issue stemmed from an internal system process incorrectly resetting the website publication status, even when it should have been automatically managed. This change ensures the website visibility is correctly set upon event creation.
Original PR description
If you create a new event, and immediately toggle "website_published" before it is saved, the UI will toggle it off on its own. The reason is technical. As event tracks this field, it is read everytime the record is written to. In parallel `_finalize_publication` invalidates the website_published field even when it is protected. As the field is protected, the orm does not recompute the field when it is read but does fill in the cache with `False` even though it would have evaluated to `True` if computed. The issue here lies in invalidating a protected field, as `Environment.protecting` normally guarantees that the field will not be invalidated. We now stop invalidating protected records. task-6102144 Forward-Port-Of: odoo/odoo#257826
This update fixes an issue where child contacts of German companies were incorrectly flagged as companies by l10n_de_reports. The change ensures that only companies with their own distinct commercial entities are recognized as such, improving the accuracy of German tax reporting. This resolves a potential reporting discrepancy.
Original PR description
Problem: When l10n_de_reports is installed, child contacts of a German company are incorrectly considered as companies as well. Steps to reproduce: 1. Install l10n_de_reports. 2. Create a company with a German VAT number (e.g. DE123456789). 3. Create a child contact under that company. 4. The child contact will be incorrectly considered as a company. Cause: If l10n_de_reports is installed, any partner with a German VAT number (DE + 9 digits) is considered as a company. Since child contacts share the same VAT as their company, they would be considered as companies as well, which is not correct. However, a partner should only be considered as a company if they are their own commercial entity. https://github.com/odoo/odoo/blob/e6bd6b106c376336594edd868c09505032008ac1/odoo/addons/base/models/res_partner.py#L819 Forward-Port-Of: odoo/enterprise#114600
This update fixes an issue where product names on the Replenishment dashboard were being cut off, leading to a poor user experience. The pull request adjusts column widths to ensure product names are fully visible, enhancing usability and clarity for users managing stock replenishment.
Original PR description
Purpose: the name of the product in the replenishment dashboard often gets truncated which is bad for UX. Adjust column widths to make better use of space. task-5097352 Forward-Port-Of: odoo/odoo#259259 Forward-Port-Of: odoo/odoo#253384
A recent update to a test within the 'web' module caused a previous merge to fail. This commit corrects the test, ensuring future updates to the 'web' module are properly validated. This prevents potential issues with the module's functionality.
Original PR description
PR [1] added a record in the test data, which made an existing test fail. The PR should have never been merged as is, but due to a runbot issue, failing tests were ignored by the mergebot and the PRs were merged anyway. This commit fixes the failing test. [1] https://github.com/odoo/odoo/pull/256621 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that prevented a key test from running correctly, ensuring the stability of our account reporting features. The change ensures proper setup of the necessary environment within tests, preventing errors and improving the reliability of our automated testing process. This contributes to a more robust and dependable Odoo Enterprise system.
Original PR description
This test, when run alone, raised an error telling assigning directly self.env.companies was not the right way of doing this, and it was better to create a new env. For some reason, it didn't raise when run together with other tests ; so, runbot didn't see the issue. This commit aims at soothing the ire of Odoo's mighty tests spirits \o/ Forward-Port-Of: odoo/enterprise#114248
This update corrects a bug where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The fix ensures the button only appears for invoices with specific payment policies, preventing incorrect display when batch payments are involved. This ensures accurate invoice management for our Mexican clients.
Original PR description
- Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114261 Forward-Port-Of: odoo/enterprise#112520
This update ensures that custom fields used in Odoo's related field functionality are correctly recognized. Previously, a field needed to be searchable to be usable in this way. This change streamlines the process by directly checking the field's properties, preventing issues and ensuring consistent behavior across the system. This update avoids potential blocking of upgrades.
Original PR description
Following up on #259309. A field must be searchable to be used in the related path. To know it, we must go into the instantiated field on the model to read that property, as being stored is not necessary. This mixes two different levels of abstraction but is necessary to have more consistent behaviour and not to block valid related field going through searchable fields. We also do this check only when the registry is ready to avoid blocking upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260585
This update corrects a display issue in the Odoo Enterprise portal. Previously, running subscriptions showed the total subscription amount in the sidebar title. Now, it accurately displays the next billing amount, providing users with clearer information about their upcoming payments. This improves transparency and simplifies subscription management.
Original PR description
Running subscriptions were showing the total amount in the portal sidebar title instead of the next billing amount. Display the next billing amount for running subscriptions. task-6125080 Forward-Port-Of: odoo/enterprise#114083
This update resolves a technical test failure within the Enterprise version of Odoo's timesheet feature. The fix ensures that the correct system calls are executed when leaderboard settings are enabled in the timesheet grid, improving the stability and reliability of the feature. This change primarily impacts internal testing and development.
Original PR description
This commit checks the steps expected once the leaderboard settings in timesheet grid is enabled to make sure the RPCs called are correctly done as expected. runbot-error-243315 Forward-Port-Of: odoo/enterprise#115029
This update clarifies the helpdesk stage Kanban view by removing the confusing "Days to rot" number display. Previously, users couldn't understand the meaning of this value. This change improves usability and reduces potential confusion for support staff.
Original PR description
Currently, only the “Days to rot” number is displayed, so users cannot understand what the number represents. In this commit, it hide from the helpdesk stage kanban view. task-5485507 Forward-Port-Of: odoo/enterprise#114880 Forward-Port-Of: odoo/enterprise#114781
This update fixes a minor issue where the company logo wasn't appearing on the journal audit export template. The fix ensures the necessary CSS class ('o_content') is included in the template, correctly applying the logo and improving the visual presentation of reports. This resolves a cosmetic problem impacting user experience.
Original PR description
before this commit, the export template of the journal audit was missing the o_content and so the company logo class was not applied opw-6128819 Forward-Port-Of: odoo/enterprise#114782
A bug was causing night shift templates to incorrectly span an extra day. This update corrects a calculation error within the shift planning process, ensuring that night shift durations are accurately reflected. This fix prevents over-extended shifts and improves the reliability of our scheduling functionality.
Original PR description
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ----------------------------------------…
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ---------------------------------------- - Create a planning shift template form 23h to 1h the next day (2h) - It must have a span over 2 working days - Create a shift and use this template - The shift spans over one more day Cause: ---------------------------------------- In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day. Solution: ---------------------------------------- We should call `plan_days()` without the hour specified so we make sure the first day is included in the count. opw-6134844 Forward-Port-Of: odoo/enterprise#114825 Forward-Port-Of: odoo/enterprise#114616
A recent update introduced a failing test in the web interface related to data limits. This commit resolves the underlying issue, ensuring the test now passes correctly. This prevents potential disruptions to the user experience.
Original PR description
PR [1] introduced a count limit test in v18, which was forward-ported to master/19.3. However, the forward-port was merged despite a silent failure caused by CSS changes in PR [2]. This commit fixes the failing test. [1] #259562 [2] #255332
This update streamlines the handling of 'Unreachable' project tags by utilizing a pre-defined XML record instead of dynamic creation. This change improves stability and efficiency, ensuring consistent tag management within the Odoo Enterprise system. The old method has been removed and replaced with a more reliable approach.
Original PR description
Replace dynamic creation of the "Unreachable" tag with a static XML record `project_tag_db_unreachable` and use `env.ref()`. Remove the old helper method `_get_unreachable_tag_id()` and update tests accordingly.
This update corrects a technical issue that was causing some automated tests to fail in the Odoo timesheet module. The problem stemmed from a recent change in how floating-point numbers were formatted, specifically the removal of trailing zeros. This fix ensures that the tests accurately reflect the current functionality and prevents future test failures.
Original PR description
Before this commit, some hoot tests in hr_timesheet module failed because the formatting of float field in timesheet uom widget now removes the trailing zeros since the merge of #256621 This commit adapts the hoot tests.
This update corrects a technical issue where a duplicate record was incorrectly introduced in the French reporting module (l10n_fr_reports). This fix ensures data integrity and prevents potential reporting errors related to audit returns. The change is a minor correction to the existing system.
Original PR description
this forward port wrongly introduced an already existing record https://github.com/odoo/enterprise/pull/114739
This update fixes a technical issue where a key event wasn't being properly sent during a process, causing test failures. The change ensures the necessary parameters are included in the `BUS:OUTDATED` event, improving the stability and reliability of the Odoo system. This resolves a reported bug and confirms the system's continued functionality.
Original PR description
Since [1], the `BUS:OUTDATED` should be sent with the `unregisterMultiTab` parameter. But a call site doesn't send it, leading to test failures. [1]: https://github.com/odoo/odoo/pull/260380 fixes runbot-243238,243240,243239 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where users were incorrectly prompted with a zero-demand warning during immediate receipt validation via barcode scanning. The change bypasses this warning for immediate transfers, streamlining the process and preventing unnecessary interruptions. This ensures accurate and efficient receipt processing.
Original PR description
Issue before this commit: ========================= When validating an immediate receipt, the user gets a zero-demand warning wizard, even though quantities are actually being received. Steps to Reproduce: ========================= - Install the stock_barcode module - Create an immediate receipt. - Validate it. - The zero-demand warning wizard appears. Cause of the issue: ========================= This behaviour was introduced in a [PR](https://github.com/odoo/odoo/pull/241646/changes/0238ff2cdd58524da1d7fccb411a94d2bce73094) to warn users when confirming/validating a picking with zero-demand moves. However, for immediate transfers, demand (product_uom_qty) is always 0, so the condition is always true and the wizard is always shown, even when quantities are being processed. With This Commit: ========================= Avoid showing the zero-demand warning wizard when validating an immediate picking from the barcode interface.
This update corrects a display issue where the tip amount was incorrectly formatted (showing '415' instead of '4,15') when users overpaid in certain locales. The fix ensures the tip amount is correctly displayed based on the user's selected decimal separator, improving the user experience and accuracy of tip calculations.
Original PR description
Steps to reproduce 1. Set language decimal separator to "," and thousands separator to "." 2. Open PoS, create an order (e.g. total 17.85) 3. Pay more than the total (e.g. 22) 4. Open the Tip popup —…
Steps to reproduce
1. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415
Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.
opw-5895622
Forward-Port-Of: odoo/odoo#255273A technical issue preventing the 'Gelato: Order status update' email template from saving correctly has been resolved. The fix addresses a browser normalization problem that incorrectly rendered HTML, causing an error. This ensures the email template functions as expected.
Original PR description
**Steps to reproduce:**
- Go to Technical > Email > Email Templates
- Try to edit and save "Gelato: Order status update"
- QWebError is raised: `KeyError: 'tracking_data'`
**Issue:**
Browser html normalization silently move block elements such as `<ul>` outside `<p>` when rendering the template body_html as it is invalid html. This moved the `t-foreach="ctx['tracking_data']"` evaluation outside the surrounding `<t t-if="ctx.get('tracking_data')">` which triggered the error.
**Fix:**
Removed `p` element to use the outer `div` and avoid the issue for now.
related: https://github.com/odoo/odoo/commit/b24974d64c3afe5febdad9abff9cb23a333f1ada
similar: https://github.com/odoo/odoo/pull/256605
opw-6114223
Forward-Port-Of: odoo/odoo#259548When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in mind when asked to authors or when reading commit messages. Partly because people tend to copy-paste code patterns without really understanding the purpose of those. See individual commits for more details. USAGE IN TESTS Lots of tests use the 'tracking_disable' or 'mail_notrack' context
Original PR description
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in…
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in mind when asked to authors or when reading commit messages. Partly because people tend to copy-paste code patterns without really understanding the purpose of those. See individual commits for more details. USAGE IN TESTS Lots of tests use the 'tracking_disable' or 'mail_notrack' context keys. However I bet most of those are there just because they were copy pasted, and without any thinking about the usage * it is used on non-thread models (which shows writer did not check what it was about); * it is copy-pasted in multiple unit tests creating one data each time (which shows performance are not the matter here as the writer could use a setupClass); * most usage is done when creating records, although there is no tracking at create time. And even if someday tracking at create comes back it would not be a performance issue on a test db compared to current test workload (too much tests, tours that are slow, ...). It also deactivates creation message log and initial follower (if not root) but those insert should be fast; * mail.thread is part of the real life stack and should be tested in functional addons. It notably has an impact on followers which means ACLs, partner_id field setup, field computation and invalidation, cache usage, ... Better remove most of them, and keep only relevant one (e.g. batch creation, simulating environment like Payroll, ...). Task-6094598 Followup of Task-3645865