Daily updates from Odoo
Tuesday, May 5, 2026
54 changes · saas-19.3
Resolved issues and error corrections
This update resolves an error that prevented users from submitting surveys with background images. The issue stemmed from outdated code referencing a removed component. The fix ensures background images load correctly during the survey submission process, improving the user experience.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves an issue where IoT-connected printers weren't correctly configured within Odoo's Point of Sale (PoS) system. Previously, these printers were unusable. This fix ensures that IoT printers are properly loaded, allowing for seamless operation within the PoS workflow.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable. Forward-Port-Of: odoo/enterprise#115826 Forward-Port-Of: odoo/enterprise#115768
This update fixes a visual issue where quick actions were incorrectly displayed on tracking messages. By standardizing the styling of tracking messages, quick actions are now positioned correctly, ensuring a consistent and user-friendly experience for viewing email notifications.
Original PR description
Previously, quick actions were incorrectly positioned on tracking messages, as they were not treated the same way as notification messages in terms of bubble styling. This PR ensures that tracking messages are handled like notification messages by excluding them from bubble coloring, resulting in the correct placement of quick actions. task-6176330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoices created in a branch environment with tax-included prices didn't correctly calculate the price after applying a fiscal position. Previously, the unit price remained at the full tax-included amount. This change ensures accurate price recalculation and tax handling for multi-company branch operations, improving financial reporting.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#262190 Forward-Port-Of: odoo/odoo#256897
This update resolves an issue preventing the successful import of Winbooks data for Belgian companies. The fix allows Odoo to correctly recognize a specific tax account (411000) used in Winbooks, ensuring accurate data import and avoiding an error message. This improves the reliability of the Winbooks import process.
Original PR description
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"…
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK" 3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable") 4. Confirm the import The import fails with: "You must select a receivable account for 'Tax Receivable Account'." Why the issue ------------- In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade". This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after. However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import. Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again. The fix ------- Add back the same bypass originally introduced in 20804db6d87. opw-6092464 Forward-Port-Of: odoo/enterprise#115291
A small typo in the quality module caused newly created quality alert records to be incorrectly grouped under 'None'. This fix replaces the incorrect '&' character with the correct '|' character, ensuring records are assigned to the appropriate stages.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update fixes an issue where changing a task's project would reset its state (done or canceled) unnecessarily. Now, the state remains consistent when a task is marked as done or canceled, ensuring accurate tracking of task completion and preventing redundant state updates. This improves the reliability of project management workflows.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864 Forward-Port-Of: odoo/odoo#261648 Forward-Port-Of: odoo/odoo#252752
This update fixes an issue where duplicating a user also duplicated their associated tasks, leading to confusion and potential data inconsistencies. The change ensures that tasks are correctly assigned to new users, preventing shared task assignments and simplifying user management. This improves data accuracy and user experience.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update resolves an issue where very long image filenames in Odoo caused errors, specifically 502 errors when uploading images through the Sales Order editor. The fix truncates filenames to 255 characters to ensure compatibility with server limits, improving image upload stability for users.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
This update corrects a bug that occurred when manually creating vendor bills and DIAN commercial events were rejected. The fix ensures that retries work correctly, preventing errors related to outdated data and improving the reliability of DIAN integration for our Colombian users. This resolves a specific issue that only appears in standard testing environments.
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#114758
This update optimizes appointment scheduling by only calculating availability for the current month, rather than pre-computing all slots. This change significantly reduces the system's workload and improves response times when users are booking appointments, leading to a smoother user experience. It's a performance enhancement focused on the appointment module.
Original PR description
Generate all slots and compute only availabilities for the display month instead of pre-computing all slots for the whole booking period. task-4144524 Forward-Port-Of: odoo/enterprise#115986
This update fixes a bug preventing the correct import of PINT invoices (Australia, Japan, Myanmarese, Singapore) by adding logic to identify the document type. It also corrects a previous issue where tax amounts were incorrectly processed for JP PINT invoices, ensuring accurate financial reporting.
Original PR description
## PINT modules (`l10n_*_ubl_pint`)
The UBL module wasn't able to import PINT documents because there was no logic to detect the type of UBL document for PINT invoices (`urn:peppol:pint:billing-1@{anz, jp, my, sg}-1`). This PR adds the methods to detect PINT UBL documents and provide appropriate EDI decoder model names. Along with the fix, test cases are added to verify proper import of the said UBL's.
## Base EDI module (`account_edi_ubl_cii`)
Additionally, `_correct_invoice_tax_amount` in the base UBL import is fixed to only process TaxSubtotal nodes in the document currency. Previously it iterated over all `TaxTotal/TaxSubtotal` nodes regardless of currency, which caused the JP PINT import to pick up the company-currency tax amount instead of the document-currency one. JP PINT is the only format that includes TaxSubtotal in both TaxTotal nodes.
Forward-Port-Of: odoo/odoo#262010
Forward-Port-Of: odoo/odoo#258017This update ensures that 'Final Consumer' records are correctly identified as individuals, not companies, within the CO Edition module. The change resolves an issue where the system incorrectly classified these records, and includes updated tests to verify anonymous document creation. This ensures accurate reporting and compliance.
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 an issue where users lacked access to equity information for partners associated with different companies within their Odoo Enterprise setup. The change adds a company identifier to equity records, ensuring accurate reporting and access to all relevant partner data, regardless of company affiliation.
Original PR description
Before this commit, if you had some holders only visible to a company you don't have access to, the cap table would show an access error. This commit introduces multi-company logic to equity models by adding a new company_id field related to the company_id of the partner_id. Other partners (holder, seller, subscriber) will have their companies checked against that company. task-6018771 Forward-Port-Of: odoo/enterprise#110724
This update resolves visual issues with Saudi document layouts by removing redundant information and dynamically updating key details like VAT numbers. It ensures all Saudi companies use the correct paper format, improving the accuracy and presentation of invoices and reports.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where translations for the Dutch returns module (l10n_nl_returns) were missing. Adding the necessary translation keys ensures accurate and complete functionality for our Dutch-speaking users. This resolves a potential issue with localized reporting and processes.
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
A recent problem with the departure form being inaccessible when accessed through payslips has been resolved. This change ensures the correct form view is used, preventing errors and improving the user experience for employees submitting departure requests.
Original PR description
The departure form could fail to load when accessed via payslip due to a leaked form_view_ref in the context. Explicitly set the correct form view in the action to avoid this issue. task-6167494 Forward-Port-Of: odoo/odoo#261701
This 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 the user experience and preventing disruptions to the accounting workflow.
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 corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting that granted excessive access to overtime calculations. The fix removes this access and includes new tests to ensure this issue doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#262206 Forward-Port-Of: odoo/odoo#261496
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
This update resolves issues related to how tracking messages are generated and displayed within Odoo. Specifically, it ensures accurate formatting of tracking data, corrects inconsistencies in test cases, and improves the handling of various tracking field types, ultimately enhancing the reliability of tracked communications.
Original PR description
Since [1] trackings are embed in message body. This PR provides various fixes and improvements following the merge of the revamped implementation. See commits for more details. Task-6128706 [1] See odoo/odoo#235719 and odoo/enterprise#99500
This update resolves issues related to how tracking information is embedded within messages, primarily impacting notification displays and test reliability. The changes ensure tracking values are correctly formatted and accessible, improving the overall user experience and fixing inconsistencies in tracking data.
Original PR description
Since [1] trackings are embed in message body. This PR provides various fixes and improvements following the merge of the revamped implementation. See commits for more details. Task-6128706 [1] See odoo/odoo#235719 and odoo/enterprise#99500
A recent update to the softphone's initial display has caused a problem with the setup tour. The tour now incorrectly assumes users will see the keypad tab instead of the recent calls tab. This fix ensures the tour functions correctly when the softphone is first opened, providing a smoother user experience.
Original PR description
Commit [1] made the softphone to show recent tab when there are missed calls. Commit [2] changed the demo data to contain 1 missed call. As a result, now when you open the softphone for the first time, you will see recent tab instead of the keypad tab before. This breaks the country_selector_tour which assumes you will see keypad tab when open softphone. [1]: c995b7df3fc6ff541dc65d8b28661ab03f4a8c08 [2]: f16faa029220ca7152289180c4de78783bab03be
This update fixes an issue where the COGS calculation was incorrectly inflated when multiple lines of the same product were invoiced separately from a single Sale Order. The change ensures that COGS are accurately attributed to each individual invoice, preventing inaccurate profitability reporting. This improves the reliability of sales data and financial reporting.
Original PR description
### Issue: When a Sale Order has multiple lines for the same FIFO-costed product and each line is invoiced separately, the COGS posted on the second (and any subsequent) invoice is incorrectly…
### Issue: When a Sale Order has multiple lines for the same FIFO-costed product and each line is invoiced separately, the COGS posted on the second (and any subsequent) invoice is incorrectly inflated, causing the sale to appear less profitable or even at a loss in the accounting records. ### Steps to reproduce: 1. Set a product as storable with FIFO costing and real-time valuation. 2. Create a Sale Order with two lines for the same product at different prices. 3. Confirm the SO and validate the two deliveries (each consumes a different FIFO layer). 4. Invoice the first SO line and post the invoice. 5. Invoice the second SO line and post the invoice. 6. Observe that the COGS on the second invoice is higher than the actual cost of the stock move linked to that line. ### Root Cause: _get_cogs_qty() and _get_posted_cogs_value() in sale_stock filtered already-posted COGS lines by product_id. This caused them to aggregate quantities and values across ALL SO lines sharing the same product. However, _get_cogs_price_unit() derives the unit cost only from the current line's stock move. The mismatch results in: (unit_cost_of_line_2 * total_qty_of_both_lines) - cogs_already_posted ### Fix: Replace the product_id filter with a sale-line-scoped filter using cogs_origin_id. By checking cogs_origin_id.sale_line_ids & sale_lines, only COGS originating from the same SO line(s) as the current invoice line are considered, correctly isolating each line's COGS from the others. opw-6004810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257868
This update resolves an issue where mail tracking functionality was unreliable due to timezone dependencies. The fix prevents message type changes during copying and introduces a user error to maintain data consistency, ensuring accurate tracking of messages and improving overall system stability. This addresses potential data inconsistencies and enhances the reliability of our messaging features.
Original PR description
- avoid company timezone dependency to prevent traceback without resource module.
- prevent message_type change when copying tracked messages
Raise a UserError when copying a message with tracking values and changing message_type to avoid inconsistent chatter data.
task-5260614This update resolves an issue impacting the accuracy of tracking messages within Odoo's reporting and expense modules, specifically for Russian localization (l10n_in_reports) and document/knowledge management. The changes streamline tracking data handling and improve search reliability, ensuring more reliable reporting and expense tracking.
Original PR description
- l10n_in_reports: fix tracking message search reliability
Replace tracking_value_ids based search with body and message_type.
- hr_expense: tracking copy cleanup
delegate tracking_value_ids handling to mail tracking module.
task-5260614A recent update resolves an issue where manufacturing orders were only processing the first 40 components of a Bill of Materials (BoM). This change ensures that all components, regardless of quantity, are correctly accounted for in the manufacturing process, preventing errors and ensuring accurate production tracking. This fix improves the reliability of manufacturing order creation.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/256655/changes/c5f0e5685b0d08fb85f723ba13e2795a06bbcfea Steps to reproduce the bug: - Create a BoM with more than 40 components - Create a manufacturing order with this BoM Problem: Only the first 40 components are taken into account and their moves are created; the remaining ones are not created. opw-6186544 Forward-Port-Of: odoo/odoo#262692
This update fixes an issue where analytic accounting wasn't correctly linking partners to journal entries during internal stock transfers. The fix ensures that the correct partner information is associated with the journal entry, improving the accuracy of financial reporting related to inventory movements. This resolves a discrepancy in how analytic distributions were applied.
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
This update resolves an issue where the 'Amazon move' status was incorrectly set to 'False' due to a missing link between stock moves and pickings. The code now uses the 'reference' field, ensuring accurate tracking of Amazon orders within the inventory system. This prevents reporting errors related to Amazon shipments.
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 resolves an issue where the system was prematurely skipping remuneration declarations, particularly when employees had periods without worked days but still received payments like end-of-year bonuses. The fix ensures accurate calculation of all declared remuneration amounts, improving payroll reporting for our Belgian clients.
Original PR description
Forward-Port-Of: odoo/enterprise#115998 Forward-Port-Of: odoo/enterprise#106689
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 that occurred within the ODOO.LIST.HEADER function, ensuring the spreadsheet remains responsive and stable. This resolves a potential disruption to users creating and managing 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 discounts weren't being imported correctly, leading to incorrect subtotal calculations for imported invoices. The fix prevents rounding of discounts during import, ensuring the imported invoice's subtotal matches Odoo's calculation. This improves data accuracy for IT VAT invoices.
Original PR description
**PROBLEM** When importing an invoice, we don't want to round the discounts, to avoid discrepancy between the subtotal computed by Odoo, and the subtotal of the file we import. To do this, we change the decimal precision of discount to 100 digits when importing files. However, float_round wasn't built with this in mind, in float round, we add a small epsilon to fix some rounding issue. This small epsilon changes the amount of the discount (50.0 -> 0.5000000000004) and this changes the subtotal. **STEP TO REPRODUCE** 1. Install l10n_edi_it. 2. Change the VAT number of IT Company to 05098540288 (to match the one on the file to import). 3. Import the file present in the bug ticket. 4. Notice the subtotal of the line doesn't match what's in the invoice. **FIX** We skip rounding of the discount on import. Ticket [link](https://www.odoo.com/odoo/project.task/6046324) opw-6046324 Forward-Port-Of: odoo/odoo#262562 Forward-Port-Of: odoo/odoo#256037
This update fixes a bug where discounts weren't applied to vendor bills with products listed at a price of $0.00, even when charges and allowances were present. Previously, the system only calculated discounts based on the product's price. This change ensures that discounts are correctly applied in these scenarios, aligning Odoo totals with the vendor's invoice data. A new test has been added to prevent future issues.
Original PR description
Allowances for Product with price as 0.00 aren't applied Step to reproduce: - import vendor bill from an XML having a product: - price: 0.00 - charge: any positive amount - allowance: any positive amount Current behavior: - allowance isn't apply resulting in a difference between the XML total and Odoo total Cause of the issue: Before this commit the discount was applied as a percent of price only. Having a price as 0 prevent doing so. opw-5499525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247938
This update fixes a bug that prevented users from seeing key options within the 'Alert' block in the email marketing editor. The change ensures that options like background color and border are now available, streamlining the process of creating effective email campaigns. It also simplifies the alert option by removing redundant size options.
Original PR description
### Steps to reproduce 1. Open Email Marketing 2. Open/Create a Mailing 3. In the editor, insert an `Alert` block. --------> Some options won't be visible. ### Technical The [commit] restructured the…
### Steps to reproduce 1. Open Email Marketing 2. Open/Create a Mailing 3. In the editor, insert an `Alert` block. --------> Some options won't be visible. ### Technical The [commit] restructured the `Alert` snippet, therefore, for the builder to identify the mass mailing's alert block, we need to adapt the selector of the option to `.s_mail_alert`. After this commit, the following options will become visible (which were invisible before the commit): - Background Color - Border Option Note: 1. mass_mailing's `Alert` option now correctly uses the mass mailing's option template. Which included different size options, but those are now already added by `size_option_plugin`. Therefore this commit also removes those redudant size options from the alert option. [commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6 Task-5999942 **The commit removing the image transform from the previous PR is no longer necessary here and has been removed in this PR.** Forward-Port-Of: odoo/odoo#262361 Forward-Port-Of: odoo/odoo#260923
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies post-fix adjustments to the untaxed amount, aligning with existing tax calculation processes. This ensures accurate invoice generation and reporting related to UBL imports.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260992
This update resolves an issue where incorrect pivot IDs were used in purchase and vendor dashboards. The fix ensures accurate data representation within these reports, improving the reliability of key business insights related to purchasing and vendor management. This change was a necessary correction to maintain data integrity.
Original PR description
This commits fixes the pivot id in some formulas. Task: 5875749 Forward-Port-Of: odoo/enterprise#114559
This update ensures that barcode validations during stock receipt creation correctly check if a destination has been scanned, even if it's the default location. Previously, the system didn't verify this, leading to potential issues. This change enhances the reliability of the barcode scanning process for stock management.
Original PR description
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a…
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a destination on all products" - Open the barcode app, create a new receipt - Scan a product > Validate #### > You are not blocked by the fact that you did not scan any destination even just to validate the default one ### Cause of the issue: The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app. ### Note: Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322 In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576 It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination. ### Note 2: We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter: https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109 opw-6110690 Forward-Port-Of: odoo/enterprise#115723 Forward-Port-Of: odoo/enterprise#114429
This update ensures correct processing of invoices from KSeF (a Polish tax system). It now requires vendors, even those based outside Poland (like Luxembourg), to use the Polish NIP number format when issuing invoices. This is a regulatory requirement for KSeF compliance, ensuring accurate tax reporting.
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 resolves a technical issue preventing proper tracking of expenses within the Stripe integration for the Enterprise module. The fix addresses a dependency conflict related to how tracking values were handled, ensuring accurate expense tracking and reporting. This improves the reliability of expense data.
Original PR description
tracking_value_ids are used in _transfer_messages_to_card but since the seperation of tracking values from mail, it's failing. task-6186968
This update resolves an issue where unexpected data in spreadsheet URLs caused server warnings. By using URL fragments instead, the spreadsheet link is now more stable and reliable, preventing potential disruptions to users accessing the shared spreadsheets. This change ensures a smoother user experience.
Original PR description
We currently rely on a query parameter to sync the active sheet id to the public spreadsheet url but hitting a public controller with unexpected query parameters raises a warning in the server logs, which is not great. Url fragments, on the other hand, are never transfered to the server. Task-6148443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure related to message attachments in the Odoo platform. The issue occurred when the Documents app was not installed, preventing proper testing. This fix ensures consistent test results across all Odoo builds.
Original PR description
Since https://github.com/odoo/odoo/commit/7f422e1de045790c503b55224a799e89f8d63e09, test_channel_message_attachments test breaks in any builds that does not have documents app installed. This commit fixes this issue [Runbot-242809](https://runbot.odoo.com/odoo/error/242809) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr