Monday, August 25, 2025
17 changes · saas-18.3
Enhancements to existing features
This update improves electronic invoice validation for Australia/New Zealand, Malaysia, and Singapore so invoices are less likely to be rejected for missing tax or address details. It adds safer fallbacks and stricter checks where local PINT e-invoicing rules require specific tax, company ID, street, or postal code information.
Original PR description
Description of the issue/feature this PR addresses: - AU&NZ: Current behavior is that when VAT is not set on the partner, the tax category code defaults to zero. This becomes problematic with certain…
Description of the issue/feature this PR addresses: - AU&NZ: Current behavior is that when VAT is not set on the partner, the tax category code defaults to zero. This becomes problematic with certain rules (e.g. the tax totals of tax category code 'O' should have amount of zero, but current code can set this value to something other than zero). The change focuses on edge cases when VAT of partner is not set. Changes are not related to the Q2 2025 release changes. - MY: Added fallback for <cac:PartyTaxScheme> to always have <cbc:CompanyID>. Currently breaks if the partner does not have VAT set. Changes are not related to the Q2 2025 release changes. - JP: No changes are made. - SG: Invoice with taxes of certain tax category codes must have seller and buyer street address and post code. Added constraint to make sure they are set. New PINT SG rule adds one more tax category code (Standard Rate, SRRC). New code is added to `ubl_cii_tax_category_code` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222737
The Guatemalan electronic invoicing module now avoids heavy invoice data calculations during installation, reducing the risk of memory issues on large databases. It also no longer installs automatically with the base Guatemalan localization, giving businesses more control over when to enable it.
Original PR description
This commit adds `_auto_init` to the `account.move` object in the Guatemalan EDI that prefills all computed stored fields in the move object with null values. This prevents computation on those fields when installing the module, and also prevents MemoryError on large databases. task-5031330 Forward-Port-Of: odoo/enterprise#92881
Resolved issues and error corrections
Saudi electronic invoicing no longer blocks invoices when the invoice company differs from the journal company in standard branch setups. This helps businesses using branches generate the correct QR code and process invoices without unnecessary restrictions.
Original PR description
This commit removes the previously enforced restriction in https://github.com/odoo/odoo/commit/d6175d0552c18006913e969eac7006666164609c that required the company specified on an invoice to match the company specified on the associated journal and makes sure that the company used to create the QR is the appropriate company whether in a branch or in a main company task-5005477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223976 Forward-Port-Of: odoo/odoo#222935
The online store now uses smaller product image versions when processing large product lists. This helps prevent out-of-memory errors and improves reliability for shops with many products.
Original PR description
This commit fixes an "out of memory" error caused by loading the `image_1920` field into memory for a large `product.product` recordset. To resolve this, the code has been changed to use `image_128` to limit the memory impact. See also: - https://github.com/odoo/odoo/pull/222584 opw-4981983
Repeated global discounts now ignore tax amounts copied from the original sale order lines, preventing discounts from being calculated too high on already discounted orders. This keeps discount and tax totals accurate when users apply global discounts more than once.
Original PR description
When creating a global discount more than once, the values on the second time onward would be incorrect due to the manual tax amounts being propogated from the sale order lines. This would cause the discount amount to increase when discounting an already discounted sale order. This happened because manual tax amounts that were from the lines that the discount lines were created from were being propogated and used to attempt to find the correct tax amounts up to the target_amount_currency, but this is incorrect. Removing the manual tax amounts when the special type of the line is global_discount resolves this issue and allows multiple global discounts to be used. opw-4985380
Fully flexible employees can now request time off in hours as well as full days. This helps related apps such as Timesheets and Planning accurately record paid holidays and unavailable working periods.
Original PR description
In this PR, we allow fully flexible employees to take time off in hours or days, to allow other apps such as timesheet to encode their paid holidays or planning to use unavailable intervals Forward-Port-Of: odoo/odoo#217938
Accounting now handles manually adjusted tax amounts more accurately when preparing electronic invoices. It also improves how global discounts and returned items are spread across invoice lines, helping country-specific formats such as Mexico's CFDI report amounts correctly.
Original PR description
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts…
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. This commit also adds a new helper '_dispatch_global_discount_lines' that can be used to split the global discount lines across the others base lines. That way in EDI like Mexico, the global discount can be reported line by line as a discount per line and no longer a big discount applied on a single line. There is also another helper '_dispatch_return_of_marchandise_lines' that allows to dispatch negative lines using the quantity. For example, if you buy 3 times the same product but one is returned because broken, you will end up with a sell of 2 products instead of 3 but having a discount of 33.33%. This makes the difference when generating the mexican CFDI. task-id: 4926200 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale issue where starting a new order with a default preset that requires a customer name did not show the name entry popup. Staff will now be prompted as expected, helping restaurants capture the needed customer details for takeout or similar orders.
Original PR description
Steps to reproduce: - go to the setting of your pos.config - set the default preset as takeout (or any other that require the name) - open your pos - click on new order - the slot selection opens (only if set so it's ok) - but then no dialog to enter the name of the client Issue: The handleSelectNamePreset method in the POS Restaurant module attempts to access the selected preset through the order, but the preset has not yet been set on the order at that point. Fix: Make sure the preset is set on the order before calling handleSelectNamePreset. Task-5030520 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
The Point of Sale now handles new orders that do not yet have a preset assigned, avoiding a crash during customer selection or initial order loading. This keeps cashier workflows running smoothly when address-based presets are configured.
Original PR description
STEPS TO REPRODUCE: ---------------- - Open Point of sale - Create preset in the backend with Identification = Address (make it Default). - Open Register - Try to new order and select a customer. ISSUE: ------------------ - Crash occurs if the order has no preset set yet (e.g., during customer selection or initial load). CAUSE: ------------------- - Accessing the preset’s fiscal position and pricelist even when no preset is set. FIX: --------------------------- - Used optional chaining (?.) to safely access preset fields. TASK-5005015
Event calendar slots now keep the intended calendar date when the user and event are in different time zones. This prevents sessions from being created a day late in cases where timezone conversion crosses midnight, improving scheduling accuracy for event organizers.
Original PR description
Purpose ======= Fix the creation of slots at the wrong date. Specification ============= User timezone: Europe/Brussels Event timezone: America/Los Angeles When creating a slot on the calendar on the 10th of April from 8PM to 11PM, the slot is created from 8PM to 11PM but on the 11th of April. In scenario where the conversion from the local tz to the event tz changes the date, the slot is created at the wrong date. => After conversion, the DateTime 'zone' param needs to be set back to the local tz (without changing the converted times) to make sure the calendar renders records correctly as it always expects datetimes expressed in the 'local' tz. related PR: https://github.com/odoo/odoo/pull/205945 Task-4743999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The French point of sale compliance check now avoids loading extra order data that it does not need. This reduces memory usage substantially for businesses with large numbers of POS orders, helping the report run more reliably.
Original PR description
### Problem: Following this pr https://github.com/odoo/odoo/pull/217348, field prefetching is unnecessary when fetching orders, as all required fields are already fetched explicitly. Keeping prefetching enabled causes excessive memory usage. ### Benchmark | Orders | Before | After | |--------|---------|--------| | 1k | 6MB | 5.8MB | | 10k | 42MB | 27MB | | 100k | 534MB | 320MB | | 200K | 1.1GB | 646MB | opw-4901994 Forward-Port-Of: odoo/odoo#223535 Forward-Port-Of: odoo/odoo#222416
Opening a project could fail after a related app, such as Timesheets, was uninstalled because a saved embedded action still referred to fields from that app. The change safely hides unavailable embedded actions instead of crashing, allowing users to keep working normally.
Original PR description
The system failed to evaluate the embedded action, which refers to the Uninstalled module.
**Steps to produce:-**
- Install `Project` and `Timesheets`.
- Go to Project and open any project.
- Click on the `embedded action` icon and select Timesheets.
- `Save` the view from the `embedded action's icon`.
- Now, `Uninstall Timesheets`.
- Now, go to that Project and try to open it.
**Error:-**
`KeyError: 'allow_timesheets'
ValueError: Invalid field in filter of project.project:
[('allow_timesheets', '=', True)]`
**Solution:-**
- Added a safe check using `hasattr` to verify if the `python_method` defined on the embedded action actually exists on the specified model.
- Ensured that if the method is missing or invalid, the embedded action is marked as not visible instead of causing a crash.
**sentry-6738596751**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#218564Fixes an issue where removing text color or formatting in the HTML editor could cause the editor to get stuck. This makes editing content more reliable, especially when formatting is applied to larger text blocks or non-editable elements are selected.
Original PR description
**Current behavior before PR:** - When color was applied to a block-level element, attempting to remove it caused the `removeFormat` method to enter an infinite loop. - Removing formatting on a contenteditable false element infinite loop when removing format. **Desired behavior after PR is merged:** - Now, the color is correctly removed from the selected text, even when it is applied to a block-level element. - Now, the toolbar no longer opens when the selected element is contenteditable false task: 4575459 Forward-Port-Of: odoo/odoo#223786 Forward-Port-Of: odoo/odoo#198319
Restaurant table appointments are now correctly loaded in the Point of Sale when restaurant mode is enabled. This ensures staff can see upcoming table bookings on the floor plan, reducing missed reservations and improving service coordination.
Original PR description
Issue: The calendar envents that have a restaurant table ressource are not loaded in the pos if the config is in restaurant mode. Fix: If the config is a restaurant the calendar_event pos domain will return a domain containing the appointment_ressources linked to the config restaurant tables. This commit also fixes the test that checks for the appointment-label on the floor plan. Task-id: 4970986
Knowledge articles now save any pending edits before the page refreshes after moving another article nearby. This prevents users from accidentally losing their work and makes article editing more reliable.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494 Forward-Port-Of: odoo/enterprise#87937
Fixed an issue where automatic subscription invoicing could stop too early when a limited batch included subscriptions that were not ready to invoice. The scheduler now applies the limit after checking invoice eligibility, helping ensure ready subscriptions are invoiced on time.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884 Forward-Port-Of: odoo/enterprise#92690 Forward-Port-Of: odoo/enterprise#89787
Users with standard Appointment access can now create resource-based appointments from calendar events without hitting an access error. This restores the expected booking flow when an appointment type has a single resource, reducing disruption for staff managing appointments.
Original PR description
Before this commit, trying to create an appointment through a calendar event as an user will raise an AccessError. This is because in this fix #76653 we needed to make sure the appointment_resource_id is being set on the calendar event and for this we needed to make it readonly. This causes that an user, is not able to get the proper access rights to read on to the 'appointment.booking.line' which is being triggered since inside each booking line, we have an appointment_resource_id which is a many2one to the appointment resource. To fix this, we are adding a sudo on the booking lines when we only have 1 booking line and the appointment resource is set on the calendar event. This way, the user will be able to read the booking lines and create the appointment. opw-4614976 Forward-Port-Of: odoo/enterprise#90149 Forward-Port-Of: odoo/enterprise#88373