Daily updates from Odoo
Tuesday, May 5, 2026
349 changes
15 changes
Enhancements to existing features
This update adds the delivery address to the TicketScreen in Point of Sale, making it easier for staff to quickly see and use customer addresses when scheduling deliveries. This enhancement streamlines the delivery process and improves order accuracy by providing all necessary address information directly on the screen.
Original PR description
In this commit: =============== - Added address details on the TicketScreen when the order preset identification type is `address`. - This helps to easily see the delivery address while scheduling the delivery. Task-5974595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257302 Forward-Port-Of: odoo/odoo#251389
Resolved issues and error corrections
This update fixes an issue where the 'Share' button on the Dashboard was not correctly copying content to the clipboard. The problem stemmed from a change in a previous update (m3) that removed design rules. This commit manually re-added Bootstrap classes to restore the button's functionality and appearance, ensuring users can seamlessly share data.
Original PR description
Because of m3, some rules have been deleted. This commit restores them by manually adding Bootstrap classes. Steps to reproduce: - Go to the Dashboard - Click on the "Share" button 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
This update resolves a visual design problem in the Documents and Spreadsheet modules, specifically related to copy-paste functionality. The issue was caused by a previous system change (m3) that removed essential styling rules. This commit manually re-added the necessary Bootstrap classes to restore the original design and ensure proper functionality.
Original PR description
…h BS Because of m3, some rules have been deleted. This commit restores them by manually adding Bootstrap classes. Steps to reproduce: Here is a way to trigger a traceback - Open the browser console - Type: "odoo.__WOWL_DEBUG__.root.notification.add(new Set())"
This update resolves an issue where customers couldn't be found using their email addresses. The system was incorrectly searching for emails in the phone field. This change ensures accurate customer retrieval based on email, improving data accuracy and customer identification.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update fixes an issue where the Swedish EC Sales Report exported to KVR (a key reporting format) displayed values with decimal places, which is not permitted by Swedish regulations. The fix ensures that all sales report values are rounded to integers, guaranteeing accurate reporting for Swedish businesses. This improves data integrity and compliance.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#116056 Forward-Port-Of: odoo/enterprise#114292
This update resolves an issue where payroll XML files were incorrectly rejecting due to missing 'TotalPercepciones' when only 'OtrosPagos' (other payments) were present. This change ensures compliance with Mexican tax regulations (LISR) and avoids rejection by the SAT, improving payroll processing accuracy.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before setting it in the main accounting view. Now, users can directly create and edit digipoort certificates within the accounting settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update automatically sets the first available printer as the default for Point of Sale transactions. Previously, users had to manually select a printer, and this change simplifies the process. Additionally, restrictions have been added to prevent accidental changes to printer settings during quick creation, ensuring data consistency.
Original PR description
Following this commit: ===== - Set first printer as default printer from the list configured. - Updated the help tooltip. - Added placeholder "None" to field product_categories_ids. - Restrict quick create for `receipt_printer_ids` and `default_receipt_printer_id` for pos.config and res.config.settings views task-5494313 Forward-Port-Of: odoo/odoo#246448
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of null (reading 'textContent') Steps to reproduce: ==================== 1. Go to /contactus and edit the form 2. Add a Radio Buttons field and enable "Add other" 3. Add another field and set "Visible only if" to depend on the radio field => TypeError, form options panel broken Cause:
Original PR description
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of…
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with:
TypeError: Cannot read properties of null (reading 'textContent')
Steps to reproduce:
====================
1. Go to /contactus and edit the form
2. Add a Radio Buttons field and enable "Add other"
3. Add another field and set "Visible only if" to depend on the radio field
=> TypeError, form options panel broken
Cause:
=======
The "Add other" feature inserts an additional `.o_other_input` text input next to the radio inputs (the free-text input shown when "Other" is selected). When loading the available condition values, the code iterated over every `.s_website_form_input` in the dependency container and looked up `label[for="${el.id}"]`. The `.o_other_input` has no `id` and no associated label, so `querySelector(...)` returned `null` and accessing `.textContent` threw.
The crash also prevented editing any field's label on the form until the page was reloaded.
Solution:
==========
Excluding `.o_other_input` from the iteration is correct: the "Other" choice is already represented in the list by its dedicated radio (with its own label), so the free-text payload input must not be treated as a separate condition value.
An alternative would have been to narrow the selector to `.s_website_form_input.form-check-input` (the class carried by radio and checkbox inputs), which also excludes the `.o_other_input`. The chosen approach (`:not(.o_other_input)`) is more explicit about the intent: skip the "Add other" payload input, regardless of any class additions to the radio/checkbox inputs in the future.
=> Visibility dependency loads correctly, only the radio choices
("Other" included via its radio label) are listed
opw-6170367
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262046This update resolves a technical issue preventing the automated tour test from running correctly within the HR Contract Salary module. The fix addressed a missing configuration setting, ensuring the tour test now passes as expected. This ensures the tour test functionality is reliable for new users.
Original PR description
tour test is failing without employee_type task-6186664
This update resolves an issue where image options weren't consistently applying to new images within the HTML Builder. By restoring sequential execution of key handlers, the system now correctly transfers and applies all image shape and hover effect options, ensuring consistent visual results. This improves the functionality of image editing within the builder.
Original PR description
[FIX] html_builder, *: execute handler sequentially *: html_editor, website Since [1], shape and hover effect options are transferred to the new image in `on_will_save_media_dialog_handlers` within `AnimateOptionPlugin` and `ImageShapeOptionPlugin`. Because the resource was called sequentially, options were correctly applied to the new image. The problem is that since [2], the media plugin does not call `on_will_save_media_dialog_handlers` sequentially. As a result, `processImage` may run before the transfer from the old image options to the new one is complete causing some options to be missing. This commit restores sequential execution of `on_will_save_media_dialog_handlers` to ensure all options are properly applied. [1]: https://github.com/odoo/odoo/commit/137a6d7e59e1d788745c3b796a14839e52a8c5bc [2]: https://github.com/odoo/odoo/commit/b966432e85a7e19c0e4e4bfbb34f673b64fc84e6 task-6186063
This update streamlines bank reconciliation within the Odoo Enterprise system. It now automatically allows users to match statement lines from a parent company with related payments and invoices from its branches, improving the accuracy and efficiency of bank reconciliation processes. This change resolves a previous issue where matching was limited.
Original PR description
The aim of this commit is allowing in the automatic reconciliation of bank reconciliation widget the possibility to reconcile statement lines from a parent company with moves (payments and invoices) from a branch. To do that, we are not only checking that the company between the AML and the statement line is the same, we are checking that there is a parent relation between the company of the AML and the statement line. opw-6056320 Forward-Port-Of: odoo/enterprise#115267 Forward-Port-Of: odoo/enterprise#114850
This update fixes an issue where closed Helpdesk tickets were sending out emails with the incorrect ticket ID instead of the reference number. This ensures that customers receive consistent and accurate information about their resolved tickets, improving communication and transparency. The change updates a key email template to use the correct ticket reference.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#115946 Forward-Port-Of: odoo/enterprise#113932
This update fixes an issue where users connecting to multiple Shopee shops through a Shopee Account were experiencing errors due to repeated authorization code usage. Now, the system correctly reuses the initial authorization code to retrieve access tokens for all associated shops, streamlining the onboarding process for users managing multiple stores.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
This update simplifies the permissions needed to upload Unsplash images, reducing complexity and potential security risks. The change focuses on granting access only to set the attachment URL, rather than broader permissions, resulting in a cleaner and more secure system. This improves the overall stability and efficiency of the Unsplash integration.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
21 changes
Resolved issues and error corrections
This update resolves an issue where invoices generated with the l10n_sa and l10n_sa_edi modules were displaying a duplicate tax number. The change ensures that company details now print the tax number only once, improving invoice accuracy and presentation. This was related to a previous change in the Odoo codebase.
Original PR description
Before this change: - the additional_company_details would print a second tax number to invoice printout in l10n_sa After this change: - company details will print tax number only once Forward-Port-Of: odoo/odoo#261272
This update resolves a visual glitch where the user status icon on the dashboard incorrectly displayed a grey question mark instead of the correct work location. The fix standardizes the data format used for user status, ensuring the icon accurately reflects the user's location. This improves the user experience and consistency.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997
Forward-Port-Of: odoo/odoo#261977
Forward-Port-Of: odoo/odoo#258829This update corrects a bug in the invoice cancellation process for the ECPay integration. Previously, non-administrator users couldn't properly cancel invoices due to a permission issue with the staging mode setting. This change ensures all users can cancel invoices through the wizard, improving workflow efficiency.
Original PR description
Before this commit, the invoice cancellation wizard failed when clicking "Request Cancel" because l10n_tw_edi_ecpay_staging_mode lacked sudo access, while similar fields had it. The cancel wizard (l10n_tw_edi.invoice.cancel) needs to read this field to determine the API endpoint, but non-superuser accounts couldn't access it, causing a permission error. This commit adds sudo() when accessing staging_mode, consistent with other ECPay API configuration fields. Steps to reproduce: - Install l10n_tw modules with ECPay staging credentials (MerchantID: 2000132) - Use valid Tax ID (10430481) to create and send invoice - As Accounting/Administrator user, cancel the invoice - Access error occurs on button_request_cancel opw-6101478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260962
This update ensures correct processing of invoices from KSeF (a Polish tax system) by requiring vendors, even those based abroad (like Luxembourg), to use the Polish NIP number format. Previously, the system incorrectly interpreted vendor numbers, leading to import issues. This fix ensures compliance with KSeF regulations and accurate invoice processing.
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039 Forward-Port-Of: odoo/odoo#262339 Forward-Port-Of: odoo/odoo#261964
This update fixes a potential issue where errors during holiday creation wouldn't be properly handled. By wrapping the core holiday creation logic in a try/except block, the system now catches and resolves validation errors more reliably, ensuring smoother holiday setup. This improves the overall user experience and data integrity.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262175
This update ensures the product configurator dialog appears when a product has sale packaging set. Previously, users were always defaulted to the standard unit of measure. This change improves the user experience and allows customers to accurately select product options during the add-to-cart process.
Original PR description
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
This update resolves an issue where Amazon-related stock moves incorrectly displayed 'False' as their reference. The change updates the system to use the 'reference' field, which is automatically calculated, ensuring accurate tracking of these moves within the Amazon integration. This prevents reporting errors and improves the reliability of Amazon order fulfillment data.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357 Forward-Port-Of: odoo/enterprise#114345
This update simplifies the process for creating Unsplash attachments, reducing complexity and potential security risks. Previously, broad access rights were required; now, only the necessary permission to set the attachment URL is granted, improving efficiency and security.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
This update resolves a rejection issue with Mexican tax filings (NOM36) when payslips only include non-taxable payments. The change ensures the XML data sent to the SAT accurately reflects the situation, aligning with tax regulations and preventing errors.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update resolves an issue where the system incorrectly skipped remuneration declarations in certain scenarios, particularly when employees had no worked days but still received a bonus. The fix ensures that all remuneration amounts are accurately declared, addressing potential discrepancies in Belgian payroll reporting. This improves the reliability of payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#115892 Forward-Port-Of: odoo/enterprise#106689
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change ensures that the original attachment view order is maintained, preventing conflicts and restoring the expected delete functionality. This improves the usability of the attachment management feature.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907 Forward-Port-Of: odoo/enterprise#115421
This update streamlines bank reconciliation by automatically allowing users to match statement lines from a parent company with payments and invoices from its branches. Previously, the system only checked company matches; now it verifies a parent-child relationship, simplifying the reconciliation process and improving accuracy.
Original PR description
The aim of this commit is allowing in the automatic reconciliation of bank reconciliation widget the possibility to reconcile statement lines from a parent company with moves (payments and invoices) from a branch. To do that, we are not only checking that the company between the AML and the statement line is the same, we are checking that there is a parent relation between the company of the AML and the statement line. opw-6056320 Forward-Port-Of: odoo/enterprise#115267 Forward-Port-Of: odoo/enterprise#114850
This update fixes an issue where closed Helpdesk tickets were sending out emails with the incorrect ticket ID instead of the reference number. Previously, the 'Ticket Closed' email template used the database ID, leading to inconsistent information for customers. This change ensures all email communications accurately reflect the ticket reference number.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#115946 Forward-Port-Of: odoo/enterprise#113932
This update fixes an issue where partner information wasn't correctly reflected in stock journal entries when using analytic accounting. The fix ensures that the correct partner is associated with the stock movement, improving accuracy in financial reporting. This resolves a bug impacting inventory tracking and reporting.
Original PR description
**Steps to reproduce**: - Activate analytic accounting on the settings - Create an Analytic distribution models for a partner - Create a product P with a cost and Inventory Valuation set to Perpetual…
**Steps to reproduce**: - Activate analytic accounting on the settings - Create an Analytic distribution models for a partner - Create a product P with a cost and Inventory Valuation set to Perpetual - Create a location L with a Location Type set to Inventory Loss and a Loss Account - Create an internal transfer from Stock to location L for product P - Confirm it - Check the associated journal entry: -> The analytic distribution is not set of the move lines **Cause**: While validating the picking: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock/models/stock_picking.py#L1426 An account move is created without specifying `partner_id`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L178 https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L200-L205 This leads to the creation of account move lines, triggering `_inverse_analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1416-L1417 The method accesses `analytic_distribution` of the `move_line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1410 which triggers its associate compute method: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1213 To retrieve the right `analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1224 By defining this search domain: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L85 if `partner_id` is not in the `vals`, it falls back to False: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L79 As a result, the distribution linked to the `partner_id!` is not found, since the `partner_id` of the vals is determined from the `account.move.line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1237 which is False since it is not specified while creating the account move. opw-5918058 Forward-Port-Of: odoo/odoo#261713
A bug in the Odoo spreadsheet functionality was causing the user interface to freeze when a specific function was used. This update fixes an infinite loop within the spreadsheet, preventing this freezing issue and ensuring a stable user experience. This resolves a reported performance problem.
Original PR description
When using `ODOO.LIST.HEADER(1, <empty_cell_ref>)`, the spreadsheet enters an infinite evaluation loop, causing the UI to freeze. Task: 6171185 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262037 Forward-Port-Of: odoo/odoo#261724
This update corrects a technical error that prevented live chat channels with AI agents from appearing correctly to users. The fix ensures that all live chat channels, regardless of agent type, are accurately displayed. This improves the user experience and functionality of the live chat feature.
Original PR description
The number of agents linked to a livechat channel was always 0 because of a mistake in the code. This prevented livechat channels with AI agents from appearing to users. This commit fixes the problem. task-5409200 Forward-Port-Of: odoo/enterprise#111574
This update fixes an issue where users were encountering errors when authorizing multiple Shopee shops through a Shopee Account. Now, the system correctly reuses authorization tokens, streamlining the process and preventing duplicate requests. This ensures a smoother onboarding experience for users managing multiple shops.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
This update resolves an issue preventing users from deleting time off requests created after a payslip was validated. Previously, an error message blocked deletion, even though the time off wasn't impacting the payslip. This change ensures the system correctly allows deletion of unapproved time off requests following payslip validation, streamlining HR workflows.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990
Forward-Port-Of: odoo/enterprise#115765This fix addresses an issue where the employee chat button was missing from the employee form after linking a user. The button has been restored to allow employees to quickly access the Discuss channel, improving communication and efficiency.
Original PR description
Steps to reproduce: ------------------- 1. Install Employees. 2. Create a new employee record. 3. Link a user to the employee. Current behavior: ----------------- The chat (Discuss) button is no longer visible on the employee form, even when a user is linked to the employee. related commit: 7603d92 Expected behavior: ------------------ The chat button should be displayed when an employee has a linked user, allowing quick access to Discuss. opw-6158991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual alignment issue within the HR Payroll module, ensuring the review status widget is correctly positioned alongside the employee chat button. This improves the user experience and makes it easier for users to access important review information.
Original PR description
Move the review status widget inside the `employee_chat_button` wrapper, so it is displayed alongside the chat button instead of being misaligned. related community https://github.com/odoo/odoo/pull/261780 opw-6158991
This update corrects an issue where the 'GST Username' field remained visible even when GST reporting was disabled. The field has been moved back to the 'Registered Under GST' block, ensuring it only appears when GST functionality is enabled. This ensures a more consistent and logical user experience for GST reporting.
Original PR description
In https://github.com/odoo/enterprise/commit/427d9dfb89e1690d851054f7d0706648dc9bb512 commit we move the 'GST Username' field under the 'GST Reports & E-Filing' block. In this commit: - Move back the 'GST Username' field under the 'Registered Under GST' block. Reason: - Reverted this change because the visibility logic around GST fields was inconsistent. Even when “GST Reports & E-Filing” was unchecked, the “GST Username” field remained visible, which is not expected. - To restore a more logical behavior, we moved the “GST Username” field back under the “Registered Under GST” block, ensuring it only appears when GST is actually enabled. task-5248629
20 changes
Resolved issues and error corrections
This update resolves an issue that occurred when changing chart templates, specifically when switching between company and association localization settings. The fix ensures that related cash rounding records are properly removed during the template update process, preventing database errors. This improves stability and avoids disruptions during localization changes.
Original PR description
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account"…
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding" DETAIL: Key (id)=(1919) is referenced from table "account_cash_rounding" ``` **Steps to reproduce:** 1) install l10n_be module 2) make a new belgium company 3) go to accounting > configurations 4) change the fiscal localization package to "Belgium- Associations and Foundations" **Cause:** `account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'` **Solution:** Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch. opw-6165374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039 Forward-Port-Of: odoo/odoo#262339 Forward-Port-Of: odoo/odoo#261964
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_ka
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly. Steps to produce: --- - Install the `website_sale` module. - Go to Settings and enable `Prevent Sale of Zero Priced Products`. - Create a product with a sales price of `0` and publish it. - Open the product on the website. - Open the editor and change the purchase style to `Box`. Iss
Original PR description
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render…
When `Prevent Sale of Zero Priced Products` is enabled and a product with a sales price of `0` is opened on the website, switching the purchase style to `Box` causes the price text to render incorrectly. Steps to produce: --- - Install the `website_sale` module. - Go to Settings and enable `Prevent Sale of Zero Priced Products`. - Create a product with a sales price of `0` and publish it. - Open the product on the website. - Open the editor and change the purchase style to `Box`. Issue: --- - The price text renders incorrectly inside the box. Root Cause: --- - At [1], the `<span>` element responsible for rendering the price text does not check whether zero-price sale prevention is enabled, causing the price string to appear regardless. - At [2], after hiding the price span, the `o_wsale_cta_wrapper` element still renders an empty box because no corresponding guard exists there either. Solution: --- - Add a conditional check on the price `<span>`: apply `d-none` when zero-price sale prevention is active, so the price string is not displayed. - Also, add the same zero-price sale prevention check on `o_wsale_cta_wrapper` to avoid rendering an empty box when no price is shown. [1]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2233 [2]https://github.com/odoo/odoo/blob/71d176d462b9db743788e4889974931ae9afc94d/addons/website_sale/views/templates.xml#L2221 Before: --- <img width="1488" height="689" alt="image" src="https://github.com/user-attachments/assets/5b3a565f-5ced-4d75-b538-63abc3690e09" /> After: --- <img width="1457" height="612" alt="image" src="https://github.com/user-attachments/assets/1e04fe54-98b6-4e1c-bd26-4d56bb34b90e" /> opw-5994812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261313 Forward-Port-Of: odoo/odoo#252666
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
Original PR description
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
This update resolves an issue where Amazon order-related stock movements incorrectly showed 'False' as their reference. The code has been updated to use the `reference` field instead of `name`, ensuring accurate tracking of these movements within the Odoo system. This prevents reporting errors and improves the reliability of Amazon order fulfillment data.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357 Forward-Port-Of: odoo/enterprise#114345
This update simplifies the process for creating Unsplash attachments, reducing complexity and potential security risks. Previously, broad access rights were required, but now only the necessary permission to set the attachment URL is granted, improving efficiency and maintainability. This change ensures secure and streamlined image uploads.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
This update resolves an issue where payroll XML files for Mexican businesses were being rejected by the SAT (tax authority) due to incorrect data formatting. The fix ensures that TotalPercepciones is omitted when only OtrosPagos (other payments) are present, aligning with Mexican tax regulations and preventing rejection errors.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change prevents the module from overriding the standard attachment view, restoring the original functionality. This ensures users can consistently delete attachments through the standard interface.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907 Forward-Port-Of: odoo/enterprise#115421
This update fixes a potential issue where errors during holiday creation wouldn't be properly handled. The code was adjusted to ensure that errors related to holiday data are caught and addressed, leading to a more reliable and stable holiday management process. This improves the overall user experience.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262175
This update corrects a technical error in the l10n_ch_hr_payroll module that was causing a system error. The change replaces an outdated function (`get_param`) with a more modern approach (`get_bool`), ensuring the payroll module functions correctly within the new saas-19.1 environment.
Original PR description
ref commit: https://github.com/odoo/odoo/commit/142eab81dad3f88afa18c0db99007db2288a85df `get_param` is no longer available in saas-19.1 and above, and it was causing a traceback.
This update fixes an issue where warning messages from the IoT blackbox were incorrectly treated as errors. Now, warning messages are displayed as notifications, providing clearer visibility into the status of IoT data processing. This improves the user experience and helps identify potential issues more effectively.
Original PR description
Before this commit, all errors returned by the iot after a call to the blackbox were considered as errors. Actually, the errors are only the ones that do not start with 0 (no error) or 1 (warning). This commit changes the behaviour when handling warning. We now show a notification. task-id: 5062178 Forward-Port-Of: odoo/enterprise#109251 Forward-Port-Of: odoo/enterprise#93896
This update resolves an issue preventing non-admin internal users from accessing the website generator import feature. The fix grants read-only access to a broader group of users, ensuring a smoother import process without impacting system security. The website generator systray now functions correctly for all users.
Original PR description
Steps to reproduce: =================== 1. On a 19.1, launch a website import as admin 2. Log in as a non-admin internal user => AccessError on website_generator.request Cause: ====== The website generator systray polls `website_generator.request` on every page load: https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/website_generator/static/src/systray_items/generator_request.js#L48 Only `base.group_system` had access on the model, so any non-admin user hit an AccessError as soon as an import request existed (session_info sets show_scraper_systray=True for everyone based on the last request's notified flag). Solution: ========= Grant read-only access to `base.group_user`; writes/creates stay restricted to system so the import flow itself is unchanged. => Systray loads silently, shows status indicator opw-6092411
This update corrects a bug where analytic distribution wasn't correctly applied to journal entries generated from stock transfers. Specifically, the system now properly identifies the partner associated with the transfer, ensuring accurate tracking of costs and revenues within analytic accounting. This resolves an issue impacting reporting and financial analysis.
Original PR description
**Steps to reproduce**: - Activate analytic accounting on the settings - Create an Analytic distribution models for a partner - Create a product P with a cost and Inventory Valuation set to Perpetual…
**Steps to reproduce**: - Activate analytic accounting on the settings - Create an Analytic distribution models for a partner - Create a product P with a cost and Inventory Valuation set to Perpetual - Create a location L with a Location Type set to Inventory Loss and a Loss Account - Create an internal transfer from Stock to location L for product P - Confirm it - Check the associated journal entry: -> The analytic distribution is not set of the move lines **Cause**: While validating the picking: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock/models/stock_picking.py#L1426 An account move is created without specifying `partner_id`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L178 https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/stock_account/models/stock_move.py#L200-L205 This leads to the creation of account move lines, triggering `_inverse_analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1416-L1417 The method accesses `analytic_distribution` of the `move_line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1410 which triggers its associate compute method: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1213 To retrieve the right `analytic_distribution`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1224 By defining this search domain: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L85 if `partner_id` is not in the `vals`, it falls back to False: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/analytic/models/analytic_distribution_model.py#L79 As a result, the distribution linked to the `partner_id!` is not found, since the `partner_id` of the vals is determined from the `account.move.line`: https://github.com/odoo/odoo/blob/ae63688e869148ad62ef107bd8f35c4cdb33a190/addons/account/models/account_move_line.py#L1237 which is False since it is not specified while creating the account move. opw-5918058 Forward-Port-Of: odoo/odoo#261713
A recent update caused a spreadsheet to freeze when using a specific function, leading to a poor user experience. This fix resolves an infinite loop within the spreadsheet's code, preventing the UI from freezing and ensuring smooth operation. This improves stability and reliability for users working with spreadsheets.
Original PR description
When using `ODOO.LIST.HEADER(1, <empty_cell_ref>)`, the spreadsheet enters an infinite evaluation loop, causing the UI to freeze. Task: 6171185 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262037 Forward-Port-Of: odoo/odoo#261724
This update resolves an issue where the POS category grouping feature incorrectly displayed products marked as 'special' or excluded. The team has refined the filtering logic to ensure that only intended products are shown within each category group, improving the accuracy of the POS interface.
Original PR description
The group products by category feature in the POS was not filtering out the products marked as special and that should not be displayed. It is now the case by extracting the filtering logic and applying it to the grouped products as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257845
This update fixes a problem where tax amounts weren't accurately adjusted when invoices were grouped. Now, the system correctly calculates and applies tax differences after grouping, ensuring accurate financial reporting. Additionally, a related test case was updated to use Belgian company and tax settings, and an unnecessary context key was removed to align with recent Odoo updates.
Original PR description
[FIX] account_edi_ubl_cii: correct tax amount when grouping lines When the user group lines of a move, the tax amount is now corrected if there's a difference in the tax amount before and after grouping This commit also removes the `ungroup_lines` context key, as the flow was changed in odoo/odoo#252458 Reword the `test_import_and_group_lines_by_tax` test: use belgian company and belgian taxes task-5993555 Forward-Port-Of: odoo/odoo#259256 Forward-Port-Of: odoo/odoo#252719
This update fixes a restriction that prevented users from deleting time off requests after a payslip had been validated. Previously, the system incorrectly blocked deletion, even if the time off wasn't included in the payslip. This change ensures the system correctly handles time off requests regardless of payslip validation status.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990
Forward-Port-Of: odoo/enterprise#115765This update fixes an issue where users were encountering errors when authorizing multiple Shopee shops through a Shopee Account. Now, the system correctly reuses authorization tokens, streamlining the process and preventing duplicate requests. This ensures smoother onboarding and access for users connecting multiple shops.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
This update resolves an issue where users were encountering a 'Missing Required Fields' error when unchecking 'Registered Under GST' for Indian VAT settings. The fix ensures the GST username field is only required when the relevant VAT features are enabled, preventing the error and allowing users to correctly configure their settings.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#114423
2 changes
Resolved issues and error corrections
This update corrects a display issue where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The fix addresses a technical discrepancy in how invoice UUIDs were compared, ensuring the button only appears for the relevant invoice when a batch payment is created.
Original PR description
backport of f41900a4353ea867b08f71ed64f8702a13411bac - Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114440
This update corrects a technical issue preventing users from saving settings when the GST registration status is unregistered. The fix ensures the system correctly validates required fields based on the user's GST setup, preventing a 'Missing Required Fields' error. This improves the usability of the accounting settings for businesses operating under GST regulations.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#114423
3 changes
Resolved issues and error corrections
This update resolves a technical issue preventing invoices generated for German XRechnung compliance from being accepted by strict validator systems. The fix removes unnecessary whitespace from the XML attachments, ensuring compatibility with regulatory standards and avoiding invoice rejection.
Original PR description
### Issue: Some strict validators, such as the German XRechnung validator, reject generated documents because the `EmbeddedDocumentBinaryObject` contains leading and trailing whitespace ### Cause:…
### Issue: Some strict validators, such as the German XRechnung validator, reject generated documents because the `EmbeddedDocumentBinaryObject` contains leading and trailing whitespace ### Cause: Before 18.4, `_postprocess_invoice_ubl_xml()` used f-strings to generate the XML content With this formatting, the result of: `base64.b64encode(attachment_values['raw']).decode()` was indented together with the XML block, introducing unwanted whitespace and line breaks inside `EmbeddedDocumentBinaryObject` ### Steps to reproduce: - Install `l10n_de` and switch to the DE Company - In Settings, enable Peppol and Activate Electronic Invoicing - Create and confirm an Invoice (Customer: DE Company, any product line with tax) - Send the invoice via Peppol - Check the generated XML attachment ### Before the fix: The XML contains formatted content such as: ```xml <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf"> content </cbc:EmbeddedDocumentBinaryObject> ``` This formatting introduces leading/trailing whitespace and may be rejected by strict validators. ### After the fix: The XML is generated without extra whitespace: ```xml <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="INV_2026_00005.pdf">content</cbc:EmbeddedDocumentBinaryObject> ``` opw-6121616 Forward-Port-Of: odoo/odoo#262472
This update resolves a bug where incorrect industry data (UNSPSC) was being added to new partner tags when creating companies from invoices. The fix ensures that company data is created correctly, aligning with how partner tags are populated from standard autocomplete features. This improves data accuracy and consistency.
Original PR description
Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner…
Partner Autocomplete was updated so DnB industry data (UNSPSC) is no longer stored on Partner Tags. That behavior was applied to the name/VAT char widget, but creating a company from a Partner many2one (e.g. customer/vendor on an invoice) still used the old path: calling an IAP suggestion `iap_partner_autocomplete_add_tags` Steps to reproduce: ------------------- * Open a customer invoice (draft). * On Customer, search a company name and pick a Partner Autocomplete line to create a new company. * Save the quick-create dialog. > Observation: The new contact still had Partner Tags populated from DnB industry data (UNSPSC), unlike contacts created or enriched from the contact form autocomplete. (see video on ticket to avoid using more IAP credits) Why the fix: ------------ Align `res_partner_many2one` with `field_partner_autocomplete`: do not call `iap_partner_autocomplete_add_tags`. From task-5373200, industries from DnB must no longer be added as Partner Tags. opw-5972360 Forward-Port-Of: odoo/odoo#260078
This update corrects a technical issue in the Discuss feature that prevented proper sorting of partners based on email prefixes. The fix ensures that partners with matching email addresses are prioritized as intended, improving search functionality. This resolves a minor sorting problem.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
3 changes
Resolved issues and error corrections
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the intended functionality for EDI processing, rather than the OCR process. This ensures accurate financial data import.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116021
This update fixes an error in how VAT reimbursement moves are calculated when carrying over unclaimed tax amounts. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#115451
This update resolves an issue where error messages from the Danish tax reporting system (l10n_dk_rsu) could cause unexpected errors. The fix ensures that error messages are handled correctly, preventing system crashes and improving the reliability of tax report generation. This resolves a technical bug related to data type mismatches.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466 Forward-Port-Of: odoo/enterprise#115515
16 changes
Enhancements to existing features
This update allows administrators to modify payroll warnings and salary structures directly within Odoo, streamlining payroll management. Previously, these settings were immutable, requiring manual updates through technical channels. A new test ensures data integrity and prevents unintended changes.
Original PR description
This commit makes payroll warnings and salary structures updatable by removing the noupdate flag on them. A test is added to check that no warnings, salary structures, or salary rule categories have the noupdate flag. task-6120462
This update enhances the visual appearance of Gantt chart connections by replacing curved lines with cleaner, right-angled connectors featuring rounded corners. The changes also include real-time updates to connector positions during drag-and-drop actions, providing a more responsive and intuitive user experience. This improves the overall professionalism and usability of the Gantt chart.
Original PR description
In this commit added below changes: - Replace Bezier curves with orthogonal paths featuring rounded corners for clearer connectors. - Added dynamic connector target updates during pill drag for better UX. ## Technical details: * **Path Structure**: Changed SVG connector path from cubic Bezier curves to orthogonal routing with rounded corners - **Before**: `M 100,50 C 150,50 200,100 250,100` (curved path) - **After**: `M 100,50 L 175,50 Q 175,75 175,100 L 250,100` (orthogonal with curves at corners) task-4648686
This update automatically removes 'Request' documents when the related record (like a Lead) is deleted. Previously, these documents lingered uselessly after a record was removed, creating confusion. This change improves data cleanliness and efficiency.
Original PR description
Scheduling an "Upload Document" activity for a record (e.g., a Lead) creates a "Request" document that is linked to that record. Previously, the request document would remain after the record was deleted, leaving it meaningless without its related record. With this change, the request is automatically archived (moved to the Trash) when its related record is removed. Note that if a file has already been uploaded for the request, no further action is taken here: the fulfilled document request will be deleted if the record does not inherit from `documents.unlink.mixin` if we delete the record "owning" the attachment of the document; otherwise the document request will be moved to the Trash. Task-5259439
This update enhances the payslip account preview feature, allowing users to see a simulated account move before validation. It includes UX improvements for salary calculations and adds optional credit/debit account assignments. This provides greater transparency and control over payroll accounting.
Original PR description
This commit serves multiple purposes: - Making the "obvious" values in the salary computation tab of a payslip invisible. This means that in the list view of the rules, only values != 1 will be shown…
This commit serves multiple purposes: - Making the "obvious" values in the salary computation tab of a payslip invisible. This means that in the list view of the rules, only values != 1 will be shown in the Quantity column, values != 100 in Rate and values != Total in the Base column. - Adding credit and debit accounts on the payslip line, optional by default. - If the Anonymize flag is set on the company, adding a way to preview the account move that would be created if we validated the payslips. To do this, a new button Journal Entry (Preview) is added to the ellipses, which triggers the form view of a newly added model MockAccountMoveWizard. This is a model used to simulate the Account Move without risking the records being saved in the db and bloating everything. All of the fields of this new model are computed, so when the form view is called on a new record, the compute function is triggered and used to fill all the values we will need in the view later. The values are taken from the same function that is used when creating an actual move, which we have split to separate the value computation part and the record creation. An additional model for mock lines is also created to be able to have the One2many relation. Task: 5965802
Resolved issues and error corrections
This update ensures that 'Final Consumer' records are correctly created as individuals, not companies, within the Odoo system. The change was triggered by a recent update to how the 'is_company' field is calculated. The fix includes correcting test assertions to reflect this accurate creation process.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves a minor issue in a test related to the HR payroll module's user interface. The change ensures the test accurately reflects updates made to the CSS styling, preventing potential errors in how the toggle field is displayed. This ensures consistent and reliable functionality for users.
Original PR description
Updates the `rule_selection_exclusive_toggle_boolean` test to account for the changes made in https://github.com/odoo/odoo/pull/262543. The test now correctly anticipates the widget sharing the same CSS rules as its base widget. task-3378044
A recent update to the Odoo Enterprise system introduced a new Dutch returns module (l10n_nl_returns) without the necessary translation files. This update corrects this issue, ensuring accurate and complete translations are available for users in the Netherlands. This prevents potential errors or confusion when using the module.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update resolves a problem where payroll exports to the Mexican SAT were being rejected due to incorrect data formatting. Specifically, when a payslip only includes non-taxable payments, the system was including a 'TotalPercepciones' field that the SAT requires to be absent. This change ensures compliance with Mexican tax regulations.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update allows users to automatically reconcile bank statements from a branch with payments and invoices from the parent company. Previously, reconciliation was limited to matching companies only. This change streamlines the bank reconciliation process by recognizing parent-child relationships.
Original PR description
The aim of this commit is allowing in the automatic reconciliation of bank reconciliation widget the possibility to reconcile statement lines from a parent company with moves (payments and invoices) from a branch. To do that, we are not only checking that the company between the AML and the statement line is the same, we are checking that there is a parent relation between the company of the AML and the statement line. opw-6056320 Forward-Port-Of: odoo/enterprise#115267 Forward-Port-Of: odoo/enterprise#114850
This update ensures that EC Sales Reports generated for Swedish companies are exported to KVR in whole numbers, as required by Swedish tax regulations. Previously, the reports included decimal values, which were incorrect for reporting purposes. This fix corrects the export process to guarantee accurate data transfer.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#116056 Forward-Port-Of: odoo/enterprise#114292
This update resolves an issue that occurred when manually creating vendor bills and DIAN commercial events were rejected due to missing information. The fix ensures that the system correctly handles these rejections, preventing a traceback error and improving the reliability of the DIAN integration. This change is crucial for accurate vendor bill processing.
Original PR description
This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills. This is a tricky error as it only happens when the vendor bill is manually created and the…
This commit fixes an error when retrying a rejected DIAN commercial event on manually created Vendor Bills. This is a tricky error as it only happens when the vendor bill is manually created and the event is rejected (missing/incomplete info or servers down which is common). To add more to this, this error can only be reproduced without demo mode as it forces the acceptance, forcing the need of valid testing or production DIAN credentials How to reproduce it: - Install l10n_co_dian module - On CO company with all required DIAN configuration set - Create a vendor bill manually with enough information to send to the DIAN but causing it to be rejected. - Click on acknowledge receipt, it should be rejected - Complete information to be accepted and again click on acknowledge receipt - A traceback appear Code expects the last document to be the most current one created when triggering commercial event, but this is not true when a rejected document exists since this is unlinked and cache invalidated causing the recordset to be invalidated and retrieved again by ORM with default order, so now the last document is the oldest one without an attachment causing the traceback opw-6104541 Forward-Port-Of: odoo/enterprise#115914 Forward-Port-Of: odoo/enterprise#114758
This update resolves a technical issue preventing the IoT printer test button from functioning correctly. The fix corrects a coding error that was preventing the system from properly identifying the printer, ensuring the test print functionality now operates as intended.
Original PR description
In the refactoring in odoo/enterprise#113545, a mistake was made where the `printer.iot_device_id` was used instead of `printer.iot_device_id.id`, causing an error when calling `searchRead`. This commit fixes the issue by restoring `.id`. Forward-Port-Of: odoo/enterprise#115039
This update corrects a bug where closed Helpdesk tickets were sending out emails with the ticket's database ID instead of its reference number. Previously, the 'Ticket Closed' email template used the wrong identifier, leading to inconsistent references for customers. This change ensures all email communications accurately reflect the ticket reference.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#115946 Forward-Port-Of: odoo/enterprise#113932
This update resolves an issue where the ECO list incorrectly showed related ECOs from child BoMs. The change ensures that the ECO smart button only displays ECOs directly linked to the current BoM, improving the user experience and data accuracy for BOM management.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a BoM (id=1):
- Create an ECO → This creates an archived BoM (id=2)
- Access BoM (id=2)
- Create another ECO → This creates an archived BoM (id=3)
- Go back to the original BoM (id=1)
→ The ECO smart button count is 1 (correct)
Click on it
Problem:
It loads all ECOs linked to both the parent and child BoMs. It should only display the ECOs directly linked to the current (parent) BoM.
opw-4653598Features or functions removed from Odoo
This update removes the 'search knowledge article' button from the settings view. This simplification streamlines the user interface, making it easier for users to navigate and manage knowledge articles. This change improves overall usability and reduces potential confusion.
Original PR description
The "search knowledge article" button is no longer required in the settings view and has been removed to simplify the interface. task-6143234
This update removes a redundant color field from stage definitions within the Helpdesk, CRM, and Project modules. This change was implemented because the 'rotting widget' was used, rendering the color field unnecessary. This optimization improves system performance and reduces potential complexity.
Original PR description
We used the rotting widget in the stage field, so the stage color field is unused, as explained below in the commit. https://github.com/odoo/odoo/commit/cd9ed578803605550135cb6fd6d4c267b433abbc task-5485507
4 changes
Resolved issues and error corrections
This change resolves an issue where the calculation of product quantities for kit products in rental orders was inconsistent with non-rental orders. It standardizes the calculation by excluding kit products, ensuring accurate quantity displays in reports and sales orders. This improves the reliability of inventory management for rental products.
Original PR description
The behavior for computing _compute_qty_at_date
fields(virtual_available_at_date, scheduled_date,
forecast_expected_date, free_qty_today, qty_available_today) with kit
products differs unexpectably with rentals vs. non-rentals.
This change unifies their behavior by avoiding kit products (through
display_qty_widget) field in sale_stock_renting.
Steps to Reproduce:
1. Create 2 products, both with kit BOMs, one rental, one non-rental
2. Give components non-zero
3. Create a rental order with both products
4. Odoo Inspect / Studio add above fields to view
5. See computed difference
opw-6141580This update resolves an issue where payroll document generation incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a dependent field with a stored employee flag, ensuring accurate validation regardless of the company context. This prevents errors during payroll processing.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti)
A test related to rental stock management was failing due to demo data. The fix ensures the test correctly handles existing stock ribbons created during demo setup, preventing a validation error. This ensures the rental stock functionality continues to operate as expected.
Original PR description
Currently, running test `test_out_of_stock_ribbon_is_not_applicable_for_rentals` with demo data enabled leads to a validation error: `Only one ribbon with the "assign when out of stock" option is allowed.` This happens because, with demo data loaded, an "out of stock" ribbon is already created via XML data. The test then attempts to create another ribbon with the same configuration, triggering the constraint and causing the failure. Related PR: https://github.com/odoo/enterprise/pull/112660 runbot-[242457](https://runbot.odoo.com/odoo/error/242457) ---
This update corrects a bug that prevented users from saving accounting settings when GST registration was unregistered. The fix ensures the system correctly validates required fields based on the user's GST registration status, preventing a 'Missing Required Fields' error. This ensures smooth operation for all users, regardless of their GST registration.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#114423
13 changes
Resolved issues and error corrections
This update fixes an issue where changing the delivery date for Hungarian invoices caused incorrect journal entries due to outdated exchange rates. The fix ensures that the most recent exchange rate is consistently applied, preventing financial imbalances and improving accuracy in financial reporting. This impacts how taxes are calculated on invoices.
Original PR description
### Issue: When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries ### Cause:…
### Issue: When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries ### Cause: `expected_currency_rate` was recomputed when `delivery_date` changed, but the new value was never automatically applied In addition, after https://github.com/odoo/odoo/pull/225407, `_sync_tax_lines` partially updated the lines: https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L3029-L3031 https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L1633-L1637 These methods reapply the previous tax rate, causing base and tax lines to be updated inconsistently As a result, when the base amount increases, the tax amount decreases, and vice versa ### Steps to reproduce: - Install `l10n_hu_edi` and `accountant` with demo data, then switch to the `HU company` - Go to Currencies → USD and add two rates: April 5: HUF per Unit = 100 April 6: HUF per Unit = 150 - Create an Invoice: (Any customer, Currency: USD, Line: Price = 1000, Tax = 27%) - Open the Journal Items and duplicate the browser tab for comparison - In the duplicated tab, change the Delivery Date to April 5 and save - Change the Delivery Date back to today and compare both tabs ### Before the fix: The values differ between both tabs because the tax lines keeps the old exchange rate opw-5801126
This update fixes an issue where users could accidentally select customers from different companies within the Helpdesk system. The fix involved adding a restriction to the customer selection field, ensuring users only see customers within their assigned company. This improves data accuracy and prevents misdirected support requests.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#111909
This update corrects a technical error in how Odoo's Discussions feature sorts partners based on email addresses. The fix ensures that partners with matching email prefixes are correctly prioritized, leading to more accurate and relevant search results within Discussions. This improves the overall user experience.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
This update enhances the speed and efficiency of our appointment scheduling system by adding crucial database indexes. These indexes help prevent issues during automatic database cleanup (garbage collection), ensuring smoother operation and faster response times. This primarily impacts the appointment module and related workflows.
Original PR description
appointment.invite model has a GC. We should therefore check FK linking that model has a 'btree_not_null' index to avoid issues when running the garbage collect. TAsk-
This update fixes a bug that prevented purchase order matching when invoice lines included UoM information but lacked a corresponding product. The fix avoids unnecessary UoM conversions, resolving the 'UoM categories differ' error and ensuring accurate purchase order processing. This improves the reliability of our invoicing and purchasing workflows.
Original PR description
Steps
---------
1. Install Purchase and Accounting
2. Create a Bill
a. Add a line with no product and an UoM
3. Hit the Purchase matching button in the header
-> Error: the UoM categories differ
Problem
---------
PO matching fails if there is an invoice line with an UoM but no product
because it will try to convert the UoM and Quantity on the line to the
one UoM of the product. Since there is no product, the categories differ
which makes the conversion fail.
Solution
---------
Don't convert when there is no product.
opw-6109513
opw-6085388
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the HTML editor's undo function sometimes restored the selection to the wrong position. By staging the selection before deletion, the system now accurately restores the user's previous state, ensuring a smoother and more reliable editing experience. This improves overall usability and reduces frustration for users.
Original PR description
Problem: In some cases, undo restores the selection to an incorrect position. Cause: The selection state was not staged before the deletion started, leading to an inconsistent selection being restored during undo. Solution: Stage the selection before performing the deletion to ensure it can be restored to the correct position. Steps to reproduce: - Go to To-Do → Create New. - Type something on the first line and press Enter. - Type something on the second line and apply styling to it. - Use the Up arrow key to move to the first line. - Remove a character. - Press Undo (Ctrl + Z). - Observe that the selection and toolbar appear on the second line. task-6142055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update strengthens the security of our Odoo IoT applications on Windows by ensuring the correct use of trusted SSL certificates for web socket connections. By aligning with industry best practices, this fix enhances reliability and protects against potential connection issues, particularly in IoT environments. It also includes necessary legal agreements for contributors.
Original PR description
This is a forward port of #261031 to 18.0. The websocket-client library defaults to the system's SSL context, which can be broken or outdated on Windows. This aligns websocket TLS verification with the `requests` library by forcing a certifi-backed CA bundle. This improves reliability on Windows IoT environments without changing reconnect logic. Adds corvanis corporate CLA and vvro individual CLA.
This update fixes a bug where the PDF viewer field didn't properly save the uploaded file's name. Now, when you upload a PDF, the correct filename is stored, improving the user experience and data accuracy within the system. This ensures consistent file management and reporting.
Original PR description
When uploading a file using the PDF viewer field, the filename was not stored in the corresponding filename field. This commit updates the PdfViewerField to support a filename field via the `filename` attribute. task-4825728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where users were incorrectly denied access to manufacturing orders due to analytic account restrictions. The fix ensures access is only blocked when the analytic line is associated with a valid timesheet entry, preventing unnecessary errors and improving user workflow. This resolves a conflict between modules.
Original PR description
Steps to reproduce the bug: - Log in as Mitchel Admin - Create a storable product “P1” - Create a bill of materials: - Component: 2 units - Miscellaneous > Project: - Select any project - Create a…
Steps to reproduce the bug:
- Log in as Mitchel Admin
- Create a storable product “P1”
- Create a bill of materials: - Component: 2 units - Miscellaneous > Project: - Select any project
- Create a manufacturing order:
- Select the BoM
- Confirm the MO
- Set Qty to Produce to 1 unit → an analytic account is created
- Set the following access rights for Marc Demo:
- Accounting: Administrator - Timesheets: User (Own timesheets only) - MRP: User
- Log in as Marc Demo
- Open the MO created by Mitchel Admin
- Try to update the Qty to Produce to 2
Problem:
A user error is raised:
"You cannot access timesheets that are not yours."
→ The restriction is applied even if the analytic line is not a timesheet entry.
Solution:
Restrict access only if the analytic line corresponds to a timesheet entry.
We cannot use the `is_timesheet`` field because it is implemented in the
`timesheet_grid`` module, and the `hr_timesheet` module does not depend
on it.
opw-4724262This update resolves a bug that allowed users to incorrectly return more items than were picked up in rental orders. By making the 'delivered' and 'returned' quantity fields read-only when the rental transfer feature is active, the system now prevents these data inconsistencies, ensuring accurate rental tracking and order management.
Original PR description
Steps to reproduce: - Enable the “Rental Transfers” option in settings - Create a rental product “P1” and update its quantity on hand to 10 units - Create a rental order with 10 units of P1 - Confirm the order → The delivery is created and marked as done, and the return picking is also created with 10 units reserved - Manually update the delivered and returned quantities on the sale order line - Create another delivery order Issue: A user error is raised: "The operation cannot be completed: You cannot return more than what has been picked up." Cause: The fields `qty_delivered` and `qty_returned` were editable even when the “Rental Transfers” feature was enabled, allowing inconsistent data entry. Solution: Make both fields readonly when the “Rental Transfers” option is enabled. opw-5126656
This update fixes a potential issue where multiple maintenance requests could block the same work center simultaneously, leading to scheduling conflicts. The change adds a validation step to ensure no overlapping maintenance blocks are created, improving the reliability of maintenance scheduling and preventing disruptions to operations.
Original PR description
Steps to reproduce: - Create a work center "WC1" - Create a maintenance request with: - For: Work Center - Work Center: WC1 - Block Work Center: True - Scheduled Date: Dec 30, 4:00 PM - Scheduled End: Dec 30, 5:00 PM - Save the record - Create another maintenance request with the same parameters Problem: It is currently possible to create multiple maintenance requests that block the same work center over the same time period. No validation is performed to check whether the work center is already blocked for the selected dates. Solution: - Add an explicit overlap check on maintenance requests that block a work center - Prevent creation or update when another non-done maintenance request already blocks the same work center during the same time slot - Perform the validation before generating calendar leaves to enforce the business rule at the data level opw-5065874
This update fixes an issue where the return quantity displayed in the stock return wizard was incorrect when the product's unit of measure differed from the unit of measure used in the original delivery order. The system now correctly converts quantities to the product's UoM before calculating returns, ensuring accurate inventory adjustments.
Original PR description
Steps to reproduce: - Create a storable product "P1" with UoM set to KG - Update on-hand quantity to 1 KG - Create a delivery order for 100g of P1 and validate it - Click the Return button Problem: The return wizard displayed 100 KG instead of 0.1 KG. The `uom_id` field on `stock.return.picking.line` is a non-stored related field pointing to `product_id.uom_id`. The quantity was taken directly from the stock move (expressed in the move's UoM) without being converted to the product's UoM before being passed to the wizard. Solution: Convert the quantity from the move's UoM to the product's UoM. opw-6113515 Forward-Port-Of: odoo/odoo#262069
Miscellaneous changes
No description available.
3 changes
Resolved issues and error corrections
This update fixes a bug that prevented users from accessing timesheet data when certain access rights were configured. The change ensures that access controls are correctly applied to analytic lines, avoiding errors related to manufacturing orders. This improves the reliability of timesheet reporting for all users.
Original PR description
Steps to reproduce the bug:
- give only the following access rights to Marc demo:
- Timesheets, mrp, inventory: User
- create a storable product “P1”
- create an analytic distribution model:
- product: P1
- analytic distribution: Administrative
- create a manufacturing order to produce 10 units of P1
- confirm the MO
- set qty producing to 5 units
- save
Problem:
An access error is triggered:
“
Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Analytic Line (account.analytic.line) “
Solution:
The account analytic line is not linked to a project or timesheet, so we should not check this access right.
opw-4534971This update corrects a bug where public holidays without working schedules weren't appearing in payroll reports. The fix ensures that all public holidays, regardless of their working schedule, are now correctly included in the SD worx generation process. This improves the accuracy of payroll calculations for Belgian businesses.
Original PR description
### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070
This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to currency differences. The fix ensures statements are now automatically assigned to the correct journal based on currency, preventing financial misallocations. This improves the accuracy of financial reporting.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931