Daily updates from Odoo
Monday, September 29, 2025
249 changes
30 changes
Enhancements to existing features
Repair orders now create required quality checks much faster when many quality rules exist. This reduces long delays or timeouts in large databases, improving day-to-day repair processing performance.
Original PR description
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when…
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when processing linear the records to compute the intersection between the all points and the points that should be associated with the repair. This commit rewrites `_create_quality_checks_for_repair` to use a `search` instead if necessary, to offload the intersection search in the database. We also split the ids to not inject a large list of ids in the query. Benchmark --------- For a database that will have 500k `quality.point` that satisfies the domain of `quality.point._get_domain`, the invocation of `_create_quality_checks_for_repair` for creating a Repair takes (excluding the `create` call time): | | Before | After | |---------|------------------|-------| | Timings | Timeout (15+min) | 1 min | Reference --------- opw-4980036 Forward-Port-Of: odoo/enterprise#95631 Forward-Port-Of: odoo/enterprise#91729
Italian e-invoice imports now keep the document type from supplier bill XML without relying on whether the entry is an incoming or outgoing invoice. This reduces duplicate document type records and helps imported invoices be classified more consistently.
Original PR description
In the FatturaPA XML, the Document Type (Tipo Documento) doesn't indicate the direction of the journal entry. A `TD01` can be an `in_invoice` or `out_invoice` depending on whether the company is set to be the seller or the buyer. That's what we consider when importing invoices from the EDI. - saved the `l10n_it_document_type` from the imported bills' XML - removed the filter in the view - removed the `l10n_it_document_type` duplicates that just differed by `l10n_it_document_type.type` - updated the invoices to point to the original `l10n_it_document_type` if there were duplicates We will have to remove the field in `master` See odoo/upgrade#8484 Forward-Port-Of: odoo/odoo#228802 Forward-Port-Of: odoo/odoo#225425
Restaurant point-of-sale users can now retry kitchen receipt printing when a printer issue occurs. The retry only sends the receipt to printers that failed previously, avoiding duplicate prints from printers that already succeeded.
Original PR description
Before this commit: = - There was no option to retry printing kitchen receipts if a printer failed. After this commit: = - Users can now manually retry printing kitchen receipts that failed due to printer issues. - The `Retry` button targets only the printers that previously failed, ensuring other successful prints are not repeated. Task: 4717776 Forward-Port-Of: odoo/odoo#206432
Resolved issues and error corrections
This fix makes an automated website test wait more reliably when the test environment is running slowly. It reduces false test failures, helping keep development and release validation smoother without changing user-facing website behavior.
Original PR description
__Current behavior before commit:__ The timeout in `waitForReposition` is sometimes reached if runbot is on heavy load making the test fail. __Description of the fix:__ Remove `waitForReposition` and use `waitUntil` instead. This should wait more time if runbot is on heavy load. The timeout has been increased for security. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/232802
The barcode kanban view now only displays existing inventory quantities instead of allowing new ones to be created by mistake. This helps avoid inaccurate stock records when users scan or type product barcodes and switch to the kanban view.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
The website builder now opens the edit dialog for the specific submenu a user selected, instead of defaulting to the top-level menu. This prevents confusion and helps website editors update event or nested navigation menus more accurately.
Original PR description
With the initial [website builder refactor], when user wanted to edit sub-menu with "Edit Menu", it opened the dialog to edit the top-level menu. This commit fixes that behavior by looking up the id of the containing menu (if any) Steps to reproduce: - On `/event/<some-event>`, open website builder - Click on a link in the menu of the event (not the top menu) - Click on "Edit Menu" button in the link popover - Bug: the edit menu dialog opens for the top level menu [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Website editors can now use the "On Hover" animation option on images even after applying a shape. The option is only hidden when the chosen shape already includes its own animation, preventing conflicts while preserving more design flexibility.
Original PR description
Applying a shape to an image unintentionally disabled the "On Hover" animation option. This commit restores the option with proper checks, ensuring it remains disabled only when the applied shape includes an animation. The related code was also refactored slightly for improved readability. Steps to reproduce: 1. Enter edit mode in Website. 2. Add an image and apply a shape. 3. Notice that the "On Hover" animation option is incorrectly hidden.
Turkish Nilvera e-invoice imports now save progress after each document is processed. This reduces the chance of losing all imported documents if a timeout or error occurs during larger imports.
Original PR description
Following bcab79c0ba9b550726164d80a22b50e689a2789c we are no longer committing changes in `_l10n_tr_nilvera_get_documents` as we loop through documents. The idea behind having that commit inside the loop was to avoid having to rollback all changes if we timeout or an error occurs. This is especially important when importing the current maximum amount of documents (30). This commit restores that behavior. No Task ID. Forward-Port-Of: odoo/odoo#228616
The rating form now hides placeholder words like “by” and “on” when there is no related comment or publisher information to show. This removes confusing leftover text and makes rating records easier for users to read.
Original PR description
Steps to Reproduce: 1. Navigate to a rating record form view 2. View ratings without publisher comments 3. Notice confusing 'by on' text fragments appearing Current Behavior: - 'by on' text shows even when there's no comment or publisher information - Text fragments remain visible after comments are removed Expected Behavior: - 'by' and 'on' text should only appear when there's actual content to display - Proper conditional visibility based on comment presence Changes Made: - Added conditional visibility to rating form view text elements - Improved XML structure for better maintainability - Fixed persistent text display issues when comments are removed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225300
This fixes an automated website menu test that could fail in smaller single-app test builds because the menu did not contain enough items. The change helps keep website test results reliable without affecting end users.
Original PR description
Following this [commit], this tour would fail whenever it is run in single-app test builds. This happened because there were not enough items in the nav for the tour to function properly. Also, removed the "@odoo/hoot-dom" dependency. Build error-231699 [commit]: https://github.com/odoo/odoo/commit/7279c92fcb999f621fd9725c2339247c620ed378
This fix replaces a technical crash with a clearer, user-friendly message when users or customizations try to search unsupported non-stored many-to-many relationship fields. It helps administrators and developers understand the issue faster without exposing confusing internal errors.
Original PR description
When searching non-stored many2many fields, fail with a user-friendly message.
`self.env['account.payment'].search([('reconciled_invoice_ids', '=', 1)])` today results in an AttributeError when trying to get the SQL for the bridge table name.
task-5061329
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe event registration email template now keeps QR codes at the correct size after template edits or previews. This prevents distorted QR codes, helping attendees reliably scan their registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
This fixes a restaurant point of sale issue where newly added items could appear saved but not be fully synced before being sent to the kitchen printer or preparation display. Staff should no longer encounter the "Order Outdated" error in this workflow, reducing ordering disruptions and inconsistencies.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228680 Forward-Port-Of: odoo/odoo#227824
The Australian Taxable Payments Annual Report now calculates gross paid amounts without incorrectly including customer payments. This helps businesses report supplier taxable payments more accurately and avoid overstating TPAR figures.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
The website SEO dialog now excludes dynamic template images that users cannot edit. This prevents broken image warnings from appearing on pages such as appointments and courses, making SEO optimization guidance clearer and more useful.
Original PR description
**Issue:** In the SEO dialog, under the `Images Optimization` section, broken images are displayed due to the inclusion of non-editable dynamic template images. This issue has been observed on the appointment and course pages. **Steps to reproduce:** 1. Go to the `Appointment` page on the website. 2. Go to `Site` settings present in the header > `Optimize SEO`. 3. Notice under the `Images Optimization` section, the broken image icon. See [screencast](https://drive.google.com/file/d/1EZTF2FY1ljj6S2PLwwt42Vht1IdVC3aK/view) Exclude non-editable dynamic template images from the SEO dialog's `Images Optimization` section. Users cannot modify their `alt` attributes, so including them serves no purpose. Forward-Port-Of: odoo/odoo#227702
This fix prevents Mexican electronic invoices with external trade details from failing when the USD currency has been deactivated. Businesses can continue confirming and sending affected CFDI invoices without needing to manually reactivate USD first.
Original PR description
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI…
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI Certificate and activate Testing mode in PAC. 5. Create a new product with "UNSPSC Category". 6. Create an invoice with CFDI to the public and "Definitive" in External Trade. 7. Confirm and send the invoice. **Sample certificate:** Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link Private key password: 12345678a **Error:** `ValueError - Expected singleton: res.currency()` **Cause:** When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation. **Fix:** This commit handles the case when USD currency is deactivated. sentry-6860601127 Forward-Port-Of: odoo/enterprise#94179
This fix makes call status indicators more reliable when joining or recovering a discussion call. It prevents outdated session information from incorrectly muting a user's microphone and ensures warning indicators remain visible when connection data is temporarily reset.
Original PR description
This commit fixes: - the SFU could send outdated information about our own session during the initialisation of the connection. This can lead to the microphone being muted when joining a call if the updates occur when the user rtc session is marked as mute when querying the audio stream. - the warning indicator was hidden if the connection state was undefined this could lead to a missing warning during some recovery steps when session data is reset. Forward-Port-Of: odoo/odoo#228811 Forward-Port-Of: odoo/odoo#228601
Fixed a mobile display issue where product carousel indicators could appear left-aligned when a page first loaded. This keeps storefront product carousels looking polished and correctly aligned for shoppers on smaller screens.
Original PR description
Since the introduction of interactions with [22e777c] in 18.2, the indicators on the CarouselProduct interaction were wrongly computed on mobile: on page load, the indicators appeared on the left instead of centered. This is because an explicit `updateContent()` has to be done at the end of the `updateJustifyContent` method, since it modifies a parameter that impacts the `dynamicContent`. We also take the opportunity to simplify the code of `updateJustifyContent`, which became needlessly complicated after [22e777c]. [22e777c]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba task-5080057 Forward-Port-Of: odoo/odoo#226632
This update fixes invoice printing for Point of Sale setups that use IoT-connected printers. When an invoice printer is configured, invoices are now sent to the printer instead of only being downloaded, helping cashier workflows continue as expected.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95616
Forward-Port-Of: odoo/enterprise#95586Sign requests opened from a record's chatter now show their related documents in the download menu. This prevents users from seeing an empty download dropdown and ensures they can access the correct signed documents regardless of how they open the request.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign request from 'request signature' activity. - From the chatter of the related record, open the sign request. - It will redirect to form view of that sign request. - click on download dropdown button. Before: - The download dropdown was empty. - This happened because the 'sign_request_documents_dropdown' widget tried to use 'active_id' from the context, but 'active_id' was missing when the sign request was opened from chatter. After: - The download dropdown correctly shows the related documents. - When active_id is not in the context, the widget now uses the sign request id from evalcontext, so it can fetch the right documents. Impact: - Users will always see the correct documents in the download dropdown, even when opening a sign request from chatter. task-5089829
Printed invoices now show the correct early-payment amount when both an early payment discount and cash rounding are applied. This prevents customers from seeing a slightly incorrect amount due on invoice documents.
Original PR description
**Steps to reproduce** - Create a tax of 8.1% - Activate and create a cash rounding with rounding precision 0.05 - Use the existing '2/7 Net 30' payment term (or create a new 2% early discount one) - Create a new invoice: - Add payment terms - Add cash rounding method - Add line with price 50, 8.1% tax - Invoice total will be 54.05 **Issue** Print the invoice: The invoice will show "$ 52.97 due if paid before 09/12/2025" However 52.97 is the amount with just the 2% early payment discount applied With cash rounding applied, it should display 52.95 This occurs because when retrieving the amount from the invoice template the system applies only the early payment discount opw-4914545 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4914545) Forward-Port-Of: odoo/odoo#228677 Forward-Port-Of: odoo/odoo#225759
This fix prevents Google Calendar account reset actions from failing because of event permission checks. It helps ensure users can reset their calendar connection smoothly without unexpected validation errors.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918 Forward-Port-Of: odoo/odoo#228520
Self-service and kiosk orders paid online will now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders reach the preparation screen even when customers leave through the payment portal.
Original PR description
pos_*= pos_online_payment, pos_online_payment_self_order, pos_self_order Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Enterprise PR: https://github.com/odoo/enterprise/pull/95312 Backport of https://github.com/odoo/odoo/pull/213493, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228687 Forward-Port-Of: odoo/odoo#228189
Orders placed through self-service or kiosk online payment now wait for payment confirmation before appearing on the preparation display. This prevents staff from preparing unpaid orders while still ensuring confirmed orders are sent correctly, including when customers leave via the payment portal exit flow.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal Forward-Port-Of: odoo/enterprise#95583 Forward-Port-Of: odoo/enterprise#95312
Creating a related monetary field in Studio now also creates a linked currency field, so the monetary value remains usable and consistent. This prevents business data entry and reporting issues caused by amounts without a proper currency reference.
Original PR description
Before this commit, when creating a related field to a monetary, the created currency field was not stored and not related either, so the monetary was unusable. This was because of 5cf5a35a0a8f78655989009d0eddcf39f8430965 , b177b058be1531c3d2af2b591c22591c19240d33 and in general the changes in read_group that largely improve the situation. After this commit, we create a currency field related to the currency field of the related monetary to ensure that the monetary's value is coherent. This is made possible by the above mentionned improvements in read_group opw-5094619
Scanning a loyalty card barcode in Point of Sale now correctly selects the customer linked to that card instead of showing an invalid code error. This helps cashiers apply loyalty benefits smoothly and reduces checkout friction.
Original PR description
When scanning the barcode of a loyalty card, there was an error saying the code is invalid. Instead it should select the partner linked to the card if there is one. Steps to reproduce: ------------------- * Create a loyalty program, and a loyalty card with a partner * Copy the barcode of the loyalty card * Open the POS, and scan the barcode of the loyalty card > Observation: The error "Invalid code" appears, and the partner is not selected opw-4653983 Forward-Port-Of: odoo/odoo#215894 Forward-Port-Of: odoo/odoo#213831
Inventory transfers with no valid quantities will now show a clear error instead of opening a backorder step that cannot do anything. This prevents confusing warehouse workflows and helps users correct the transfer before validating it.
Original PR description
### Steps to reproduce: - Create and confirm a delivery with 2 moves: - 1 x product 1 - 1 x product 2 - Set the quantity of product 2 to 0 and mark it as picked - Validate the transfer #### > The…
### Steps to reproduce:
- Create and confirm a delivery with 2 moves:
- 1 x product 1
- 1 x product 2
- Set the quantity of product 2 to 0 and mark it as picked
- Validate the transfer
#### > The backorder wizard open's even though there is nothing to validate. Creating a backorder does nothing.
#### Cause of the issue:
Since there is a picked move, the picking validation does not pick every moves in the `pre_action_done` hook keeping only moves with empty qty as picked:
https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_picking.py#L1208-L1209 Then, only the picked moves are processed in there `_action_done`: https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1914 https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1929-L1937 Which leads to an empty picking validation.
opw-5076640
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227995The analytic distribution account selector now only shows accounts for the document's company. This prevents users in multi-company setups from viewing or selecting accounts that belong to another company, supporting proper data separation and compliance with company rules.
Original PR description
**Description of the issue/feature this PR addresses:** When creating or editing an analytic distribution, the analytic account selection does not respect the company context. This allows users to…
**Description of the issue/feature this PR addresses:** When creating or editing an analytic distribution, the analytic account selection does not respect the company context. This allows users to see and select analytic accounts from other companies, which violates the multi-company record rules. <img width="669" height="333" alt="2025-09-08_09-28" src="https://github.com/user-attachments/assets/488eb4b1-fdfa-49ca-a57e-8f46a264107d" /> **Current behavior before PR:** The analytic account dropdown in the analytic distribution widget shows analytic accounts from all companies, instead of being restricted to the current company. **Desired behavior after PR is merged:** The analytic account selection in the analytic distribution widget is filtered by company. Only analytic accounts belonging to the document company will be displayed, ensuring compliance with multi-company record rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228268 Forward-Port-Of: odoo/odoo#225835
Spanish Mod 349 tax report audits now show the relevant transaction details for the intra-community operations summary line. This helps accounting users verify reported EU invoice amounts instead of seeing an empty audit result.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
A failing automated test for PayPal button rendering was removed because it depended on real PayPal credentials that cannot be safely used in the test environment. This keeps automated validation stable while the affected PayPal button scenario is handled through manual testing.
Original PR description
## Versions 18.4 ## Issue An error is raised after PayPal SDK call for button rendering in a test introduced by 1b8f26611a1a349a92075720cb95cb17b00c2b21. ## Cause PayPal SDK cannot render a button with dummy credentials. ## Fix As the button requires real (production or sandbox) credentials we cannot safely provide in runbot environment, we accept a manual testing for this specific use case. runbot-232965
19 changes
Enhancements to existing features
Repair creation is now faster when many quality rules are present. The change moves heavy matching work to the database and avoids oversized queries, reducing long delays or timeouts for large quality setups.
Original PR description
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when…
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when processing linear the records to compute the intersection between the all points and the points that should be associated with the repair. This commit rewrites `_create_quality_checks_for_repair` to use a `search` instead if necessary, to offload the intersection search in the database. We also split the ids to not inject a large list of ids in the query. Benchmark --------- For a database that will have 500k `quality.point` that satisfies the domain of `quality.point._get_domain`, the invocation of `_create_quality_checks_for_repair` for creating a Repair takes (excluding the `create` call time): | | Before | After | |---------|------------------|-------| | Timings | Timeout (15+min) | 1 min | Reference --------- opw-4980036 Forward-Port-Of: odoo/enterprise#95631 Forward-Port-Of: odoo/enterprise#91729
Italian electronic invoices now keep the document type from imported XML without relying on whether the entry is a customer invoice or vendor bill. This reduces duplicate document type records and helps imported invoices be classified more accurately.
Original PR description
In the FatturaPA XML, the Document Type (Tipo Documento) doesn't indicate the direction of the journal entry. A `TD01` can be an `in_invoice` or `out_invoice` depending on whether the company is set to be the seller or the buyer. That's what we consider when importing invoices from the EDI. - saved the `l10n_it_document_type` from the imported bills' XML - removed the filter in the view - removed the `l10n_it_document_type` duplicates that just differed by `l10n_it_document_type.type` - updated the invoices to point to the original `l10n_it_document_type` if there were duplicates We will have to remove the field in `master` See odoo/upgrade#8484 Forward-Port-Of: odoo/odoo#228802 Forward-Port-Of: odoo/odoo#225425
Resolved issues and error corrections
This update fixes a problem where reinstalling the Danish Nemhandel module could leave it broken. It helps businesses using Danish electronic invoicing keep the module reliable during maintenance or reinstallation.
Original PR description
**Description of the issue/feature this PR addresses:** Reinstalling the module breaks it. 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#228747
The barcode Kanban view now only displays existing inventory quantities instead of allowing new ones to be created. This prevents accidental inventory records and helps keep stock data accurate when users scan or enter product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
The Australian TPAR report now excludes unrelated customer payments from the Gross Paid amount. This prevents overstated supplier payment reporting and helps businesses produce more accurate annual taxable payments reports.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
This fix makes Turkish Nilvera e-invoice imports save progress after each document is processed. If an import times out or encounters an error, already imported documents are kept instead of being rolled back, reducing rework and improving reliability for larger batches.
Original PR description
Following bcab79c0ba9b550726164d80a22b50e689a2789c we are no longer committing changes in `_l10n_tr_nilvera_get_documents` as we loop through documents. The idea behind having that commit inside the loop was to avoid having to rollback all changes if we timeout or an error occurs. This is especially important when importing the current maximum amount of documents (30). This commit restores that behavior. No Task ID. Forward-Port-Of: odoo/odoo#228616
The web testing tool now distinguishes between different levels of errors and warnings, so issues are reported with the right urgency. This helps developers see important problems earlier while preventing expected or lower-priority test issues from disrupting test runs unnecessarily.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228674
Resetting a submitted tax return now correctly removes the previously generated tax journal entry and related attachments. This prevents old and new entries from being counted together when the return is submitted again, reducing the risk of incorrect tax amounts.
Original PR description
- Create a journal entry for a period. - In Tax return, submit the tax return for the period. - Reset the tax return (bypassing the lock date): the tax journal entry generated by the tax return is not deleted. - Resubmit the tax return: both the old and the new journal entries are taken into account for the tax return value. Commit https://github.com/odoo/enterprise/commit/123ae45cbc966f6a2c03050899058aff175f92dd (in account_return.py) mistakenly removed the line unlinking the closing move and attachments at reset. We reintroduce them here. opw-4972892
Event registration confirmation emails now keep QR codes at the correct size and proportions after the template is edited or previewed. This prevents stretched QR codes, helping attendees reliably scan their tickets or registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
Mexican electronic invoices with external trade details can now be sent even if the USD currency has been deactivated. This prevents a blocking error during invoice confirmation and helps businesses complete CFDI invoicing without needing to reactivate an unused currency.
Original PR description
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI…
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI Certificate and activate Testing mode in PAC. 5. Create a new product with "UNSPSC Category". 6. Create an invoice with CFDI to the public and "Definitive" in External Trade. 7. Confirm and send the invoice. **Sample certificate:** Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link Private key password: 12345678a **Error:** `ValueError - Expected singleton: res.currency()` **Cause:** When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation. **Fix:** This commit handles the case when USD currency is deactivated. sentry-6860601127 Forward-Port-Of: odoo/enterprise#94179
Carbon emissions calculations now use the emission factor's unit of measure when converting quantities. This prevents inaccurate emissions values in ESG reporting, improving confidence in sustainability metrics.
Original PR description
Prior to this commit, the UoM conversion in the carbon emissions calculation was done by targeting the UoM of the account move line instead of the UoM of the emission factor. Which led to incorrect emissions values calculations. task-5107685
Users who work across multiple companies can now assign themselves to planning slots in a company where they have an employee record, even if another company is currently active. This prevents silent failures and makes planning assignments work as expected in multi-company setups.
Original PR description
_______________________________________ ## Short functional explanation of the error Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding…
_______________________________________ ## Short functional explanation of the error Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens. ## Reproduction Steps 1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2. 2. Select both companies. In planning, create a slot for company_2 and publish it. 3. Log in as the user you created. Make sure that the current company is company_1. Select company_2. 4. Go to planning and try to assign yourself to the slot you've just created as an admin ### Expected behavior Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected). ### Unexpected behavior Nothing happens ## Origin of the issue When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee, self.env.user.employee_id is set at False _________________________________________ opw-4963674 ---
The employee form now shows the full count of documents stored in an employee’s folder and all related subfolders, while excluding folders themselves from the total. This gives HR users a more accurate view of available employee documents at a glance.
Original PR description
Before this commit, the documents count on the employee form view showed only the count of documents (folders included) inside the employee folder but not the ones in subfolders. This commit fix that by showing the count of every documents (folders excluded) included in the employee folder or its subfolders. Task-4944895
This fix prevents users from appearing muted unexpectedly when joining a Discuss call and ensures warning indicators remain visible during connection recovery. It improves call reliability and helps users better understand their call status when connection data is refreshed.
Original PR description
This commit fixes: - the SFU could send outdated information about our own session during the initialisation of the connection. This can lead to the microphone being muted when joining a call if the updates occur when the user rtc session is marked as mute when querying the audio stream. - the warning indicator was hidden if the connection state was undefined this could lead to a missing warning during some recovery steps when session data is reset. Forward-Port-Of: odoo/odoo#228811 Forward-Port-Of: odoo/odoo#228601
Fixes an issue where enabling VAT number verification on a non-empty EC Sales List could create duplicate validation checks and cause an error. Businesses can now run the report with VAT verification enabled without interruption.
Original PR description
Create tax return checks for a non-empty EC Sales List report when the option "Verify VAT Numbers" (vat_check_vies) is enabled implies to create 2 checks with the same code (check_partner_vies). This is forbidden and raises a traceback. opw-5079474 opw-5090602 opw-5094853 opw-5103611
This fixes a display issue where product carousel indicators could appear left-aligned on mobile when a page first loaded. The change keeps the carousel controls centered immediately, improving the shopping page experience for mobile visitors.
Original PR description
Since the introduction of interactions with [22e777c] in 18.2, the indicators on the CarouselProduct interaction were wrongly computed on mobile: on page load, the indicators appeared on the left instead of centered. This is because an explicit `updateContent()` has to be done at the end of the `updateJustifyContent` method, since it modifies a parameter that impacts the `dynamicContent`. We also take the opportunity to simplify the code of `updateJustifyContent`, which became needlessly complicated after [22e777c]. [22e777c]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba task-5080057 Forward-Port-Of: odoo/odoo#226632
Printed invoices now show the early payment discount amount after applying cash rounding. This prevents customers from seeing a slightly incorrect amount due when both early payment discounts and cash rounding are used.
Original PR description
**Steps to reproduce** - Create a tax of 8.1% - Activate and create a cash rounding with rounding precision 0.05 - Use the existing '2/7 Net 30' payment term (or create a new 2% early discount one) - Create a new invoice: - Add payment terms - Add cash rounding method - Add line with price 50, 8.1% tax - Invoice total will be 54.05 **Issue** Print the invoice: The invoice will show "$ 52.97 due if paid before 09/12/2025" However 52.97 is the amount with just the 2% early payment discount applied With cash rounding applied, it should display 52.95 This occurs because when retrieving the amount from the invoice template the system applies only the early payment discount opw-4914545 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4914545) Forward-Port-Of: odoo/odoo#228677 Forward-Port-Of: odoo/odoo#225759
Google Calendar account resets now apply the same safeguard to all related calendar event updates. This prevents reset operations from failing unexpectedly because of event permission checks, making account reconnection and cleanup more reliable for users.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918 Forward-Port-Of: odoo/odoo#228520
The Spanish Mod 349 tax report now correctly displays the underlying invoice details when users audit the summary line for intra-EU operations. This helps accounting teams verify reported amounts more easily and avoid confusion during tax report review.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
5 changes
Resolved issues and error corrections
Self-order point of sale orders will no longer be sent for preparation when the customer payment did not complete successfully. This avoids staff preparing unpaid orders and reduces operational confusion.
Original PR description
backport of : [#213493](https://github.com/odoo/enterprise/pull/87173) opw-4974253
Fixed an issue that could stop Mexican electronic invoices with external trade information from being confirmed and sent when the USD currency was deactivated. This prevents invoice processing failures for companies that do not keep USD enabled in their currency list.
Original PR description
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI…
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI Certificate and activate Testing mode in PAC. 5. Create a new product with "UNSPSC Category". 6. Create an invoice with CFDI to the public and "Definitive" in External Trade. 7. Confirm and send the invoice. **Sample certificate:** Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link Private key password: 12345678a **Error:** `ValueError - Expected singleton: res.currency()` **Cause:** When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation. **Fix:** This commit handles the case when USD currency is deactivated. sentry-6860601127 Forward-Port-Of: odoo/enterprise#94179
Internal agents who preview WhatsApp conversations without joining them can now translate messages. This removes an unnecessary limitation and helps support teams understand customer conversations more reliably.
Original PR description
Before this commit, when an agent that is not member of whatsapp but is peeking the conversation, the agent could not translate the message. This happens because the translation feature is limited to internal users, but this was determined based on the self member relational field. This works when the agent is a member but when not a member this was arbitrarily disabling the feature. This commit fixes the issue by looking at whether the user is internal or not, based on self persona independently on whether the agent is member or not of the conversation. Task-5111383
When warehouse staff split a delivery line in the barcode app, the new line now keeps the original reserved source package while assigning the scanned destination package. This prevents package information from being lost during partial deliveries, reducing picking errors and manual corrections.
Original PR description
### Before this PR: - Put a package in WH/Stock with quantity 100 - Create delivery for partial quantity for example 50 - Go to app barcode - Try to split the package into two different packages scanning another destination Package - The splitted line will be created with empty package instead of the package already reserved before ### After this PR: Scanning another destination package , the new line created splitting the old one will have the package_id Forward-Port-Of: odoo/enterprise#81170
The Spanish Mod 349 tax report audit view now correctly shows the underlying EU invoice transactions for the intracommunity operations total. This helps accounting users verify reported amounts instead of seeing an empty audit result.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
2 changes
Resolved issues and error corrections
This fix prevents upgrades and app installations from failing when warehouse manufacturing locations were missing. It ensures the needed warehouse locations are recreated before related operation types are rebuilt, helping affected databases upgrade smoothly.
Original PR description
DBs and upgrades are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or…
DBs and upgrades are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or `values["default_location_dest_id"]` are `False`. This happens when some `stock.warehouse` have null `stock.picking.type` references so the picking types have to be created, but the `stock.warehouse` fields use to compute `stock_picking_type` `default_location_dest_id` and `default_location_src_id` are null. To avoid this, we make sure the missing location of all `stock.warehouse` are created before creating the `stock.picking.type`.
The problem happens from 17.3 and later on, because the concerned fields are required only from this version.
`stock.picking.type.default_location_dest_id` [definition](https://github.com/odoo/odoo/blob/e1fb54cb3d5db9c906946fa11ff49c1ca86d3722/addons/stock/models/stock_picking.py#L37)
### To reproduce:
1. install odoo { 17.3 - ... } with stock,mrp
2. Nullify the following fields in some warehouse:
  Stock After Manufacturing Location
  Picking Before Manufacturing Location
  Stock After Manufacturing Operation Type
  Picking Before Manufacturing Operation Type
To view the fields:
  Developper mode
  Settings > Warehouse > Multi-Step Routes: True
  Warehouse > SomeWarehouse > Technical Information
To nullify the fields:
  Rules: Archived + Operation Type contains 'Pick Components' > Delete
  Operation Types: Archived > Delete 'Pick Components' & 'Store Finished Products'
  Locations: Archived > Delete 'WH/Pre-Production' & 'WH/Post-Production'
(or `update stock_warehouse set pbm_type_id=null,pbm_loc_id=null,sam_type_id=null,sam_loc_id=null` with sql)
3. install point_of_sale
Linked pr: https://github.com/odoo/upgrade/pull/8360
Related traceback group: https://upgrade.odoo.com/odoo/tbg/877/upgrade.request/3051298/tbg/877/3051298/upgrade.request/3051298/tbg/877
```
vval_3051298> select id,pbm_type_id,pbm_loc_id,sam_type_id,sam_loc_id from stock_warehouse order by id
+----+-------------+------------+-------------+------------+
| id | pbm_type_id | pbm_loc_id | sam_type_id | sam_loc_id |
|----+-------------+------------+-------------+------------|
| 1 | 36 | 64 | 37 | 65 |
| 2 | 39 | 66 | 40 | 67 |
| 4 | 42 | 68 | 43 | 69 |
| 5 | 45 | 70 | 46 | 71 |
| 6 | <null> | <null> | <null> | <null> |
+----+-------------+------------+-------------+------------+
```
[upg-3051298](https://upgrade.odoo.com/odoo/upgrade.request/3051298)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a setup issue where installing Point of Sale could fail if warehouse location records were missing or incomplete. The change ensures those missing warehouse locations are created first, helping affected databases install or upgrade reliably.
Original PR description
DBs are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or…
DBs are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or `values["default_location_dest_id"]` are `False`. This happens when some `stock.warehouse` have null `stock.picking.type` references so the picking types have to be created, but the `stock.warehouse` fields use to compute `stock_picking_type` `default_location_dest_id` and `default_location_src_id` are null. To avoid this, we make sure the missing location of all `stock.warehouse` are created before creating the `stock.picking.type`.
The problem happens from 17.3 and later on, because the concerned fields are required from this version.
`stock.picking.type.default_location_dest_id` [definition](https://github.com/odoo/odoo/blob/e1fb54cb3d5db9c906946fa11ff49c1ca86d3722/addons/stock/models/stock_picking.py#L37)
### To reproduce:
1. install odoo { 17.3 - ... } with stock,mrp
2. nullify the following fields in some warehouse:
 Stock After Manufacturing Location
 Picking Before Manufacturing Location
 Stock After Manufacturing Operation Type
 Picking Before Manufacturing Operation Type
To check the fields:
 Developper mode
 Settings > Warehouse > Multi-Step Routes: True
 Warehouse > SomeWarehouse > Technical Information
To make them null:
 Rules: Archived + Operation Type contains 'Pick Components' > Delete
 Operation Types: Archived > Delete 'Pick Components' & 'Store Finished Products'
 Locations: Archived > Delete 'WH/Pre-Production' & 'WH/Post-Production'
(or `update stock_warehouse set pbm_type_id=null,pbm_loc_id=null,sam_type_id=null,sam_loc_id=null` with SQL)
3. install point_of_sale
Linked pr: https://github.com/odoo/upgrade/pull/8360
Linked tbg: [tbg](https://upgrade.odoo.com/odoo/tbg/877/upgrade.request/3051298/tbg/877/3051298/upgrade.request/3051298/tbg/877)
```
vval_3051298> select id,pbm_type_id,pbm_loc_id,sam_type_id,sam_loc_id from stock_warehouse order by id
+----+-------------+------------+-------------+------------+
| id | pbm_type_id | pbm_loc_id | sam_type_id | sam_loc_id |
|----+-------------+------------+-------------+------------|
| 1 | 36 | 64 | 37 | 65 |
| 2 | 39 | 66 | 40 | 67 |
| 4 | 42 | 68 | 43 | 69 |
| 5 | 45 | 70 | 46 | 71 |
| 6 | <null> | <null> | <null> | <null> |
+----+-------------+------------+-------------+------------+
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr33 changes
Enhancements to existing features
The point of sale closing process has been reorganized so order cancellation is handled in a separate, reusable step. This does not change the cashier experience, but it makes future customizations easier for businesses with specialized closing workflows.
Original PR description
In this commit: =============== - Extract the order cancellation logic during session closing into a new method `cancelOrders`. - This makes it possible to override the method in other modules if needed. Task: 4966693 Related Enterprise PR: https://github.com/odoo/enterprise/pull/95074
Employee-related version records now automatically track changes to most business-relevant fields across HR, payroll, contracts, attendance, sign, and localization modules. This improves auditability by making it easier to see what employee data changed, when it changed, and supporting stronger compliance records.
Original PR description
Most fields in hr.version represent business-relevant employee data that should be tracked to ensure a complete audit trail. This commit adds `tracking=True` by default on hr.version fields across community and enterprise modules. task-5022109 Forward-Port-Of: odoo/enterprise#92601
New tables added on the restaurant floor screen now receive a number after the highest existing table number instead of reusing gaps from deleted tables. This makes table numbering more predictable for staff and avoids confusion when tables have been removed.
Original PR description
Before this commit: ------------- - When adding a new table in the floor screen, the system reused missing number. - For example, if table 2 was deleted, the next added table would again be number 2. - Logic: find the minimum missing number starting from 1. After this commit: -------------------- - A new table in the floor screen always gets the next number after the biggest existing one. - For example, with tables [1, 3, 4], the next table becomes 5 (not 2). Task-5056800
Employee history records now track changes to more business-relevant fields by default. This strengthens audit trails for employee information across HR, attendance, and work entry areas, making it easier to review what changed and when.
Original PR description
Most fields in hr.version represent business-relevant employee data that should be tracked to ensure a complete audit trail. This commit adds `tracking=True` by default on hr.version fields across community and enterprise modules. task-5022109 Forward-Port-Of: odoo/odoo#223342
Payroll payslip line and worked days reports have been adjusted so users can no longer edit report data directly. This helps preserve payroll data accuracy while making the reports easier to navigate and search.
Original PR description
-In payslip line report, some fields can be edited, which should not be allowed. -Views have been adjusted to prevent the navigation from pivot to list view. -Search view has been modified for easier data reaching. Forward-Port-Of: odoo/enterprise#94284
The Documents screen can now show a larger fixed list of related items in its selector, so users can see all relevant options without needing an unavailable “Search more” action. This keeps existing behavior unchanged elsewhere while improving visibility 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). Forward-Port-Of: odoo/odoo#227509 Forward-Port-Of: odoo/odoo#226608
Italian electronic invoice imports now use the document type from the XML without relying on whether the invoice is incoming or outgoing. This reduces duplicate document type records and helps bills and invoices be classified more consistently during import.
Original PR description
In the FatturaPA XML, the Document Type (Tipo Documento) doesn't indicate the direction of the journal entry. A `TD01` can be an `in_invoice` or `out_invoice` depending on whether the company is set to be the seller or the buyer. That's what we consider when importing invoices from the EDI. - saved the `l10n_it_document_type` from the imported bills' XML - removed the filter in the view - removed the `l10n_it_document_type` duplicates that just differed by `l10n_it_document_type.type` - updated the invoices to point to the original `l10n_it_document_type` if there were duplicates We will have to remove the field in `master` See odoo/upgrade#8484 Forward-Port-Of: odoo/odoo#228802 Forward-Port-Of: odoo/odoo#225425
The Documents details panel now shows the full list of available model labels instead of a shortened static list. This makes it easier for users to see their options immediately without guessing whether more choices exist.
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 Forward-Port-Of: odoo/enterprise#94934 Forward-Port-Of: odoo/enterprise#94180
Resolved issues and error corrections
The Mexican DIOT report export now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion when businesses submit or review the downloaded TXT file, while the underlying calculated amounts remain unchanged.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
Project users can no longer create new task stages from the task list when they do not have the right permissions. This keeps project workflows controlled by project managers and prevents accidental or unauthorized changes to task stages.
Original PR description
Steps to reproduce: - Go to a project - Open the task list view - Select a task - In the `Stage` field, attempt to create a new stage Issue: - Project users were able to create new task stages from…
Steps to reproduce: - Go to a project - Open the task list view - Select a task - In the `Stage` field, attempt to create a new stage Issue: - Project users were able to create new task stages from the task list view, despite not having the required permissions. Cause: - The `_default_user_id` method assigns the current user as the owner `user_id` of a new stage only when `default_project_id` is not present in the context. As a result, the method returned the current user’s ID, unintentionally making them the owner of the stage. This allowed project users to bypass the intended access rules and create new stages. Solution: - Use the `no_create` option for users outside the project manager group to prevent them from creating new stages. - Updated the `stage_id` field in the task list view to explicitly include `default_project_id` in the context, ensuring proper access control of that stage. task-4628666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228907 Forward-Port-Of: odoo/odoo#206407
Fixes an issue where website tab image descriptions could disappear when a slide title was formatted as a paragraph or placed inside another text style. This ensures editors can use the “Active only” description setting without losing visible content on the page.
Original PR description
After the new options for s_tabs_images were added in [1], it wouldn't display the active description if the title was inside of another tag. Steps to see the issue: - Open website and start editing - Drop the s_tabs_images snippet and click on the first slide title - Change the Descriptions option from "All items" to "Active only" - Select the title and change the font style from "Normal" to "Paragraph" => Observe that the description isn't displayed [1]: https://github.com/odoo/odoo/commit/e2e26bb8ad239fe13c504f0f811eab9cae1fb376
Accounting imports now avoid linking invoice lines to unrelated products when the imported product name is very short, such as “-” or “a”. This helps prevent incorrect product assignments on documents created from XML or EDI imports, improving data accuracy for accounting teams.
Original PR description
hen resolving a product in _retrieve_product, the code searched by barcode, default_code, and then by name using both exact and ilike domains. For very short item names coming from imports (e.g., “-”, “A-1”, “0001”), the ilike fallback could match unrelated products whose names merely contain that short string. this led to incorrect product linkage on created documents (e.g., EDI-imported invoices). discussed with: Christophe (chkl) Steps to reproudce: Accounting -> Invoices upload an XML with a product name liek `-` or `a` See the product attched to the invoice line. opw-5003482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225143
Importing certain electronic invoice files could fail when a base quantity was explicitly set to zero. This fix prevents that error so affected customer invoices can be imported successfully instead of being blocked.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
This fixes an issue where email signature image styling could be damaged when preparing messages for Outlook. Signatures and formatted email content should now appear more consistently for recipients, especially when resized images are used.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
Payment terminal messages printed at the bottom of POS receipts now use the correct font sizing. This makes the printed text larger and more consistent with what staff see on screen, improving receipt readability for customers and cashiers.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
Customers renting products online will again see stock availability warnings during checkout. This helps prevent confusion and reduces the chance of orders being placed when rental stock may not be available.
Original PR description
Introduced by 151349aeaf899a3b70534a0120a5f49882981d53, the `_set_shop_warning_stock` method was modified and is now supposed to return the applied warning.
The Time Off calendar now shows the selected employee's working schedule instead of the schedule of the person viewing it. This helps managers and HR staff accurately review availability and days off when checking another employee's time off.
Original PR description
Steps to reproduce: - In the Employee app, select an employee with a different working schedule than yours - Click on the "Time Off" smartbutton - Switch from Kanban to Calendar view - The displayed working schedule is yours and not the employee's (easier to see if you and the employee have different days off) Reason: The employee_id field in the context used by the Python method was null instead of an ID, which caused the Python method to default to not use the employee's working schedule but the working schedule of the user viewing it. How it was fixed: By using a different field already present in the context, the employee's ID is correctly retrieved and used to display the calendar. Task ID: 4987732 Forward-Port-Of: odoo/odoo#225839
Shiprocket Cash on Delivery shipments now include coupon discounts in the discount amount sent to Shiprocket. This helps ensure COD shipment values match the customer’s discounted order total, including taxes where relevant.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357
Forward-Port-Of: odoo/enterprise#95435
Forward-Port-Of: odoo/enterprise#92310Fixed an issue in Brazilian electronic invoicing that could cause an error when users confirmed several invoices at the same time. This makes bulk invoice processing more reliable and helps avoid interruptions during invoicing workflows.
Original PR description
opw-5107516 Forward-Port-Of: odoo/enterprise#95532 Forward-Port-Of: odoo/enterprise#95511
Preparation ticket printing now handles order notes saved in different formats, so tickets print reliably across multiple kitchen printers. This prevents a failure where the second printer could stop with an error when an order note was included.
Original PR description
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers. Steps to reproduce:…
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers.
Steps to reproduce:
-------------------
* Configure two preparation printers for a pos_restaurant with food categorie.
* Create an order with a note in that restaurant.
* Send the order to the kitchen.
> Observation:
The second printer fails to print the ticket with an (uncaught) JSON parse error (Unexpected token), while the first prints correctly.
Why the fix:
------------
`getStrNotes()` assumed notes were always JSON strings like [{"text":"...","colorIndex":0}]. In practice, notes can be plain strings or already-parsed arrays depending on the update path and last printed changes.
The function now:
- returns joined texts for arrays,
- tries to parse JSON strings and joins texts if it’s an array,
- falls back to the raw string if parsing fails. This makes note rendering stable across printers and prevents the error, ensuring tickets are printed consistently.
opw-5029870
Forward-Port-Of: odoo/odoo#227430Invoice Analysis now calculates product quantity, average price, margin, and inventory value correctly when invoice lines use product packaging. This prevents misleading sales and profitability reporting after the unit-of-measure packaging changes.
Original PR description
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost,…
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost, and it differs from sales price - In the sales sheet, add a packaging - Create a sale order - Add the product using the package - Confirm - Go to delivery, validate - Back to sale order create an invoice and confirm it - Go to "Invoice Analysis" - Go to Pivot View - In "Measures" select: - Average Price, - Inventory Value, - Margin, - Product Quantity - In "Total" select: - Product #### Current behavior: - Those fields display wrong values as they were miscalculated: - Average Price line_balance / number_of_packages * number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages / number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages / number_of_unit_in_package - Product Quantity number_of_packages / number_of_unit_in_package #### Expected behavior: - These fields should be right: - Average Price line_balance / number_of_packages / number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages * number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages * number_of_unit_in_package - Product Quantity number_of_packages * number_of_unit_in_package #### Cause of the issue: - As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas. opw-5031495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227489
The barcode kanban view now only displays existing inventory quantity records instead of allowing new ones to be created from that screen. This prevents accidental stock record creation and keeps inventory data cleaner when users scan or enter product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
This fix prevents hidden editor markers in Knowledge comments from multiplying and causing errors while editing. It improves reliability when users navigate or interact with comments in Knowledge articles, reducing the risk of unexpected crashes.
Original PR description
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment…
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment boundary. I.e.: at the first beacon, we want a cursor position before the anchor (outside of the comment), and one after (inside of the comment). Issue: Since this [commit], empty links receive 2 `zwnbsp` nodes to allow the user to type inside, instead of 1 previously. However knowledge comments beacons are not editable and only need one `zwnbsp`, since we never want to type inside. Furthermore, having 2 and nothing in between them would cause an issue when their content is normalized, which may lead to a traceback: - `link_plugin` executes `selection.anchorNode.parentNode.normalize();` which merges 2 FEFF together. However the function `isZwnbsp` does return true for one text node with 2 FEFF characters. This means that during the next "add feffs" phase, new text nodes with one `FEFF` characters will be added, creating a growing loop generating new `FEFF` at every normalization phase. - Furthermore, merging the nodes in one text node may not result in a new step in some cases, which prevent the `history_plugin` from registering the new node in time in its `nodeMap`, which may lead to a serialization traceback. Resolution: This commit stops using the deprecated `padLinkWithZwnbsp` method to ensure that there are 3 `zwnbsp` characters for each beacon: 2 around it, and one inside. [commit]: https://github.com/odoo/odoo/commit/f0eaeb6 task-5046068 Forward-Port-Of: odoo/enterprise#95550
This fix makes coupon and global discount lines identifiable on sales orders so they are handled correctly by related processes such as Shiprocket cash-on-delivery shipments. It also prevents discount line values from being reset when quantities change, helping ensure order totals and external shipment requests reflect the real discounted amount.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian company up (with valid address and some dummy mail & phone) - Create a customer "IN Cust" (with valid address and some dummy mail & phone) - Create a product "IN Prod" - Sale price: 1000 INR - Weight: 100g - Set some reference, eg "INPROD" - Create a Shiprocket delivery method - Payment Method: COD - Set some "Shiprocket Channel" - Enable Debug requests - In settings, enable "Promotions, Loyalty & Gift Card" - Go to Sales > Products > Discount & Loyalty - Create a new program - Name: 50% off - Program Type: Coupons - Change the existing reward to 50% discount on order - Generate some coupon - Copy the code to the generated coupon - Create a SO our product and customer - Use the coupon code & apply the 50% discount - Add shipping - Shiprocket COD - Get rate - Confirm the SO - Go to the picking & validate it - Open logs (Settings/Technical/Database Structure/Logging) - Open the "shiprocket_request_external/shipments/create/forward-shipment" log --> total_discount is 0 Cause ----- The problem comes from https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301 There are 2 issues here. The first and most important one is how we find the discount lines. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320 Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this. The second issue is that we use the untaxed discount amount. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321 This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price). ----- Enterprise PR: https://github.com/odoo/enterprise/pull/92310 Ticket: opw-4755357 Forward-Port-Of: odoo/odoo#228375 Forward-Port-Of: odoo/odoo#223517
Point of Sale receipts for delivery orders no longer show the customer's name and address twice. This keeps printed receipts cleaner and avoids confusion for staff and customers.
Original PR description
Steps to reproduce: - Open the restaurant configuration. - Select the preset as Delivery and choose a customer with an address. - Validate the order and print the receipt. Issue: - The customer’s name and address appear twice on the receipt. Fix: - Removed the duplicate name and address from the receipt header. task-5097764
This fixes an issue in Sales Commission reporting so grouped report results can be formatted as needed instead of being blocked by a read-only setting. It helps ensure commission and achievement reports display reliable grouped information for business review.
Original PR description
runbot-89585061
This fixes an issue where online shoppers could receive the wrong pricelist after signing in or creating an account without an address. Website sales now keep using the shopper's GeoIP country when recalculating pricing, helping ensure country-specific pricing rules are applied correctly.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198 Forward-Port-Of: odoo/odoo#228909 Forward-Port-Of: odoo/odoo#225582
Rating records now hide placeholder words like “by” and “on” when there is no publisher comment or related information to show. This removes confusing leftover text and makes rating screens clearer for users reviewing feedback.
Original PR description
Steps to Reproduce: 1. Navigate to a rating record form view 2. View ratings without publisher comments 3. Notice confusing 'by on' text fragments appearing Current Behavior: - 'by on' text shows even when there's no comment or publisher information - Text fragments remain visible after comments are removed Expected Behavior: - 'by' and 'on' text should only appear when there's actual content to display - Proper conditional visibility based on comment presence Changes Made: - Added conditional visibility to rating form view text elements - Improved XML structure for better maintainability - Fixed persistent text display issues when comments are removed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225300
Manufacturing planning now handles extremely small operation or work order durations safely. This prevents scheduling failures that could block production planning when durations are entered below the expected minimum precision.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228760 Forward-Port-Of: odoo/odoo#227253
The ESG Database menu no longer offers a direct create option, reducing the chance that users expect unsupported automatic data imports. Users can still create database entries from within emission factors when they need to manually classify emission factors.
Original PR description
Before this commit, when the user goes to Database menu inside ESG app, the user can create a database if he wants. However, when he creates a database, he might think it can add the link of the database to automatically fetch the data, but this system is not implemented because each database has its own formatting. This commit disables the create action inside that menu to avoid confusing the user. However, he can still create a database inside a emission factor if he wants to classify his emission factors manually created. task-5117594
Event registration confirmation emails now keep QR codes at the correct height when templates are previewed or edited. This prevents distorted QR codes, helping attendees reliably scan their event tickets.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
This fixes a restaurant Point of Sale issue where added items could fail to sync before being sent to the kitchen printer or preparation display. It helps prevent outdated order errors and keeps table orders consistent between the register and server.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228680 Forward-Port-Of: odoo/odoo#227824
Australian Taxable Payments Annual Reports now exclude unrelated customer payments from the Gross Paid amount. This keeps reported supplier payment totals accurate and helps avoid overstating taxable payments.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
4 changes
Enhancements to existing features
The update aligns enterprise localization tests with a recent change that adds delivery party information to UBL electronic documents. This helps ensure electronic invoice and related document checks remain reliable for affected localizations, especially Peru.
Original PR description
The community commit introduced the `<cac:DeliveryParty>` element under `<cac:Delivery>` in UBL XML. This enterprise commit improves test coverage for the element and updates existing UBL tests that were failing due to the additional tag. ---- Community PR: odoo/odoo#223756 task-5022404
Resolved issues and error corrections
This fix ensures missing warehouse locations are created before point of sale setup triggers related stock operations. It helps prevent installation or upgrade failures for databases with incomplete warehouse configuration, improving reliability during upgrades.
Original PR description
DBs and upgrades are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or…
DBs and upgrades are failing [here](https://github.com/odoo/odoo/blob/9ace6d7da6ae826ccace15fc21a262463c3e3886/addons/stock/models/stock_warehouse.py#L387) when `values["default_location_src_id"]` or `values["default_location_dest_id"]` are `False`. This happens when some `stock.warehouse` have null `stock.picking.type` references so the picking types have to be created, but the `stock.warehouse` fields use to compute `stock_picking_type` `default_location_dest_id` and `default_location_src_id` are null. To avoid this, we make sure the missing location of all `stock.warehouse` are created before creating the `stock.picking.type`.
The problem happens from 17.3 and later on, because the concerned fields are required only from this version.
`stock.picking.type.default_location_dest_id` [definition](https://github.com/odoo/odoo/blob/e1fb54cb3d5db9c906946fa11ff49c1ca86d3722/addons/stock/models/stock_picking.py#L37)
### To reproduce:
1. install odoo { 17.3 - ... } with stock,mrp
2. Nullify the following fields in some warehouse:
  Stock After Manufacturing Location
  Picking Before Manufacturing Location
  Stock After Manufacturing Operation Type
  Picking Before Manufacturing Operation Type
To view the fields:
  Developper mode
  Settings > Warehouse > Multi-Step Routes: True
  Warehouse > SomeWarehouse > Technical Information
To nullify the fields:
  Rules: Archived + Operation Type contains 'Pick Components' > Delete
  Operation Types: Archived > Delete 'Pick Components' & 'Store Finished Products'
  Locations: Archived > Delete 'WH/Pre-Production' & 'WH/Post-Production'
(or `update stock_warehouse set pbm_type_id=null,pbm_loc_id=null,sam_type_id=null,sam_loc_id=null` with sql)
3. install point_of_sale
Linked pr: https://github.com/odoo/upgrade/pull/8360
Related traceback group: https://upgrade.odoo.com/odoo/tbg/877/upgrade.request/3051298/tbg/877/3051298/upgrade.request/3051298/tbg/877
```
vval_3051298> select id,pbm_type_id,pbm_loc_id,sam_type_id,sam_loc_id from stock_warehouse order by id
+----+-------------+------------+-------------+------------+
| id | pbm_type_id | pbm_loc_id | sam_type_id | sam_loc_id |
|----+-------------+------------+-------------+------------|
| 1 | 36 | 64 | 37 | 65 |
| 2 | 39 | 66 | 40 | 67 |
| 4 | 42 | 68 | 43 | 69 |
| 5 | 45 | 70 | 46 | 71 |
| 6 | <null> | <null> | <null> | <null> |
+----+-------------+------------+-------------+------------+
```
[upg-3051298](https://upgrade.odoo.com/odoo/upgrade.request/3051298)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCorrected the Italian e-invoicing XML so linked invoice dates use the official field name required by the tax authority validator. This prevents affected invoices with customer references from being rejected due to an invalid date element.
Original PR description
The name for the date in DatiFattureCollegate (56e08bb091d39a18ea1c8e7699321b953a8823e1) is wrong. It is not DataDocumento but Data as per https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiFattureCollegate/Data/18
How to reproduce the issue:
- With l10n_it, create an invoice and fill the customer reference field.
- Generate the xml and validate through https://fex-app.com/servizi/verifica
- The following error related to the date happens: E-invoicing (Italy) La fattura elettronica è stata rifiutata dall'SdI. File non conforme al formato : Invalid content was found starting with element 'DataDocumento'. One of '{Data, NumItem, CodiceCommessaConvenzione, CodiceCUP, CodiceCIG}' is expected. riga: 80 - colonna: 24
opw-5082016
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPayment terminal messages added to Point of Sale receipts now print at a readable size. This improves receipt clarity for customers and staff while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
7 changes
Enhancements to existing features
This update restructures how product stock valuation fields are calculated so custom modules can adapt the behavior more easily. It mainly benefits implementations that need tailored inventory accounting logic without changing core code.
Original PR description
FWP of https://github.com/odoo/odoo/pull/160201 cc @pfertyk @svs-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian POS fiscal blackbox devices are now read more efficiently to avoid delays caused by repeated serial port timeouts. The update also improves device detection and buffer handling, reducing the risk that a blackbox is mistaken for another connected device.
Original PR description
This commit is a backport of some parts of odoo/enterprise#93614. The goal is to ensure that we don't read too many different times from the serial port, as each read has a timeout of 3 seconds: if 2 read fail, we exceed the longpolling's timeout. We then backport the `read_until(char)` instead of `read(n)` allowing us to read not more than once (except for the lrc, which is read only if first read is successful). We also backport the supported retry, which ensures we detect a blackbox when we plug one (prevent detecting it as an Adam Scale), and correctly flush buffers after writing/reading. Task: 5116854
Link tracking redirects now encode certain repeated dot characters that some web server setups may block as suspicious. This helps ensure tracked links continue to open reliably for users behind stricter nginx configurations.
Original PR description
Purpose ======= It has been reported that some nginx configuration detect '...' as malicious. When testing, encoding the '...' solve the issue, and so we force the encoding for the redirection URL. Task-4920533
Resolved issues and error corrections
The CRM Periodic Digest tip now shows the correct number of free credits for targeted lead generation. This avoids misleading users by stating 20 credits instead of the incorrect 200 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252
The partner ledger now keeps partner names and expand arrows properly aligned on phones and tablets. This makes the report easier to read and use on smaller screens without changing its functionality.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889
The Planning app walkthrough has been adjusted so its guided steps work properly on mobile devices. This helps users complete onboarding or training flows more reliably when using Planning from a phone or tablet.
Original PR description
In this added tour steps to work in mobile. Also made changes with some steps to better accommodate mobile tour steps task-3709542 Forward-Port-Of: odoo/enterprise#65261
This fix ensures appointment calendar events correctly include the resources selected through booking lines. It helps staff see the right rooms, equipment, or people tied to an appointment, reducing scheduling confusion.
Original PR description
PR IN PROGRESS.. opw-4565161