Daily updates from Odoo
Tuesday, September 16, 2025
40 changes · saas-18.3
Enhancements to existing features
The model selection widget can now show a configured number of visible items, allowing Documents to display its full static list of nine entries. This keeps existing behavior unchanged elsewhere while making all relevant choices visible to users in Documents.
Original PR description
In Documents, we have a static list of 9 items to show with this widget. As there is no "Search more" available, and we're in stable, this is the minimal change to not change behavior. Task-5075200 See related ENT PR (includes an integration test).
The Documents app now shows the full list of available model labels in the details panel. This makes it easier for users to see their options without guessing, especially since the list is short and cannot be searched.
Original PR description
As the list is static and there are only a few and searching for more is not supported, this enables to show all labels so that users don't have to guess what is available or not. Task-5075200
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
Users can now drag and place fields correctly when working with multiple uploaded documents in Odoo Sign. This resolves a workflow blocker that prevented preparing multi-document signature requests efficiently.
Original PR description
Version: - saas-18.3 Steps to reproduce: - install sign - upload multiple documents - try to drag the field Issue: - Fields cannot be dragged when multiple documents are uploaded. Solution: - update the condition to check if !acive then return no need to preventdefault. Impact: - Users can now upload multiple documents and drag/drop fields without issues.
The Philippine localization now assigns the 0% Exempt tax to the correct VAT fiscal position instead of conflicting categories. This helps Filipino companies avoid incorrect tax configuration and reduces accounting setup confusion.
Original PR description
### Steps to reproduce: - Install "l10n_ph" and switch to a Filipino company - Check the tax "0% Exempt", it has both "VAT Exempt" and "VAT Registered" ### Cause: The CSV was badly generated because of the fiscal position tax mapping before 18.3. ### Solution: Fix the CSV. Also delete the country for the fiscal position "VAT Exempt". This is a [recommendation from AYH on discord](https://discord.com/channels/678381219515465750/687337689988726949/1410930795329097880). opw-5044305
EU OSS taxes now receive the correct Spanish tax classification when tax mappings are refreshed. This helps businesses using Spanish localization report distance-selling taxes accurately and avoid incorrect tax categorization.
Original PR description
The EU OSS taxes were generated with the wrong l10n_es_type. - Install l10n_es and l10n_eu_oss. Then go to Settings and refresh the tax mapping in “EU Intra-community Distance Selling.” - In Taxes, filter by tax group containing “OSS.” All OSS taxes appear with l10n_es_type = sujeto. This is incorrect. The correct type should be “No Sujeto por reglas de localización” (see section 2): https://a3responde.wolterskluwer.com/es/s/article/version-3-05-del-moduloticketbai-batuz-de-a3erp-mejoras#OSS This commit adds the possibility of adding country specific field during the account_tax creation using chart_template -> fields mapping. opw-5009180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225459 Forward-Port-Of: odoo/odoo#224192
This fixes an attendance issue where changing an employee's checkout time could prevent validated overtime hours from being recalculated correctly when saved. The change avoids unnecessary overtime updates, helping managers keep attendance and overtime records accurate.
Original PR description
This fixes a weird behaviour where field that is not triggering the compute on the save because it was already triggered on the onchange If a user ser the validated_overtime_hours to a value that is…
This fixes a weird behaviour where field that is not triggering the compute on the save because it was already triggered on the onchange If a user ser the validated_overtime_hours to a value that is not the one in overtime_hours, upon changing the check_out time we will trigger the compute for both those fields. Overtime_hours calculates it's value based on attendance.overtime model, which is not being updated here, hence it will have the same value. Validate_overtime_hours in the other hand will be updated since there is a write in overtime_hours (even though with the same value) and this will mark the field to be updated when a web_save happens. Now when the save happens the overtime_hours is updated but even though validate_overtime_hours depends on it, it won't be updated since it's being writen to, as a field to be updated This fix aims to prevent writing to overtime_hours when there is no real need to, preventing the described issue opw-4806193 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222832
Spanish POS receipts will no longer print an incorrect QR code when the TicketBAI submission fails. This avoids misleading receipt information and keeps failed fiscal reporting attempts from appearing successful to customers or staff.
Original PR description
Currently if the TicketBAI upload fails, a QR code is printed with the value `true`. Steps to reproduce ----- 1. Validate a POS order 2. Have a request exception occur during the TicketBAI post 3. Receipt is printed with an incorrect QR code Issue ----- `get_l10n_es_pos_tbai_qrurl()` returns None if the edi document is not accepted. This is then interpreted as `true` by the client and a QR code is printed. Solution ----- Explicitly return an empty string if the edi document is not accepted. Forward-Port-Of: odoo/odoo#227293
Budget report entries are now limited to the companies the user can access. This prevents users from seeing budget-related entries from other companies and avoids access errors when opening report lines.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Budget Management" - Go to "Accounting / Accounting / Analytic Budget" - Create a budget - Open the budget - Create a bill (or invoice depending on the budget type) using the analytic used in the budget lines - Create a budget from another company and also a bill using the analytic used in the budget lines - Connect with a user with Accounting rights who only has access to the first company - Go to "Accounting / Reporting / Management / Budget Report" - Switch to the list view - Remove the "Open Budget" filter **Issue:** The entries linked to the budget from the other company are visible. When trying to open one of them, an access error is raised. **Solution:** Add a multi-company record rule for budget report. opw-4943360 Forward-Port-Of: odoo/enterprise#94105
This update prevents the mail system from trying to process empty or invalid entries that could cause an error. It improves reliability in mail-related workflows without changing how users interact with the system.
Original PR description
Browse breaks when given a bool, so the solution is to filter the list from false values before browsing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225916
Renamed spreadsheets now keep their chosen name when users create another spreadsheet and return using the breadcrumb. This prevents confusion from previously renamed spreadsheets appearing as untitled.
Original PR description
Steps to reproduce: - Create a spreadsheet - Rename it to "My awesome spreadsheet" - Click on File -> New - Go back to "My awesome spreadsheet" from the breadcrumb => The spreadsheet is untitled. This was caused by the fact that the name was not saved in the local state of the action. Task: 4942117 Forward-Port-Of: odoo/enterprise#93163
This fix ensures linked record fields show long text with a proper ellipsis instead of overflowing or causing alignment issues. It improves readability and layout consistency in forms such as the employee private information section.
Original PR description
The text-truncate bootstrap class of the m2o field does not work properly as the ellipsis is not visible and create an alignment issue with the private_state_id field. This PR solves this issue which can be seen in the "Private information" tab of the employee form. Task-5078736
Features or functions removed from Odoo
An obsolete automated website test for link editing was removed because it had been disabled for months and no longer matched the current system behavior. This reduces test noise and avoids confusion from a broken internal check, with no expected impact on customer-facing website features.
Original PR description
Test has been disabled in 18.0~master since March, it's even more broken in 19.0+ following #225791 (migrated to a `setSelection` with a different protocol, but the tour was not updated to the new protocol). https://runbot.odoo.com/odoo/error/116797 Forward-Port-Of: odoo/odoo#227288 Forward-Port-Of: odoo/odoo#227163
Documentation and clarification updates
The corporate contributor license agreement record for Quartile has been updated. This keeps Odoo's contribution paperwork current and supports continued compliance for accepting contributions.
Original PR description
@qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226204
This update records a Contributor License Agreement signature for tsezgin. It supports Odoo's legal compliance process for accepting contributions and has no direct impact on product features or users.
Original PR description
The commit contains my CLA signature Forward-Port-Of: odoo/odoo#226307
This update adds a contributor to Ahkio Consulting's corporate contributor license agreement record. It helps keep Odoo's legal contribution records current and ensures the contributor is properly covered for future work.
Original PR description
Description of the issue/feature this PR addresses: Add a contributor to ahkio-consulting.md --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226311