Thursday, April 23, 2026
23 changes · saas-19.1
Resolved issues and error corrections
The refusal wizard now avoids automatically selecting email templates that have been archived. This prevents outdated templates from appearing pre-filled when users refuse an applicant, helping keep the workflow clearer and less error-prone.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to reproduce: ------------------------- 1. Install hr_recruitment. 4. Go to Recruitment > Applications > All Applications and open an applicant. 5. Click on the "Refuse" button to open the refuse wizard. 6. Click on the "Email Template" and click on 'Search More' 7. Observe available templates Issue: ------- If a refuse reason is linked to an archived email template, the wizard automatically pre-fills that archived template Cause: ---------- The `_compute_template_id` method automatically assigns the template from the refuse reason without checking whether the template is active, which allows archived templates to be pre-filled in the wizard. https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96 Solution: ----------- - Update `_compute_template_id` to ensure only active templates are automatically assigned. opw-5974244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257580 Forward-Port-Of: odoo/odoo#251186
Project chatter will no longer automatically post tracking messages when a linked Sales Order changes status. This reduces unnecessary activity in the record history and keeps the chatter focused on more relevant project updates.
Original PR description
Before this commit: - The chatter on the Project record tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `project.project`, `project.task` models. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/odoo#258549
Helpdesk tickets will no longer automatically post chatter messages when the linked Sales Order changes status. This reduces noisy activity in ticket conversations and keeps the discussion focused on customer support updates.
Original PR description
Before this commit: - The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/enterprise#114078
A display issue could turn normal percent signs into doubled percent signs in rendered website content. This fix ensures text is shown exactly as entered when no placeholders are involved, preventing awkward or incorrect page copy.
Original PR description
`_compile_format` unconditionally escaped `%` to `%%` to protect against Python's `%`-formatting, but only appended the `% (values,)` formatting operation when `#{...}` placeholders were present. With no placeholders, the escape was never undone and `%%` leaked into the rendered output.
This went unnoticed until the introduction of paramteric t-call: https://github.com/odoo/odoo/commit/eb6e88a25050
And since we use `.translate` and `.f` directly in existing views this became apparent
Example:
```xml
<t t-call="website.s_wd_testimonial"
_testimonial_quote.translate="...by 400%."/>
```
will be rendered as `...by 400%%.` on the page.
To prevent this, we can simply check for the absence of values and simply return the repr as is if there isn't any.
Forward-Port-Of: odoo/odoo#260434This update removes an outdated requirement for country information on payment tokens used for subscription invoices. Previously, this restriction caused processing issues, but modern payment providers now support invoices without country details. This change improves invoice processing reliability and efficiency.
Original PR description
Before this commit, a country was mantadory on the payment token when it was used to pay invoices of subscriptions. This behavior was fetched back from internal code in 15.3. This issue was not visible until recently. Some token are fine without country, the provider allows it but the cron fails to process the sale order when the contract is processed. THis commit remove that old constraint. opw-5268156 task-5349998 Forward-Port-Of: odoo/enterprise#100166
This update prevents customers without a portal account from seeing the 'Pay Now' button in follow-up emails. This avoids confusion and ensures customers aren't directed to a portal they can't access, streamlining the invoicing process.
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#112891
This update resolves an issue preventing developers from creating new, empty Odoo repositories for testing and development. The change relaxes a validation check, allowing empty repositories to be created without errors, which improves the development workflow. This ensures developers can easily start new projects without encountering initial setup problems.
Original PR description
Initialize a new empty git repository where you are going to vide-code some new Odoo modules. Because the repository is empty (no addon yet) the CLI fails with an "option --addons-path: the path <path> is not a valid addons directory". This makes vide-coder sad, and bigrams want vide-coders to be happy, so drop the sanity-check and also accept empty addons. Forward-Port-Of: odoo/odoo#259007 Forward-Port-Of: odoo/odoo#256913
This update fixes an issue where scanning GS1 barcodes with leading zeros (like EAN-13 codes) wasn't working correctly. The fix ensures that products are accurately identified when scanning these barcodes, preventing errors during sales transactions. This improves the reliability of the Point of Sale system.
Original PR description
When scanning a GS1 barcode whose GTIN-14 has a leading zero (e.g. a product stored with EAN-13 "5400000002649" is encoded as GTIN-14 "05400000002649"), the product lookup in _getProductByBarcode failed because the exact string did not match the stored barcode. opw-6117948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259199
This update corrects a bug where night shift templates created with specific start times would incorrectly extend shift durations by one day. The fix ensures accurate calculation of shift lengths when using templates, preventing overestimation of work time. This improves the reliability of shift planning.
Original PR description
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
This update fixes an issue where the ‘Scan the QR code to pay’ message on kiosk online payment pages was consistently displayed in English, regardless of the user’s selected language. Now, the payment page will correctly display the QR code instructions in the language the user has set for their Odoo instance, improving the user experience for international kiosk payments.
Original PR description
Currently if you use an online payment with the kiosk, the payment page with the QR code is not translated. Steps to reproduce: ------------------- * Create an online payment method with demo * Install any language, you don't need to switch * Open kiosk configurations * Set the online pm in the available payment methods * Set the language istalled as the default language * Make an order, go to payment page > "Scan the QR code to pay" is written in english no matter the language opw-6074194 Forward-Port-Of: odoo/odoo#259895
This update resolves a problem where the website's interactive tour wouldn't consistently disappear after use. The fix ensures the tour's iframe is fully loaded before the edit mode is initiated, improving the user experience and preventing unexpected behavior.
Original PR description
This commit fixes a non-deterministic problem of the tour by ensuring the iframe is ready before opening an edit mode. runbot-240987 Forward-Port-Of: odoo/odoo#260309
This update streamlines the payment refresh button in the Odoo Enterprise system. Previously, the button was always visible, leading to unnecessary checks. Now, it only appears for payments that are actively being processed (pending or unsigned), optimizing system performance.
Original PR description
… batches The refresh button was always shown, which could cause unnecessary calls to OdooFin if the payment is finalised (accepted, rejected or canceled). With this change, the button is shown only for payments in progress (pending or unsigned). task-6103900 Forward-Port-Of: odoo/enterprise#113182
This update resolves an issue where close buttons on web views without names triggered unexpected behavior in the system. Now, the system accurately identifies when a close button is used, ensuring proper tracking and functionality. This improves the reliability of web view actions.
Original PR description
View buttons with no name cause onClosed to be called without any parameters even if special=true or dismiss=true. This commit fixes that which allows to know if a close/discard button caused the action onClosed callback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260482 Forward-Port-Of: odoo/odoo#260301
This update resolves compatibility issues with Python 3.14 and the Ubuntu Resolute operating system. The changes include necessary opcode additions and improvements to data handling, ensuring continued stability and functionality of Odoo.
Original PR description
Forward-Port-Of: odoo/odoo#258568
This change simplifies the setup of the Mollie payment method in POS. Previously, a validation error blocked users from saving their configuration, requiring them to repeat steps. Now, users can complete the initial setup once, and an error will still appear if the API key isn't provided before a payment is made.
Original PR description
Before this commit, when configuring the Mollie payment method in POS, a validation error would be raised if the associated payment provider did not have the API key set. While this makes sense given that it needs to be set in order for payments to work, it resulted in this unintuitive UX: 1. User fills in all the fields in the Mollie POS payment method form. 2. The user tries to save, but hits the validation error. 3. The user uses the internal link to go to the payment provider and fill in the API key. 4. The user returns to the POS payment method form, but because the form couldn't save they have to fill in everything *again*. This commit removes the validation error, allowing everything to be filled in just once. There will still be an error if trying to make a payment without an API key set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260293
This update corrects a visual issue on the subscription portal where product lines weren't correctly aligned with tax totals. The change ensures that only invoiceable products are displayed, resolving the mismatch and providing accurate tax calculations for customers. This improves the clarity and reliability of subscription information.
Original PR description
Previously, the portal view for subscriptions displayed all un-collapsed products from the sales order, ignoring whether they were actually invoiceable lines. This caused a visual mismatch where the displayed lines did not correspond to the calculated tax totals at the bottom of the view. This commit updates the visibility logic to ensure that product lines are only included if they are invoiceable. task-6128619 Forward-Port-Of: odoo/enterprise#114088
This update fixes a previous issue where invoice settlement could fail if the commercial partner information wasn't fully loaded. The change streamlines the process by directly using the partner ID from the invoice data, preventing errors and ensuring smooth invoice settlement. This improves the reliability of the POS system.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#113852 Forward-Port-Of: odoo/enterprise#111957
This update fixes an issue where floors were incorrectly displayed in the restaurant POS system. Previously, floors were loaded through indirect processes, leading to inaccurate floor selections. Now, the system correctly shows only the floors directly assigned to the current restaurant configuration.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259537 Forward-Port-Of: odoo/odoo#257113
This update fixes an issue where child contacts of German companies were incorrectly flagged as companies when the l10n_de_reports module was installed. The change ensures that only companies with their own distinct commercial entities are recognized as such, improving the accuracy of German tax reporting. This prevents misclassification and potential reporting errors.
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
This update resolves a problem where activity updates weren't reliably shared between Odoo tabs. The issue stemmed from interference with a specific internal route (`/mail/data`) during testing. This fix ensures activity updates function consistently, improving the reliability of testing and the overall user experience.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 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#260529 Forward-Port-Of: odoo/odoo#260265
This update resolves a bug where users with limited permissions were encountering errors when accessing task details within subscription orders. The fix involves simplifying data retrieval to prevent privilege-related access issues, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update streamlines the way Odoo processes XML reports within the l10n_sk_reports module. By using the standard XML parser, we've reduced unnecessary complexity and improved performance. This change ensures more efficient report generation and maintenance.
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.
This update ensures that service order line display names accurately show the price unit when requested, regardless of context. Previously, the display name was inconsistent, potentially omitting the price unit for service products. This fix corrects a bug related to how the 'with_price_unit' context flag is used, improving the clarity and accuracy of service order information.
Original PR description
Before this commit, when `formatted_display_name` is true in the context, the display name of `sale.order.line` records will always show the partner and the price unit if it contains a service product. The problem is `with_price_unit` is no longer checked in the context to really know if we want to display or not the price unit in the formatted display name. This commit checks `with_price_unit` in the context to display the price unit in the formatted display name if it is truly in the context.