Tuesday, September 16, 2025
34 changes · saas-18.3
Resolved issues and error corrections
Very small negative amounts that round to zero now appear as "0.00" instead of "-0.00" on printed PDFs. This prevents confusing or misleading totals on business documents while keeping the actual rounding behavior unchanged.
Original PR description
Previously, when an amount value that is passed to `value_to_html` is a really small negative number (e.g. -0.000000001), the rounded result will have the negative sign in front of it (e.g. "-0.00").
This commit fixes it so that they will be rendered without the negatives ("0.00").
opw-4685953
Forward-Port-Of: odoo/odoo#224292The accounting KPI summary now includes posted accounting entries that still need an accountant's review, not only draft entries. This gives teams a more accurate view of pending accounting work by journal category, helping them prioritize follow-up tasks.
Original PR description
The `kpi.provider:get_account_kpi_summary` method should count draft moves by category, but also include posted moves that still are to be checked by the accountant. Task-id: 5062431 Forward-Port-Of: odoo/odoo#227091 Forward-Port-Of: odoo/odoo#226411
This fix prevents Ecuadorian delivery guides from failing when the Barcode Scanner option is turned off in Inventory. Businesses can now generate the required delivery documents reliably regardless of whether barcode scanning is enabled.
Original PR description
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch…
Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings. **Steps to reproduce:** - Install the `l10n_ec_edi_stock` module and switch to the `EC company`. - Uncheck `Barcode Scanner` in the Inventory `settings`. - Create a new warehouse and set the `Entity` and `Emission Point`. - Navigate to Inventory > Operations > Deliveries and create a new delivery. - Add details > mark as Todo > Validate > Generate Delivery Guide. **Error:** `AttributeError: 'stock.move.line' object has no attribute 'qty_done'` **Root Cause:** At [1], the code references `line.qty_done`, but this field is defined in the `stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, the field is not available, leading to the `error`. **Fix:** This commit updates the delivery guide values to use `line.quantity` instead of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3], `qty_done` is derived from `quantity`. [1]: https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354 [2]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23 [3]: https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50 [4]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165 sentry-6851008674 Forward-Port-Of: odoo/enterprise#93775
The Time Off app no longer crashes when an employee has more than one running contract across different periods. This ensures HR users can manage leave normally for employees with multiple active contract records.
Original PR description
**Step to Reproduce** - install hr_contract and hr_holidays module - go to employee -> contracts - Add 2-3 contract to a employee, which can be done by having contracts in different interval (but…
**Step to Reproduce**
- install hr_contract and hr_holidays module
- go to employee -> contracts
- Add 2-3 contract to a employee, which can be done by having contracts in different interval (but same year)
- set their stage to `running`
- open Time off App
**Observation:**
- we receive a traceback
```
File "/data/build/odoo/addons/hr_contract/models/hr_employee.py", line 229, in _get_unusual_days
tmp_date_from = max(date_from_date, selected_contract.date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
record.ensure_one()
File "/data/build/odoo/odoo/orm/models.py", line 5635, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.contract(1, 2)
```
**Cause:**
- `_get_unusual_days` assumes that there is only one running contract
- Hence with multiple contract, it raises traceback
Fix:
- Adjust the method to accept multiple contracts
opw-5045306
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225521Mexican electronic invoice PDFs now show the same customer fiscal regime as the official CFDI XML when invoicing a child contact under a company. This prevents discrepancies between customer-facing invoice documents and legally reported tax data.
Original PR description
In l10n_mx: - Create a child contact under a company contact. - Set the fiscal regime of the child contact to one different from the company’s fiscal regime. - Create an invoice with the child contact and send it to the CFDI. In the XML, the fiscal regime used is the company’s, whereas in the PDF it is the child contact’s. This commit applies the same logic from _add_customer_cfdi_values to the PDF generation. After this change, the fiscal regime shown in the PDF will be the company’s, consistent with the XML. opw-4989605 Forward-Port-Of: odoo/enterprise#94259 Forward-Port-Of: odoo/enterprise#92482
Public visitors could hit a Forbidden error in the online shop when fiscal settings were calculated from their location. The update ensures those settings can be read correctly, keeping the shopping experience available for anonymous customers.
Original PR description
Ensure the fiscal position is always computed using sudo. When computing the fiscal position based on geolocated country, the result may not be return without sudo. Steps to reproduce: - Set a default Fiscal Position on the contact model (property_account_position_id) - Visit the website shop without logging in. - You will get a Forbidden error because Odoo raises an access error when fetching the fiscal position. This fix add a sudo() to the partner used to compute the fiscal position, so that when accessing the partner property, it will be returned with `env.su = True`. opw-5058588 Forward-Port-Of: odoo/odoo#225481
The portal signature form now works correctly even when it is placed directly on a page instead of inside a pop-up window. This prevents an error that could block users from completing signature steps in some portal flows.
Original PR description
Description of the issue/feature this PR addresses: Be able to use the portal signature form outside of a modal. Current behavior before PR: If the signature form (```<t t-call=“portal.signature_form”>```) is used outside of a modal, an error occurs: ```TypeError: Cannot read properties of null (reading 'addEventListener')``` Desired behavior after PR is merged: The signature form can be used outside of a modal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224564
Opening the duplicate transactions wizard directly no longer triggers an error when no accounting journal is linked. This improves reliability for users accessing accounting views and prevents an unexpected crash in this edge case.
Original PR description
Currently, an error occurs when users try to open the view directly. Steps to reproduce: --- - Install `Accounting` module - Using Open View, Open `account.duplicate.transaction.wizard` view Traceback: --- `ValueError: Expected singleton: account.journal()` This error occurs because no account journal is linked to the wizard at [1], resulting in an empty `account.journal`. [1]- https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L32 sentry-6812500330 Forward-Port-Of: odoo/enterprise#94538
The printer interface now keeps running if the system encounters an error while adding a printer, such as a read-only filesystem or invalid printer name. These errors are logged for follow-up instead of interrupting printer operations, improving reliability for IoT printing setups.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227121
Branch companies can now confirm sales orders that use loyalty programs from their parent company without hitting an access error. This ensures loyalty history is recorded correctly when businesses operate with parent and branch company structures.
Original PR description
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a…
If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised. Steps to reproduce: ------------------- * Create a loyalty cards program * Set company to the current company * Create a branch company for the current one * Switch to branch company * Create a sale order, no need to add products, just a partner * Try to confirm the order > Observation: Access Error: > Sorry, Mitchell Admin (id=2) doesn't have 'create' access to: > -History for Loyalty cards and Ewallets (loyalty.history) Why the fix: ------------ Here's where the access error is being triggered: https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106 Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history. Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company. opw-5055999 Forward-Port-Of: odoo/odoo#226226
Website sitemaps now avoid listing the same page more than once when website controllers are customized or extended. This helps keep sitemap data cleaner for search engines without changing which pages are included.
Original PR description
When extending controllers (e.g. `WebsiteSale.shop`), sitemap entries were duplicated because deduplication relied on the endpoint function object. Overridden methods result in different function objects but identical sitemap URLs, leading to duplicates. This commit fixes the issue by deduplicating on the generated sitemap location (`loc['loc']`) instead of the function object, ensuring unique URLs in the sitemap even when controllers are extended. Fixes #224193 Forward-Port-Of: odoo/odoo#226810 Forward-Port-Of: odoo/odoo#224406
Fixed an issue that caused FedEx Home Delivery return label generation to fail with an address error. The return shipment request now correctly marks the recipient address as residential, helping users complete FedEx home delivery workflows without manual workarounds.
Original PR description
**PROBLEM** When selecting FedEx Home Delivery service, and enabling the return label generation, we got the error `RECIPIENT.ADDRESS.ERROR`. **STEPS TO REPRODUCE** 1. Install delivery_fedex_rest (use the new fedex credentials). 2. On the FedEx US shipment method (demo data) select FedEx home delivery service, and check the `Generate Return Label` option. 3. Create a SO, add shipping with FedEx US, validate the SO. 4. Validate the delivery order, and notice the FedEx API return an error. **CAUSE** For Home Delivery Service, the recipient address need to have the `residential` flag set to true. In `_return_package()`, the request sent doesn't include this flag, leading to an error. **FIX** Fix `_return_package()` query to include the `residential` flag. opw-4939065 Forward-Port-Of: odoo/enterprise#94463
Fixed an issue that could prevent Razorpay OAuth webhook generation when website payments are enabled. The change ensures payment connection URLs are built correctly, avoiding authentication failures caused by accidental double slashes.
Original PR description
A bad URL could be generated when the `website_payment` module is installed, as it overrides `get_base_url` and may return a URL ending with `/`. Using f-strings to create URLs could result in a double slash `//`, causing errors. Steps to reproduce: - Install `website_payment` and `payment_razorpay_oauth` - Go to Payment Acquirers and connect via OAuth - Click "Generate your webhook" - "Authentication failed" error appears This fix uses `url_join`, like other payment providers, to build URLs correctly and avoid the double slash issue. opw-5079295 Forward-Port-Of: odoo/odoo#226639 Forward-Port-Of: odoo/odoo#226248
Tax return reports for UK and New Zealand companies now follow the company's configured fiscal year instead of assuming a calendar year. This ensures invoices are included in the correct tax quarter when the fiscal year ends on a date other than December 31.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_uk_reports - Switch to a British company (e.g. UK Company) - In Accounting settings, set the last day of the fiscal year to another date than "December 31" (e.g. "January 31") - Create some invoices with tax between the 1st of January and the 30th of April - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the "Tax Report (GB)" for the first quarter (i.e. Tax Q1) **Issue: (same issue for NZ localization)** The Tax Report is ignoring the configured date of the fiscal year. All the invoices from January are included and those from April are excluded. It should be the opposite. **Solution:** Override the "_get_start_date_elements" method for the British tax report that allows to define the start date. opw-4939971 opw-5067877
The appointment booking page now shows the right number of people that can be booked when multiple resources have different capacities. This prevents customers from seeing an artificially low limit and helps businesses make full use of available appointment capacity.
Original PR description
**How to reproduce:** - Create an appointment with availability assigned to a resource. - Enable 'Manage Capacity' - Set the capacity of the first resource lower than the second one. - Open the appointment's booking page. **Technical Reason:** If appointment is scheduled based on 'resource_time' then resource_default is updated as the first value of resource_possible. Related PR: https://github.com/odoo/enterprise/pull/47059 **After this PR:** 'Number of people' dropdown will display the maximum capacity from all available resources. Task-4664393 Forward-Port-Of: odoo/enterprise#84243
This fixes subscription recurring totals when taxes are calculated by an external service. It ensures customers and staff see totals based on the externally calculated amounts instead of Odoo recalculating them differently.
Original PR description
sale_subscription now uses `account.tax` to recalculate the tax amounts [1], thus bypassing amounts set by external calculators. For externally calculated orders, we override the recurring_total calculation to restore the previous behavior of calculating the amount using `price_subtotal` on the lines. This field will contain the amount returned by the external calculator. [1] https://github.com/odoo/enterprise/commit/70376f94e9f26e631890312edc0857d9ff37dc7b opw-4964610 Forward-Port-Of: odoo/enterprise#93567 Forward-Port-Of: odoo/enterprise#93054
Company logos on Point of Sale receipts now load more reliably, including on iOS devices and when browser caching is disabled. This helps ensure receipts consistently show the correct branding for customers.
Original PR description
Some clients reported that the company logo was not displayed on receipts. This issue was reproducible when using iOS with a large logo file, and in some cases when the browser cache was disabled. This commit addresses the issue by: - Using the image_256 version of the company logo to fix rendering on iOS. - Storing the logo as data url to avoid repeated URL requests and cache-related issues. Task-5055910 Sample company logo causing issue [logo.zip](https://github.com/user-attachments/files/22251877/logo.zip)
A test was adjusted to avoid rare false failures caused by an internal database identifier containing a specific number sequence. This helps keep automated checks stable without changing any customer-facing behavior.
Original PR description
The database_id is an uuid. It can happen that it contains the substring "1337". The test only needs to check if the value is not in the "prompt" or "conversation_history" keys. Thus we can remove the "database_id" key runbot-198561
Member users can now use AI field buttons when prompts include Studio-created fields, without being blocked by an unrelated email template permission error. This makes AI-assisted field completion more reliable for everyday users working with customized Odoo apps.
Original PR description
[FIX] tools: Fixed AI field prompt access rights Description of the issue/feature this PR addresses: 'Member' users can use the AI field button when the prompt contains standard field references.…
[FIX] tools: Fixed AI field prompt access rights Description of the issue/feature this PR addresses: 'Member' users can use the AI field button when the prompt contains standard field references. When the prompt contains a Studio field reference, there is an error message stating 'email template editor' access is required. Current behavior before PR: -Create an internal 'Member' user -Add a 'user' group for the app you want to test on (bug spotted in Helpdesk). -Make a plain text Studio field -Make a text AI field where the prompt references the plain text Studio field you just created. -Make a text AI field where the prompt references a standard available field. -Log into the database as the 'Member' user -Push the 'AI' button on each of the two fields you created. -The one referencing the standard field should populate as normal; the one referencing the Studio field will trigger an error message asking for 'Email template editor access'. Desired behavior after PR is merged: Allowing AI fields unrestricted access to render template when stuudio field is used to avoid access error. Task-5016767
Saudi e-invoices for foreign customers now use the required alphanumeric Other Buyer ID format. This helps avoid acceptance warnings from ZATCA and improves compliance for invoices issued to non-Saudi customers.
Original PR description
When an invoice is being issued to a Foreign Customer, the Other Buyer ID (Other Buyer ID (BT-46) <cac:AccountingCustomerParty / cac:Party / cac:PartyIdentification / cbc:ID>) should be OTH and filled accordingly to avoid an acceptance warning from ZATCA. According to ZATCA, the value needs to be in alphanumeric format, even if the value does not follow the specific country's VAT format Task-id: 5075005 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#226593
Italian split payment taxes now show the correct label in the Taxes column of PDF documents instead of appearing as standard taxes. This helps users and customers read tax information accurately on generated documents.
Original PR description
Split payment taxes were not labelled correctly in the PDF's "Taxes" column, they were labelled as standard taxes. <img width="1214" height="598" alt="image" src="https://github.com/user-attachments/assets/f1ea57bd-9a7f-460f-8c81-6a89585ba6d8" /> Forward-Port-Of: odoo/odoo#226588 Forward-Port-Of: odoo/odoo#226366
The AI module now treats unsuccessful website scraping as a warning instead of an error when the issue does not block the overall process. Users are still informed when a URL cannot be scraped, while monitoring systems receive fewer false error alerts.
Original PR description
Currently, an error can occur on unsuccessful scrapping of URL.
**Error:**
`Error scraping URL https://agenciavirtualpy.com: HTTPError('403 Client Error: Forbidden for url: https://agenciavirtualpy.com/')`
- Instead of logging an error, we log only warning during unsuccessful URL
scraping because it is not a blocking point in the code.
- On unsuccessful scraping, we log warnings [1] and raise a UserError [2] to
inform the user about the failed URL scraping. Therefore, we should log a
warning as the UserError is already present.
[1]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L258
[2]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L283-L285
sentry-6634525990Fixed an issue where users could see an error when Shop Floor was set as their default landing page. The page now handles reloads more reliably, reducing login disruption for manufacturing users.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback…
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** In mrp_workcenter_dialog.js, the Shop Floor action uses the `menu` service to get the name of the current app. `setCurrentMenu()` which set the current app in the `menu` service is not called before the `appName` getter is called. https://github.com/odoo/odoo/blob/5c1234085b1c1e227846b24bde55a0392779069b/addons/web/static/src/webclient/menus/menu_service.js#L29-L36 This lead to a traceback because this.menu.getCurrentApp() is `undefined`. **FIX** Workaround if the current app is undefined. We already check what is returned by `getCurrentApp()` where it is used. opw-4926317 Forward-Port-Of: odoo/enterprise#93043
The update gives the test user the needed Sales permissions so Mexican localization tests can create sales orders successfully. This prevents false test failures and improves release reliability without changing any business behavior.
Original PR description
The tests `test_global_discount` and `test_down_payment` in `l10n_mx_edi_sale` were failing with:
AccessError: You are not allowed to create 'Sales Order' (sale.order) records.
This happened because `mx_external_setup` runs with a user that does not belong to any Sales group. Both tests explicitly create Sale Orders and advance payment wizards, which require Sales ACLs.
This change ensures the test user has the `sales_team.group_sale_salesman` group in `setUpClass`, so Sales Orders can be created normally. No business logic is modified, only test stabilization for the MX localization.
[RB-232559](https://runbot.odoo.com/odoo/error/232559)This fix prevents a secondary failure when Odoo tries to capture screenshots or screencasts after a serious error. It helps ensure the original problem is retained and easier to diagnose, improving reliability of automated testing and error investigation.
Original PR description
Cf #226267 the "error condition" on the ws socket is that it's not present at all, not that it's `None`. So when used after a fatal error (e.g. in the context of trying to take a screenshot or take a screencast) these methods *can* in some cases trigger a compound failure and lose the original error because they fail on trying to access the ws to check if it's truthy. Forward-Port-Of: odoo/odoo#227385