Daily updates from Odoo
Navigate
Branch
Friday, September 26, 2025
205 changes
6 changes
Enhancements to existing features
Bank reconciliation no longer uses a fixed matching tolerance for invoices. Instead, businesses can control the tolerance through a system setting, with existing and new databases defaulting to no tolerance unless enabled.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/9bea3f2c517e77fdb822eb53b9648e9fc5478dac introduce a tolerance. If an invoice has a bigger amount than the bank line but within the tolerance of 3%, reconcile the invoice automatically and leave the difference in the suspense account. The statement line will be partially matched. This commit will change that tolerance to use a system parameter instead. For old DB the tolerance is at 0 and for new DB a system parameter (0 by default) will be put so that people that want to use it can. task-5106655 Forward-Port-Of: odoo/enterprise#95301
Resolved issues and error corrections
The Helpdesk performance dashboard now correctly opens the SLA Success Rate view. Managers can see closed tickets from the last seven days that were resolved within SLA, making performance reporting accurate and actionable.
Original PR description
**Steps to Reproduce** - Install the Helpdesk module. - Check the My Performance section. - Click on SLA Success Rate. **Issue:** Clicking on SLA Success Rate does nothing. It should display the closed tickets from the past seven days that were resolved within the SLA. **Cause:** Missed a domain filter, so no data is returned or shown. **Fix:** - Add the correct domain filter to show closed tickets. - And also modified compute method as well, so both are aligned. The problem arises in this [commit](https://github.com/odoo/enterprise/pull/76079/files#diff-e145df8bcc8742bcac578d5b05b6fc1aeaef55d236952a2a58d61ac92ce84a67R258-R260) task-4781994 Forward-Port-Of: odoo/enterprise#85412
Italian ENASARCO taxes are now treated correctly as both withholding and pension fund contributions in electronic invoices. This ensures the required information appears in the proper XML sections and reduces reporting errors after installing the Italian localization modules.
Original PR description
* = l10n_it, l10n_it_edi, l10n_it_edi_withholding The ENASARCO tax works both as a Withholding (negative) tax and as a Pension Fund tax. It must appear in the XML in both sections DatiRitenuta and CassaPrevidenziale. - We modified the master data to amend this error. Now the correct Withholding type appears right after installing the module. - Since there was an explicit check on taxes being both, we removed it. - Removed an exception where ENASARCO taxes were allowed to have positive values Forward-Port-Of: odoo/odoo#228322 Forward-Port-Of: odoo/odoo#226357
Vendor bill imports for Chilean electronic invoices now correctly treat lines marked with exemption code 6 as negative amounts. This prevents overstated bills and improves compliance with Chilean electronic invoicing rules.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#93393
Razorpay payments now use a single authentication method instead of mixing account keys with an access token. This prevents mobile checkout failures and 403 errors for merchants who configured both connection options.
Original PR description
In a specific context, Razorpay rejects connections using both Key ID/Secret and an access token simultaneously. To reproduce, it's require a real production Razorpay account since Oauth is not available in test mode. Step to reproduce: - Configure Key ID/Secret and connect via OAuth on the Razorpay payment provider. - On iOS/Android, making a payment on the website triggers a "403 Forbidden" error because Razorpay redirect to `/payment/razorpay/return` and the signature from Razorpay not correspond to the expected signature computed with the Key Secret. This fix prioritizes call with Key ID/Secret over token authentication. if not configured. opw-5100194 opw-4989944 opw-5039880
The IoT box remote debugging dialog now always shows the generate password button. This removes an outdated restriction so users can access the password action when needed.
Original PR description
Since we recently removed the check for the requests sent to the iot box controllers the generate password button being invisible doesn't make sense anymore. This PR makes it always visible Forward-Port-Of: odoo/odoo#228602
9 changes
Enhancements to existing features
Point of Sale now avoids loading large lists of product option values until they are actually needed. This reduces startup delays for stores with complex product catalogs while keeping product options linked correctly.
Original PR description
Before this commit, when loading PoS, all product template attribute value (ptav) IDs linked to a product attribute were loaded. This caused performance issues when attributes had a large number of values, even though they were not needed at that stage. With this commit, the values are no longer preloaded, since the reverse fields in ptav and ptal are fetched when needed, ensuring they can still be linked correctly without degrading performance. opw-5006818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225600 Forward-Port-Of: odoo/odoo#224497
Restaurant point-of-sale users can now retry kitchen receipt printing when a printer issue causes a failure. The retry action only sends the receipt to printers that failed previously, avoiding duplicate prints on 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
Resolved issues and error corrections
Fixed an issue in Brazilian electronic invoicing where confirming several invoices at the same time could cause the process to fail. This helps accounting teams process batches of invoices more reliably and reduces manual retries.
Original PR description
opw-5107516 Forward-Port-Of: odoo/enterprise#95511
Fixed an issue where membership products could disappear from invoice line search after the product's purchase option was disabled. This keeps membership invoicing workflows consistent and avoids confusion when editing draft invoices.
Original PR description
**Steps to Reproduce:** 1. Create a new membership product from the Membership module. 2. Open any partner and go to the Membership page. 3. Click on Buy Membership and select the created product. 4.…
**Steps to Reproduce:**
1. Create a new membership product from the Membership module.
2. Open any partner and go to the Membership page.
3. Click on Buy Membership and select the created product.
4. Click on Invoice Membership.
5. Open the newly created draft invoice.
6. From the invoice line, open the product form (via the internal link).
7. Disable the Can be Purchased option and return to the invoice using breadcrumbs.
8. Add a new line in the invoice and search for the same product by its name.
**Observation:**
1. When Can be Purchased is enabled on the product, the product appears in the invoice line search.
2. When Can be Purchased is disabled, the product no longer appears in the search.
**Issue:**
In the product field domain defined in
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029 the `default_move_type` context is `null`.
As a result, only the condition `[('purchase_ok', '=', True)]` is applied in the `name_search` domain.
**Solution:**
Pass the proper context value in the invoice action, ensuring the domain evaluates correctly and the product remains searchable.
**Note:**
The domain used in the following field
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029
is evaluated by a following JavaScript function
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/web/static/src/core/py_js/py_interpreter.js#L483-L489
rather than on the Python backend. Because the domain logic depends on dynamic
context evaluation performed client-side, there is no straightforward way to
retrieve or test the domain arguments dynamically within the `name_search`
method on the server. As a result, it is not feasible to write automated test
cases for this specific domain filtering scenario in the backend.
opw-5028789
Forward-Port-Of: odoo/odoo#225230This fixes paid order search in the Point of Sale so staff only see orders from the current register setup or its trusted related setups. It prevents unrelated paid orders from appearing, reducing confusion and helping teams keep sales data separated correctly.
Original PR description
Before this commit, when searching paid orders in the PoS UI, orders from other configs could appear even if they were not part of the trusted configs or the same PoS config. This commit ensures that only orders related to the current PoS configuration (or its trusted configs) are loaded and displayed. opw-5083747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227709
Fixes an issue in bank reconciliation where, when several bank lines were reconciled at once, an exchange difference entry could be attached to the wrong line. This helps keep accounting records accurate for multi-line reconciliations involving currency differences.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures bank reconciliation assigns exchange difference entries to the correct selected line when multiple lines are reconciled together. It reduces the risk of accounting records being linked to the wrong transaction, improving accuracy in multi-currency reconciliation workflows.
Original PR description
When selecting multiple lines in the bank rec widget (reconcile button), it could happen that one of those lines have a exchange diff move linked to it. In this case, the exchange move id was placed on the first line all the time which could be wrong. This commit will change the use of indexes to use the reconciled line of the exchange diff move. no task id
Barcode receipt users will now see quality checks only for items they have actually picked. This prevents unnecessary or confusing checks from appearing for products with zero processed quantity, making warehouse quality control more accurate.
Original PR description
_______________________________________ ## Short functional explanation of the error On barcode, when an item isn't picked, when clicking on quality checks, the quality check for the unpicked item…
_______________________________________ ## Short functional explanation of the error On barcode, when an item isn't picked, when clicking on quality checks, the quality check for the unpicked item will still show. ## Reproduction Steps 1. Go to Quality and create a Quality point by clicking on Quality Control. Click on new, set a title and put 2 products in the field Product. In operation, select Receipt. 2. Go to Inventory and click Receipts. 3. Click New. Fill the Receive From field, and add 2 products. Set the demand field to 2 for example. 4. Click on Mark as Todo. 6. Go to Barcode. Click on Operations, the Receipts, and click on the latest Receipt you created. 7. For one product, click on the +2 button. For the other one, leave it at 0. Then, click on Quality Check. ### Expected behavior Only the quality check for the item that has been picked should show. ### Unexpected behavior Both quality checks show. ## Origin of the issue The behavior of the code is different when we perform the operations in backend compared to when we perform them in barcode. Indeed, for the regular flow in Inventory, in ```check_quality()```, we also retrieve the checks linked to a move line that hasn't been picked: https://github.com/odoo/enterprise/blob/c09a5cbc2450ec32b0ad3985fa2d4e5e2fcd3d71/quality_control/models/stock_picking.py#L44-L58 Which isn't the intended flow for barcode. Thus, we have to change this behavior and take into account the environment. __ opw-5010764
Users now see a clear “Device disconnected” message when the Belgian POS blackbox device is unplugged or loses connection. This avoids a vague unknown error and helps staff understand and resolve the issue faster.
Original PR description
When the blackbox is being disconnected the user gets "unknown blackbox error" instead of "Device disconnected" explicit message. This PR removes this vague error message introduced in https://github.com/odoo/enterprise/pull/93468 Forward-Port-Of: odoo/enterprise#95489
6 changes
Resolved issues and error corrections
Users with viewer permission can now mark documents as favorites using the keyboard shortcut without seeing an access error. This makes the Documents app shortcut behavior consistent and prevents disruption for users who rely on favorites to organize files.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326 Forward-Port-Of: odoo/enterprise#89928
This fix ensures Swedish ISO 20022 payment processing passes all needed information through the system when other add-ons extend the same process. It helps prevent customization-related issues and keeps payment file generation more reliable.
Original PR description
Pass all arguments to super-call of _get_company_PartyIdentification32-method in account_iso20022/models/account_journal_iso20022_se.py so they can be passed correctly in other modules inheriting the method. Forward-Port-Of: odoo/enterprise#93883
Orders placed through self-ordering or kiosk flows with online payment now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring paid orders reach the preparation screen even if the customer exits through the payment portal.
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
This fixes an issue where users working across multiple companies could be blocked from adding Helpdesk timesheets when the linked project had no company set. It preserves the correct company during timesheet creation, preventing validation errors and supporting smoother Helpdesk billing and migration flows.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
This fix ensures helpdesk tickets appear properly in timesheet reports when they should. It corrects a previous report update that missed the right part of the report layout, helping users see more complete ticket-related time information.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Users now see a clear “Device disconnected” message when the Belgian POS blackbox is unplugged or loses connection. This replaces a vague unknown error, helping staff understand the issue faster and reduce confusion at checkout.
Original PR description
When the blackbox is being disconnected the user gets "unknown blackbox error" instead of "Device disconnected" explicit message. This PR removes this vague error message introduced in https://github.com/odoo/enterprise/pull/93468
16 changes
New functionality added to Odoo
Adds a new Belgian Codaclean integration that lets businesses automatically retrieve CODA bank statement files into configured bank journals. This reduces manual bank statement handling by syncing twice daily or on demand through the accounting dashboard, with the secure external connection handled via Odoo IAP.
Original PR description
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server.…
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server. The IAP side does the actual calls to codaclean (with a secret API key). To use the module you have to create a connection to IAP / codaclean and set up a bank journal: - To manage the connection to IAP / codaclean go to Settings -> Accounting -> Codaclean -> Manage Connection - To set up the bank journal you need to configure the following in the "Journal Entries" tab on the journal: - Put the IBAN in the "Bank Account Number" field - Select "Codaclean Synchronization" for the "Bank Feeds" field Coda files will be automatically fetched 2 times per day via the scheduled action called "Accounting: Sync Coda Files from Codaclean". They can also be manually fetched by clicking "Fetch from Codaclean" below the journal on the accounting dashboard (only available when the journal and connection are setup correctly). On an empty journal we start fetching from 1 year ago. When the journal is not empty we start fetching after the last bank statement / bank statement line in the journal. IAP PR: https://github.com/odoo/iap-apps/pull/1181 documentationh PR: https://github.com/odoo/documentation/pull/14525 task-4844423 Forward-Port-Of: odoo/enterprise#93909
Slovenian companies can now generate the EC Sales List report in the required XML format for submission. The update also adds tax return handling for this report, helping businesses meet local compliance requirements more efficiently.
Original PR description
Add the possibility to generate the Slovenian EC Sales List Report in the appropriate XML format, and the tax return functionality on said report. Part of task-4776229
Enhancements to existing features
The Equity app now has smoother screens and form flows for ownership and beneficial owner information, along with fixes for issues found during testing. Added test coverage helps make these workflows more reliable for companies managing equity records and compliance details.
Original PR description
1. Unit tests for UBO 2. UI/UX improvements 3. Fixes for detected issues task-5078906 Forward-Port-Of: odoo/enterprise#94736
Users can now duplicate documents directly from the All and My Drive folders, removing an extra step in document management. Drag-and-drop behavior into My Drive is also clearer: shortcuts are moved, documents create shortcuts, and items already rooted in My Drive are not duplicated unnecessarily.
Original PR description
**Before this PR:** - When the ALL folder is selected, the server action to duplicate the documents is absent. - Drag and drop to my drive creates a shortcut. **After this PR:** - Now we can easily duplicate the documents, even when we are present in the ALL folder. - Drag and drop shortcuts to MY Drive will move shortcuts. - Drag and drop documents to MY Drive will create shortcuts in MY Drive. - Drag and drop documents to MY Drive from All will do nothing if docuemnt root belongs to MY Drive. Task-4717535
Restaurant preparation displays now show clear course names such as “Starter” or “Main” instead of short codes like “C1” or “C2”. This makes orders easier for kitchen staff to understand at a glance, while very long course names are shortened to keep the display readable.
Original PR description
Before this commit: ======================= - Preparation display showed sort course names. (e.g., C1, C2). After this commit: ======================= - Full course name is displayed in preparation display. (e.g., Starter, Main). - Course names that are too long will be truncated. Task - 4982871 Related PR: - Community: https://github.com/odoo/odoo/pull/224147
Bank statement matching no longer uses a fixed 3% tolerance when an invoice amount is slightly higher than the bank line. The tolerance is now controlled by a system setting, defaulting to 0%, so businesses can choose whether to allow automatic partial matching and keep differences in suspense.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/9bea3f2c517e77fdb822eb53b9648e9fc5478dac introduce a tolerance. If an invoice has a bigger amount than the bank line but within the tolerance of 3%, reconcile the invoice automatically and leave the difference in the suspense account. The statement line will be partially matched. This commit will change that tolerance to use a system parameter instead. For old DB the tolerance is at 0 and for new DB a system parameter (0 by default) will be put so that people that want to use it can. task-5106655 Forward-Port-Of: odoo/enterprise#95567 Forward-Port-Of: odoo/enterprise#95301
Payslips now hide the employee record field when it is not needed, such as when no employee is selected or only one record exists. This reduces clutter and makes payroll entry easier for users, while improving the related version search list for this context.
Original PR description
With this commit, the employee record on payslips is hidden if the employee is not selected or if the employee has only one record task-5082906
This update reorganizes how online sales pages handle customer interactions across rental, stock rental, and local invoicing flows. It should make the shopping and checkout experience easier to maintain and more reliable without changing the visible business process.
Original PR description
task-5089578 Community PR: https://github.com/odoo/odoo/pull/225568
Resolved issues and error corrections
The WhatsApp message composer now requires users to select a template before sending. This prevents an error that occurred when sending without a template and makes the process clearer for users.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the "WhatsApp" button next to the phone number. 3. Remove the template and click Send Message. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874
Brazilian service invoices with installment payments now send installment amounts without taxes, matching the requirements of the AvaTax integration. This helps prevent invoice rejection errors caused by mismatched installment and line totals.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95496 Forward-Port-Of: odoo/enterprise#85108
The Helpdesk dashboard's SLA Success Rate action now opens the expected list of recently closed tickets resolved within the SLA. This helps support teams trust their performance metrics and quickly review successful SLA outcomes.
Original PR description
**Steps to Reproduce** - Install the Helpdesk module. - Check the My Performance section. - Click on SLA Success Rate. **Issue:** Clicking on SLA Success Rate does nothing. It should display the closed tickets from the past seven days that were resolved within the SLA. **Cause:** Missed a domain filter, so no data is returned or shown. **Fix:** - Add the correct domain filter to show closed tickets. - And also modified compute method as well, so both are aligned. The problem arises in this [commit](https://github.com/odoo/enterprise/pull/76079/files#diff-e145df8bcc8742bcac578d5b05b6fc1aeaef55d236952a2a58d61ac92ce84a67R258-R260) task-4781994 Forward-Port-Of: odoo/enterprise#85412
This update removes outdated test setup declarations that are no longer needed for Knowledge, Stock Barcode, and Manufacturing Work Orders. It helps prevent automated validation errors and keeps internal quality checks aligned with the current shared testing framework, with no expected change for end users.
Original PR description
runbot-error-232620 Forward-Port-Of: odoo/enterprise#95516
Scanning a product in the Barcode app now opens the same kanban-style view used by other barcode workflows. This creates a more consistent experience for warehouse teams and avoids the unexpected switch to a list view.
Original PR description
This commit is to show the kanban view as a default when scanning a product in barcode. Before PR: All views in barcode are in kanban view except when scanning a product, it appears in list view. After PR: Now barcode also shows kanban view when scanning a product. Forward-Port-Of: odoo/enterprise#95517
The Knowledge article list now correctly recognizes when Studio customization is allowed, so users can add custom fields from the optional columns menu as expected. This prevents a misleading “not editable by Studio” message and restores the intended customization workflow.
Original PR description
Steps to reproduce ================== - Install knowledge, web_studio - Go to knowledge > Articles - Click on the optional columns dropdown - Click on "Add Custom Field" => This action is not editable by Studio Cause of the issue ================== Since https://github.com/odoo/odoo/pull/205129/commits/c18e93191c516f6e37093f068e8934cba8495891 the event ACTION_MANAGER:UI-UPDATED is triggered before the list renderer has a chance to register for it. Solution ======== We don't actually need to listen to that event to get the info we need. The action xml_id was missing, but it was added in the view subenv config. opw-5066488 Forward-Port-Of: odoo/enterprise#95495 Forward-Port-Of: odoo/enterprise#94794
SEPA direct debit email templates now use the recipient partner's language. This ensures customers receive payment-related messages in the language expected on their account, reducing confusion and support follow-up.
Original PR description
Before this commit the mail sent were not translated in the language of the partner. task-5010120
Barcode transfers now keep lot-tracked kit components separate from the same component added independently. This prevents valid scanned quantities from being misread and avoids unnecessary backorders during warehouse transfers.
Original PR description
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating **Steps to reproduce:** - create two products tracked by lot (comp A and comp B) - set an on hand quantity for both - create a storable product (final product) and create a BOM - in the BOM add comp A and comp B - create an internal transfer for 1 final product and 1 comp B - click on "mark as todo" - open this transfer in barcode, we see that the two lines from the comp B are grouped - scan the source location, click on +1 and +2 button to fulfill the quantities and validate **Current behavior:** a backorder is created **Expected behavior:** no backorder should be created as we entered the right quantities of the picking **Cause of the issue:** the lines from comp B should not have been grouped in the barcode picking. When doing the same scenario but with product not tracked those lines are not grouped opw-4998766 Forward-Port-Of: odoo/enterprise#95497 Forward-Port-Of: odoo/enterprise#93262
18 changes
New functionality added to Odoo
Adds a new Belgian Codaclean integration that lets companies fetch CODA bank files into bank journals through Odoo's IAP service. Businesses can automate imports twice daily or trigger them manually, reducing manual bank statement handling and keeping accounting data more up to date.
Original PR description
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server.…
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server. The IAP side does the actual calls to codaclean (with a secret API key). To use the module you have to create a connection to IAP / codaclean and set up a bank journal: - To manage the connection to IAP / codaclean go to Settings -> Accounting -> Codaclean -> Manage Connection - To set up the bank journal you need to configure the following in the "Journal Entries" tab on the journal: - Put the IBAN in the "Bank Account Number" field - Select "Codaclean Synchronization" for the "Bank Feeds" field Coda files will be automatically fetched 2 times per day via the scheduled action called "Accounting: Sync Coda Files from Codaclean". They can also be manually fetched by clicking "Fetch from Codaclean" below the journal on the accounting dashboard (only available when the journal and connection are setup correctly). On an empty journal we start fetching from 1 year ago. When the journal is not empty we start fetching after the last bank statement / bank statement line in the journal. IAP PR: https://github.com/odoo/iap-apps/pull/1181 documentationh PR: https://github.com/odoo/documentation/pull/14525 task-4844423
Enhancements to existing features
The Equity app receives improvements to beneficial ownership workflows, portal forms, valuation and cap table displays, and related communications. These changes make it easier for users to complete equity ownership requests accurately while addressing issues found during testing.
Original PR description
1. Unit tests for UBO 2. UI/UX improvements 3. Fixes for detected issues task-5078906
The default user group name has been changed back after feedback from use. This keeps terminology familiar for users and reduces confusion in access or role descriptions.
Original PR description
After using it, fp changed his mind.
Resolved issues and error corrections
This fixes an error that could appear after validating a reception and opening the move details when no package was assigned. Users can now view completed stock move details normally, even when package tracking is enabled but unused for that move.
Original PR description
Steps to reproduce: - Inventory -> Settings -> Enable Packages - Create a reception - Add a Product, put some quantity - Validate the reception - Open the move's details Issue: A traceback is generated, as now we're in a 'done' context and the widget should only display the closest package for each move line. But it didn't check whether there was a package assigned to the move line in the first place. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where barcode transfers could incorrectly group a separately moved lot-tracked component with the same component from a kit. This prevents unnecessary backorders when warehouse staff have scanned and processed the correct quantities.
Original PR description
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating **Steps to reproduce:** - create two products tracked by lot (comp A and comp B) - set an on hand quantity for both - create a storable product (final product) and create a BOM - in the BOM add comp A and comp B - create an internal transfer for 1 final product and 1 comp B - click on "mark as todo" - open this transfer in barcode, we see that the two lines from the comp B are grouped - scan the source location, click on +1 and +2 button to fulfill the quantities and validate **Current behavior:** a backorder is created **Expected behavior:** no backorder should be created as we entered the right quantities of the picking **Cause of the issue:** the lines from comp B should not have been grouped in the barcode picking. When doing the same scenario but with product not tracked those lines are not grouped opw-4998766 Forward-Port-Of: odoo/enterprise#94085 Forward-Port-Of: odoo/enterprise#93262
Monthly demand in the vendor product catalog now includes confirmed sales that use two-step or three-step delivery routes. This helps purchasers see more accurate demand earlier, reducing the risk of underestimating what needs to be bought.
Original PR description
Issue before this commit: ========================= When confirming a sale quotation in a 1-step delivery route, the product's monthly demand in the vendor’s product catalog in purchase RFQs was…
Issue before this commit: ========================= When confirming a sale quotation in a 1-step delivery route, the product's monthly demand in the vendor’s product catalog in purchase RFQs was updated correctly for the scheduled sale order. However, in 2-step or 3-step delivery routes, confirming a sale quotation did not correctly update monthly demand for the scheduled sale order. Users may see lower than actual monthly demand in the product catalog, potentially causing confusion when planning purchases in multi-step delivery flows. Steps to Reproduce: ========================= -Install `Sales`, `Inventory`, and `Purchase` modules, and enable `multi-step routes` in configuration. -Set the Outgoing Shipments in the warehouse to 2-step/3-step. -Create a product and assign a vendor in the Purchase tab. -Create a sale quotation for the product and Confirm it. -Go to Purchase → Create RFQ for the vendor and open the Catalog `Observation`: Monthly demand of product is not updated for the confirmed sale -Go to the Sale Order, open the delivery, and validate the intermediate transfer `Observation`: The monthly demand is now correctly calculated for the confirmed sale order. Cause of the issue: ========================= -In this [PR](https://github.com/odoo/odoo/pull/215363), the `move domain` was updated to include reserved moves (not only done moves) in monthly demand calculations. However, the method `_get_monthly_demand_moves_location_domain` only returns moves where `location_dest_usage` is `customer` or `production`. -In 2-step or 3-step delivery routes, the final transfer move is only created after the intermediate transfer moves are validated. These intermediate transfer moves have `location_dest_usage` = `internal` and are therefore excluded from the domain. -As a result, the product’s monthly demand is not fully reflected for confirmed sale quotations in multi-step delivery flows. With This Commit: ========================= -The method `_get_monthly_demand_moves_location_domain` is extended to also return moves whose `location_final_id.usage = customer` and `move_dest_ids = False` -`location_final_id.usage = customer` ensures that only moves that eventually reach the customer location are counted as monthly demand, -`move_dest_ids = False` ensures moves without subsequent transfers are counted. Without this, intermediate internal transfer moves would also be counted once the final move is created, which would incorrectly inflate the demand. -These conditions ensure that intermediate moves in multi-step deliveries are correctly included in monthly demand calculations, while avoiding duplication once subsequent transfers exist.
This fix ensures that when in-store pickup is the default delivery option, the shown pickup location is actually saved during checkout. Customers no longer see a location selected on screen only to be blocked later by an error saying no pickup location was specified.
Original PR description
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user…
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values. This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case. [This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it. Refactored the test cases to avoid the redundancy in the setup process. Steps to reproduce on runbot: 1. Set the pick up in store as the default delivery method by updating the sequence 2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here 3. Go to the cart and click checkout 4. The default pickup location will be set here 5. Click on Confirm 6. An error will appear saying the location was not set opw-4954187 [This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228345 Forward-Port-Of: odoo/odoo#227826
This fix removes unnecessary test dependencies and duplicate test helper declarations in Knowledge, Manufacturing Work Orders, and Barcode. It helps keep automated checks stable without changing day-to-day user workflows.
Original PR description
runbot-error-232620
Public holidays now create timesheet entries using each employee's flexible working schedule instead of the company default. This prevents employees on shorter flexible days from being credited with too many time-off hours, improving payroll and timesheet accuracy.
Original PR description
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible…
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule ## Cause: When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()` This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end) These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed: https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393 We want to use the calendar itself as the calendar resource to get the `work_hours_data` ## Steps to reproduce: - On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week - Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6) - In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values) - Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off opw-4881758 Forward-Port-Of: odoo/odoo#228315 Forward-Port-Of: odoo/odoo#225876
Scanning a product in the Barcode app now opens the same kanban-style view used elsewhere in barcode workflows. This removes an inconsistent list view and makes the product scanning experience more predictable for warehouse users.
Original PR description
This commit is to show the kanban view as a default when scanning a product in barcode. Before PR: All views in barcode are in kanban view except when scanning a product, it appears in list view. After PR: Now barcode also shows kanban view when scanning a product.
This fix makes automated tour tests load their required resources consistently and avoids a conflicting test library being included in sale timesheet assets. It improves test reliability across different installation setups without changing day-to-day business features.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an accounting issue that could cause Odoo to crash when creating analytic items linked to invoices with a zero total. This helps users record and manage zero-value invoice entries without interruption.
Original PR description
The system will crash with error when try to create a analytic item. **Steps to Produce:-** 1. Install the `Accounting` module with demo data. 2. Go to `Settings > enable Analytic Accounting`. 3.…
The system will crash with error when try to create a analytic item. **Steps to Produce:-** 1. Install the `Accounting` module with demo data. 2. Go to `Settings > enable Analytic Accounting`. 3. Navigate to `Accounting > Customers > Invoices`. 4. Create a new invoice with total amount = 0 and confirm it. 5. Go to Accounting > Accounting > Transactions > Analytic Items. 6. Create a new Analytic Item and: - Set a value in the `Project` field. - Under the `Accounting` section, select the `Journal Item` linked to the last created 0-amount invoice and save. **Error:-** `ZeroDivisionError: float division by zero` **Cause:-** - At [1], when `line.balance` is 0.0 (for example, when a journal item is defined with a total of 0.0), the system raises an error. **Solution:-** - Added a condition to compute only when line.balance exists; otherwise,set the value to 100. [1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/account/models/account_move_line.py#L3248-L3251 **sentry-6844926153** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226148 Forward-Port-Of: odoo/odoo#225068
This fix prevents certain existing translations from being deleted during upgrades when they were not explicitly marked as translated. Businesses upgrading Odoo can recover and reuse these translations instead of losing localized field text and seeing unexpected English content.
Original PR description
After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were…
After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were not marked as `state='translated'` in the DB. However, the missing translations were removed from the `_ir_translation` table during the upgrade. With this patch, we still keep the conservative behavior of only auto-translating fields marked as `state='translated'` in the DB (which is still probably wrong, because user translations should remain the same; if Odoo was displaying translated text before the upgrade and it is not after it, that's probably a bug; but that's another story...), but we no longer delete the other fields. This way, you can still mark them as translated after the upgrade and use the new tooling provided in https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc to recover those translations after the upgrade. @moduon MT-11570 cc @aj-fuentes Forward-Port-Of: odoo/odoo#228404
The Helpdesk performance dashboard now correctly opens the list of recently closed tickets that met their SLA when users click the SLA Success Rate metric. This makes the metric actionable again and helps teams review successful service performance without empty or unresponsive results.
Original PR description
**Steps to Reproduce** - Install the Helpdesk module. - Check the My Performance section. - Click on SLA Success Rate. **Issue:** Clicking on SLA Success Rate does nothing. It should display the closed tickets from the past seven days that were resolved within the SLA. **Cause:** Missed a domain filter, so no data is returned or shown. **Fix:** - Add the correct domain filter to show closed tickets. - And also modified compute method as well, so both are aligned. The problem arises in this [commit](https://github.com/odoo/enterprise/pull/76079/files#diff-e145df8bcc8742bcac578d5b05b6fc1aeaef55d236952a2a58d61ac92ce84a67R258-R260) task-4781994 Forward-Port-Of: odoo/enterprise#85412
This fixes an internal upgrade issue where Odoo could try to inspect dependencies for modules that are not available in the configured add-ons path. It helps upgrades proceed more reliably when some modules are missing or intentionally unavailable.
Original PR description
`Manifest.for_addon(module_name)` returns `None` if the module is unavailable in the addons path. This is a common case during upgrades. https://github.com/odoo/odoo/blob/ef15cb776ebdd409691cef03835b51fcf7e808da/odoo/modules/module.py#L280 See also: 8e496b3df0df708280c77b9a1ae15c46e922c3bc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures spreadsheet radar chart labels are shortened only when needed. Short labels now remain readable, while longer labels are neatly shortened with an ellipsis, improving chart clarity for users.
Original PR description
Before this commit: - Radar chart point labels were truncated incorrectly because Chart.js passes extra arguments (label, index, labels) to the callback. - As a result, truncateLabel received the index as maxLen and applied unnecessary truncation. After this commit: - The callback now wraps truncateLabel to pass only the label string. - This ensures long labels are truncated with ellipsis and short labels remain unchanged. Task: 5078858 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
Generic builder tests were moved from the Website area into the shared HTML Builder area and updated to use common testing tools. This keeps checks better organized and reduces duplicated test effort, helping teams validate builder changes faster without affecting customer-facing behavior.
Original PR description
Forward-Port-Of: odoo/odoo#224522
Documentation and clarification updates
Fomasoft has been added as a contributor covered by Odoo's Contributor License Agreement. This is an administrative/legal update that helps ensure contributions can be accepted under the project's licensing rules.
Original PR description
Added new member Fomasoft --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
38 changes
Security fixes and vulnerability patches
Publicly shared MP4 files in Documents will no longer show a preview option to visitors using an anonymous link. This prevents hosted videos from being streamed through public document previews and better protects shared content access expectations.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384
Enhancements to existing features
This change makes it easier for other Odoo modules to customize how analytic distribution information is prepared for accounting entries. It supports more flexible business-specific rules, such as basing analytic distributions on employee-related data, without changing core accounting behavior.
Original PR description
**Description of the issue/feature this PR addresses:** Add an inherit point to let others modules specify others/new values when the analytic distribution is build on the analytic distribution model. **Functional example:** If you wan to determine your analytic distribution on the employee (so the `employee_id` field is added into `account.analytic.distribution.model`), the specific module can not edit the dict (who is extracted by this PR). So I propose to extract the `dict` creation into a dedicated method. **Current behavior before PR:** It's not possible to edit the `dict` **Desired behavior after PR is merged:** Update the `dict` (and let it as a `frozendict` to use it as a key). ✅ I don't find any duplicates PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Discuss calls can now automatically fall back to a server-assisted connection when direct peer-to-peer connections do not work. This improves call reliability for users on restrictive networks or in situations where direct connections are unstable.
Original PR description
This commit makes it so that in the case of unsuccessful peer-to-peer connections, the client will request to the Odoo server to upgrade the channel with a SFU. backport of: odoo/odoo#200122 and odoo/odoo#206411
The self-ordering interface has been simplified by removing visual clutter from the desktop QR code button and moving mobile QR code access into the menu. Settings are also clearer, with a renamed Settings action and a new option for free metal or wood stand references.
Original PR description
In this commit: ------------------- - Removed the QR code icon from the desktop view of the `Get QR Code` button. - Moved the QR code button from the navbar into the burger menu for mobile view. - Added a new reference option `Free Metal / Wood Stands` in settings. - Renamed the `Edit` menu item to `Settings`, to make the button functionality clear from the label as it leads the user to the settings page for the selected config. task:5003448
Resolved issues and error corrections
This fixes an issue in the HTML editor where valid content such as links or images could be incorrectly removed or cause errors when inserted into preformatted text areas. It helps preserve user-entered formatting and prevents editing disruptions in affected content blocks.
Original PR description
In this previous [task], insertion in `pre` elements was filtered to prevent non-phrasing content from being inserted (as it is invalid per the html specification). Invalid elements were targeted using the wrong condition, resulting in an issue where any `ELEMENT_NODE` phrasing content inserted through `DomPlugin:insert` (such as links, images) caused an error if empty and was unwrapped if not. [task]: https://github.com/odoo/odoo/commit/216e9ebf02e8350b82ec676586d8bcaa2a446615 task-4984152
Point of Sale users can now type a name when creating or editing a customer in the customer popup. This fixes a regression that made the name field read-only in some PoS environments, blocking quick customer creation at checkout.
Original PR description
Before this commit, the partner name field in the PoS partner popup was rendered as a non-editable div when the field_partner_autocomplete widget was missing in the PoS JS environment. This caused users to be unable to type a name for new customers. The original workaround registered a DefaultField for field_partner_autocomplete, which suppressed the missing widget warning but broke editability. opw-5111958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores a missing database index used by inventory rules to avoid confusing upgrade messages. It helps keep upgrades cleaner and preserves expected performance for company-related stock rule lookups.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
This fixes an issue where earlier manufacturing operations could show the wrong status after a backorder was completed. Businesses will see more accurate work order progress, reducing confusion for production teams tracking remaining manufacturing work.
Original PR description
In this bug, in backorder created for later work opertions, the `state` of initial operation is changed to `progress` after, the backorder is `done`. To produce the bug: 1- Create a Bill of Materials with at least two operations at two work centers 2- Create a manufacturing order and confirm it. 3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity 4- In the second work order, the first operation initially appears as `Cancelled`. Once the second operation is completed, it will change to `In progress`. opw-4931653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents product packaging entries from being duplicated when a new product has attributes but only one resulting variant. It keeps product setup cleaner and avoids incorrect duplicate packaging records after saving.
Original PR description
**PROBLEM** When creating a new product, with attributes but only one variant the packaging is duplicated on save. **STEP TO REPRODUCE** 1. Install inventory, go to the settings and enable the product packagings option. 2. Create a new product, with one attribute with one possible value, and with a packaging. 3. save the product and notice the packaging was duplicated. **CAUSE** `packaging_ids` is stored on the product.product model (product variant). `packaging_ids` in the product.template model is a compute field with an inverse. When creating the product, the inverse function is called a first time, creating a first packaging. Later in the product creation, it is called a second time because of a write call on the product.template model, creating a second packaging. **FIX** In the create() and write() of product template, set some value in the context to know if we should create the packaging or not when calling the inverse function. opw-5050592
This change restores the ability to create new customers directly from Point of Sale by bringing back the required customer name field. It prevents checkout and customer registration disruptions for staff using the POS customer creation flow.
Original PR description
This reverts commit 0635af99d3617511e82ebe20155296e86e87c92c. An issue appeared after the above commit. Inside the pos, when creating a new customer the name field is invisible, not allowing it to be filled. Customer creation is impossible as it is a required field. opw-5111673
New users can now load demo data in the Attendance app without hitting an access error. This makes initial setup and evaluation smoother for teams trying the module with non-administrator accounts.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module. Steps to reproduce: --- - Install ``hr_attendance`` module (without demo data) - Create NEW user >…
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.
Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``
Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.
This operation is allowed for the following groups:
- Administration/Settings
Contact your administrator to request access if necessary.
ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
<field name="name">Standard 32 hours/week (4 work days, friday free)</field>
<field name="company_id" eval="False"/>
<field name="hours_per_day">8</field>
<field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}), (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}), (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Tu...
ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n <field name="company_id" eval="False"/>\n <field name="hours_per_day">8</field>\n <field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}), (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}), (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}), (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSurvey description and end-message content now avoids an editor-only embedding method that prevented videos from appearing to respondents. This ensures shared survey pages show the intended media content reliably.
Original PR description
Embedded components do not render when the html field content is displayed outside the editor, as their mechanism relies on the editor plugin. Solution: --------- Disable embedded components for the survey messages (Description and End Message). Steps to reproduce: ------------------- * Create a new survey * Add a video as End Message or Description * Use the share link to view de survey * Video not showing Cause of the issue: ------------------- The new web_editor has a plugin system, and one option that is enabled by default is embedded_components. This option has been introduced in: https://github.com/odoo/odoo/commit/03f495c696030214c17e6479076571823513f60e According to the description: "It is forcibly set to false in HtmlMailField since embedded components can only be rendered inside Odoo." Observation : ------------ similar fix: https://github.com/odoo/odoo/commit/1446167e482745c71725563e56411948c3dd1f41 opw-5005752
New users can now load demo data in the Appraisal module without running into an error. This makes it easier for teams to try or evaluate the Appraisal feature in a fresh setup.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247This update corrects automated checks around product barcode lookup so product weight data is properly handled when available. It also fixes test permissions for product variants, helping prevent false failures and improving confidence in barcode lookup reliability.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155
This fixes an issue where extremely small manufacturing operation or work order durations could break planning. The change ensures scheduling can continue reliably instead of failing with an error when tiny duration values are encountered.
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
This fix ensures timesheet reports correctly include helpdesk ticket information where relevant. It repairs a previous update that did not properly target the report field, helping users see the expected ticket context in exported or printed reports.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Stock transfer validation now stops with a clear user error when there is nothing to process, instead of opening a backorder wizard that cannot create anything useful. This prevents confusion for warehouse users and avoids meaningless validation steps when all picked quantities are zero.
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#227995This fixes an issue where sale orders linked to projects could become blocked if a related analytic account had been deleted. Users can now update the project on affected sale orders without encountering an error, improving reliability for sales and project workflows.
Original PR description
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an…
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error. # Cause This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists. # Fix This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field. # Steps to reproduce - Install sale_project and accountant modules - Check "Analytic Accounting" in the Accounting settings - Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic") - Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order. - Delete the analytic.account "Test AC" - Go back on "Test SO", try to change the field "Project" - a Missing error is thrown --- Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore. Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Google Calendar account resets now consistently bypass event permission checks where needed. This prevents reset failures caused by validation errors, helping users reconnect or reset calendar sync without disruption.
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
This fix prevents older translation entries from being deleted during upgrades when they were not formally marked as translated. Businesses upgrading Odoo can recover and keep more existing translated content instead of seeing fields unexpectedly revert to English.
Original PR description
After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were…
After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were not marked as `state='translated'` in the DB. However, the missing translations were removed from the `_ir_translation` table during the upgrade. With this patch, we still keep the conservative behavior of only auto-translating fields marked as `state='translated'` in the DB (which is still probably wrong, because user translations should remain the same; if Odoo was displaying translated text before the upgrade and it is not after it, that's probably a bug; but that's another story...), but we no longer delete the other fields. This way, you can still mark them as translated after the upgrade and use the new tooling provided in https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc to recover those translations after the upgrade. @moduon MT-11570 cc @aj-fuentes Forward-Port-Of: odoo/odoo#228404
Fixed an issue that could block users from archiving several Helpdesk teams at once when those teams were connected to different websites. This prevents an unexpected error and keeps routine Helpdesk administration smooth for multi-website businesses.
Original PR description
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration >…
Currently, an error occurs when archiving multiple helpdesk teams linked to different websites. **Steps to reproduce:** - Install the `website_helpdesk` module. - Go to Website, Configuration > Websites and create two websites (`W1` and `W2`). - Go to Helpdesk, Configuration > Helpdesk Teams > create two teams (`T1` and `T2`). - Enable the `Website Form` (under `Help Center`), assign `W1` to `T1` and `W2` to `T2`. - Return to the list view, select both teams, and attempt to `archive` them. **Error:** `ValueError: Expected singleton: website(3, 1)` **Root Cause:** At [1], the code incorrectly uses `with_website.website_id.id`, when `multiple websites` are involved, this leads to an `error`. **Fix:** This commit prevents errors and ensures that users can archive multiple helpdesk teams linked to different websites [1]: https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/website_helpdesk/models/helpdesk.py#L102 sentry-6867906123
The Australian TPAR report now excludes customer payments when calculating Gross Paid amounts. This prevents unrelated incoming payments from inflating supplier taxable payment reporting, improving report accuracy for compliance.
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#95029
Opening the warehouse receipts view could crash when many transfers had many quality checks. This change reduces unnecessary memory use during that process, making the inventory workflow more reliable for large operations.
Original PR description
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive"…
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker. This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop. For a specific customer (opw-5025162), this was the case. ## Benchmarks: | No. stock.picking | avg no. quality checks | peak memory before | peak memory after | | ----------------- | ---------------------- | ------------------ | ----------------- | | 25 | 20 | 2771 mb | 235 mb | opw-5025162
This fixes a Point of Sale issue that prevented users from entering a customer name when creating a new customer during a POS session. Cashiers can now save new customer records without seeing the invalid name field error.
Original PR description
**Steps to reproduce:** - Install `point_of_sale` - Open a POS session - Click on customer (bottom left) -> Create new customer - Try to enter the name and save **Issue:** - Unable to set customer name - Error shown: "Invalid field: Name" **Cause:** - after commit https://github.com/odoo/odoo/commit/0635af99d3617511e82ebe20155296e86e87c92c the field_partner_autocomplete widget was set as the default for missing fields. But the name field of res.partner also uses this widget without a default value, which blocks entering a customer’s name when creating a new record. https://github.com/odoo/odoo/blob/0635af99d3617511e82ebe20155296e86e87c92c/addons/point_of_sale/static/src/app/missing_fields.js#L14 **Solution:** - Remove 'field_partner_autocomplete' widget from the missing field component, as we can't set a default value for name. opw-5113044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an invoicing error in the Mexican extended electronic invoicing flow when the USD currency has been deactivated. Businesses can now confirm and send affected CFDI invoices without being blocked by a currency lookup issue.
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
Updating a product barcode no longer clears the product's e-commerce description when no new description is available from barcode lookup. This prevents accidental loss of sales content on product pages during routine product maintenance.
Original PR description
**Steps to reproduce:** 1.Install website_sale 2.Create a new product and set an e-commerce description (under the Sales page) 3.Update the barcode (length ≥ 8) in General Information page **Issue:** - The e-commerce description is cleared after updating the barcode. **Cause:** https://github.com/odoo/enterprise/blob/c0c4f5d4b9799fb88d80a6074bb1efb0cb73ccc8/product_barcodelookup/models/product_template.py#L16-L21 - The onchange triggered by barcode updates calls _update_product_by_barcodelookup method, which overrides the product's ecommerce description field even when no barcode_lookup_data and no updated description. https://github.com/odoo/enterprise/blob/233e82cf4e6908502a580be4bcd77fadd2aada53/website_product_barcodelookup/models/product_template.py#L8-L11 **Solution:** - Added a check for update the ecommerce description Only if we receive a description. opw-4813710
Warehouse teams can now select which IoT printer is used for shipping labels instead of the system automatically picking the first compatible printer. This helps route labels to the right printer for each picking type, reducing misprints and operational confusion.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. Task: 4792491
This fix ensures that when users add a border to an image in email content, the border remains visible after the email is sent. It improves consistency between the email editor preview and what recipients actually receive.
Original PR description
Problem: When adding a border to an image and sending an email, the border is not visible in the received email. Solution: Ensure a `border-style` is set if missing, otherwise keep the existing one. Steps to reproduce: - Open email marketing. - Add an image snippet. - Add a border to the image. - Send the email. - The received image has no border. opw-5004824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223867
This fix removes an unnecessary navigation step from an automated Point of Sale test that was causing intermittent database-related failures. It helps keep validation runs stable and reduces false alarms in the development pipeline without changing user-facing behavior.
Original PR description
Before this commit: ================= The `test_draft_pos_order_linked_sale_order` test fails intermittently with a `psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the…
Before this commit:
=================
The `test_draft_pos_order_linked_sale_order` test fails intermittently with a
`psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the
browser tour navigates back to the backend.
After this commit:
=====================
The problematic navigation step is removed from the `PosSettleOrder5` tour,
stabilizing the test and preventing the runbot error.
Cause:
========
The `Chrome.clickMenuOption("Backend", { expectUnloadPage: true })` step
forces an immediate database flush (`self.cr.flush()`) during the test's
authentication phase.
This forced flush happens when the records are in an intermediate state (after
loading the Sale Order but before payment/validation). This specific
intermediate state, combined with the subsequent recomputation of computed
fields (like `qty_delivered` through `sale_mrp` and `sale_margin`), exposes an
underlying bug in Odoo's ORM cursor management, leading to the
`psycopg2.ProgrammingError`.
Since the backend navigation is not necessary for the test's assertion logic,
removing this step prevents the premature flush and resolves the failure.
Runbot Error: 226521
Task: 4974084Project users can no longer create new task stages from the task list when they do not have the required permissions. This prevents accidental or unauthorized workflow changes and keeps project stage management limited to project managers.
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#206407
Product information now displays correctly for products with variants in Point of Sale sessions. Cashiers can again see the product name, price, and inventory details, helping them answer customer questions and complete sales accurately.
Original PR description
When opening the `product information` of a product with variants in a POS session We do not see the product name, price and inventory information OPW-4544324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures email signature formatting remains intact when messages are prepared for Outlook. It prevents image sizing and other final style settings from being accidentally merged with Outlook-specific hiding rules, leading to more consistent email appearance.
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
The web test runner now classifies errors and warnings more accurately depending on when they occur. This helps development teams see important problems without unnecessarily stopping test runs, improving reliability of quality checks.
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
Barcode scanning no longer crashes when a warehouse picking includes a kit product variant with its own packaging. This helps warehouse teams process packaged kit variants reliably in the Barcode app.
Original PR description
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration.…
In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback. ### Steps to reproduce: 1. Enable packagings on inventory configuration. 2. Create a product, that as a least 2 variants. 3. Add a packaging to one of the variants. 4. Create a BoM for created product (kit type). 5. Create a picking order for the variant with packaging. 6. Print the picking operation to scan the code through barcode. 7. Go to barcode and try to scan it, this will trigger the traceback. ### Cause of the issue: Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data: https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91 _get_stock_barcode_data will obtain the packaging methode for the products. https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16 since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information. ### Fix: We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids: https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441 our fix will allow for packaging in the variant to be considered when there is more than only one variant. opw-4852875
Changing a website theme color from the color palette and saving no longer triggers an error. This improves reliability for users editing website appearance and prevents disruption during routine design updates.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146
Point of Sale users can once again print customer invoices through connected IoT printers instead of only downloading the PDF. The printer selection flow was also streamlined so the same printing process can be reused reliably in more places.
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-5109814Users now see a clear warning instead of an error when opening a product forecast in a company that has no warehouse. This prevents a confusing crash and explains why the forecast cannot be shown until a warehouse exists.
Original PR description
Step to reproduce: - install stock - create a new company and switch to that company - open a storable product - click on forecasted smart button Cause: - StockForecasted component needs at least 1 warehouse, but when we create a new company, it does not have any warehouse https://github.com/odoo/odoo/blob/7747c5810eabe798a1631c3e3b26b81a5c89b4b4/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L49-L52 - clicking on the smart button, raises traceback Fix: - we show a warning when the smart button is clicked and no warehouse is found **Note**: not adding a test case, as issue is not reproducible in test mode due to this https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 opw-5059799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request updates the Adhoc corporate contributor license agreement records by adding new members. It is an administrative legal update that helps keep contributor authorization records current and does not affect product functionality.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226715
7 changes
Resolved issues and error corrections
Rental product pages now keep showing the main product's pricing table after an optional product dialog is opened and closed. This prevents customers from seeing the wrong rental prices, reducing confusion during checkout.
Original PR description
Steps: - Install eCommerce and Rental module. - Create a product with option product with both product contains different renting pricing. - Go to product in the website. - Click on add to cart it will open dialog with optional product. - Close the dialog. Issue: - Price table has optional product's pricing instead actual product. Cause: - Updating combination always trigger pricing table update and in optional product dialog update combination last calls for optional product and thus it update pricing table to optional product pricing. Fix: - Only update pricing table if the combination of main products update. Issued PR: https://github.com/odoo/enterprise/pull/32614 opw-5012075 Forward-Port-Of: odoo/enterprise#94758
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)
Accrued expense entries for purchase orders now show the tax-exclusive amount after applying line discounts. This prevents overstated amounts when reviewing or creating accrued expenses for discounted purchases.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848
The Spanish Mod 349 tax report now correctly shows the underlying invoice lines when users audit the summary for intra-community operations. This helps accounting teams verify reported EU transaction amounts without missing supporting details.
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
Website product pages now show the correct price when a customer's tax rules change how taxes are applied. This prevents small rounding errors, such as a $10 item appearing as $10.01, improving price accuracy for shoppers.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Configure website to display prices tax-included; 2. have two 15% taxes, one price-included, one price-excluded; 3. create a $10 product that uses the price-included tax; 4. create a fiscal position that maps the included tax to excluded one; 5. assign the fiscal position to the public partner; 6. open the product's shop page as public user. Issue ----- The price gets displayed as $10.01. Cause ----- When applying the taxes to the price, small errors are introduced by rounding the base price before doing the tax calculations. Solution -------- To circumvent issues like these, commits 143ec3739196f and 6045061f818a0 added the `round` & `round_base` context values respectively. By settings these to `False`, we can prevent intermediate rounding that may introduce errors like these. opw-4945752
This fix prevents small rounding differences from building up during inventory revaluation. It helps avoid incorrect negative remaining values, improving the reliability of stock valuation and related accounting figures.
Original PR description
Before this commit, the remaining_value_unit_cost was rounded before any computation. In the case where the numer of layers with remaining value and remaining quantity increase, the rounding error introduced by that rounding quickly explodes, leading to a negative remaining_value during revaluation computation. After this commit, the remaining value is rounded at the end, after the computations and the checks. This ensures that the rounding error remains constant and does not accumulate over the execution of the method. opw-4901966
A timesheet attendance report query now correctly identifies the employee field it needs to use. This prevents database comparison errors that could block affected Odoo upgrade requests.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401