Daily updates from Odoo
Tuesday, May 5, 2026
66 changes · saas-19.2
Resolved issues and error corrections
A bug was fixed that prevented the custom color settings for self-ordering kiosks from being applied. The issue stemmed from a missing data field, which defaulted to the standard color. This update ensures that self-ordering kiosks now correctly display the configured color scheme.
Original PR description
The background color configured for the self ordering / kiosk was not applied. This was caused because the `self_ordering_primary_color` field was not sent to the self order when loading the data, resulting in the default color always being used. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6149865
This update fixes an issue where invoices in a multi-company branch environment weren't accurately calculating prices with taxes included. Previously, the unit price didn't correctly reflect the exclusion of the initial tax. Now, invoices will correctly adjust the price to exclude the original tax when a fiscal position is applied.
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 where long image filenames in Odoo could cause website errors. The system now automatically shortens these filenames to prevent exceeding server limits, ensuring images load correctly and maintaining a stable user experience. This improves the reliability of image uploads and related features.
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
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy and reporting.
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 resolves a crash in the form builder when using the 'Add other' option with radio buttons. The fix prevents a JavaScript error that occurred when the system tried to access data from a special input field created by the 'Add other' feature. Now, the form builder works reliably with this functionality.
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-prThis update fixes an issue where copying a user also duplicated their associated tasks, leading to shared task assignments. The change ensures that tasks are correctly isolated to the new user, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
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 ensures that EC Sales Reports generated for the Swedish market (l10n_se) are exported to KVR in whole numbers, as required by Swedish tax regulations. Previously, the export included decimal places, which was incorrect. This fix corrects the rounding logic to meet reporting standards.
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#115980 Forward-Port-Of: odoo/enterprise#114292
This update prevents Odoo from crashing when viewing order details without a linked employee. Previously, enabling 'Log in with Employees' after processing an order would cause issues. Now, the 'Served By' field defaults to the user who created the order, ensuring a smoother experience.
Original PR description
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is…
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is enabled after at least one order has already been processed. **After this commit** If there isn't an `employee_id` associated with an order, don't try to overwrite the "Served By" field. By default, this should allow the name of the user who processed the order to be displayed. This can be seen in the original `getOrderFields()` method on the `OrderDetailsDialog` component. https://github.com/odoo/odoo/blob/e1c81c326e370b0a7b5bc8018b151e251ebce544/addons/point_of_sale/static/src/app/screens/ticket_screen/order_details_dialog/order_details_dialog.js#L81 This commit is mostly a backport of the slight refactor in 19.3, with the added benefit of still showing the names of the users who processed orders before `pos_hr` was installed on the database. https://github.com/odoo/odoo/blob/be57b42442db8c6be219d36f8c3e07e8baf45e31/addons/pos_hr/static/src/app/screens/order_details_dialog.js#L10-L15 opw-6169880
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 selecting it. Now, users can directly create and edit digipoort certificates within the primary accounting settings, improving usability.
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 fixes a bug preventing the correct import of PINT invoices for Australia, Japan, Myanmar, Singapore, and other regions. The changes include logic to identify the specific UBL document type for each region, ensuring accurate tax calculations and EDI processing. New test cases have been added to verify the improved functionality.
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 created within the CO Edition are correctly identified as individuals, not companies. Previously, a calculation error resulted in these records being incorrectly classified. The fix includes a necessary adjustment to the data and updated tests to guarantee accurate record creation.
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. The change adds a company identifier to equity models, ensuring accurate reporting and access to all relevant partner data, regardless of company affiliation. This enhances the reliability of equity reporting within the Odoo Enterprise system.
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 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 clarifies the tax selection process on invoices for Saudi Arabia (l10n_sa). Previously, users incorrectly chose a general VAT tax, leading to compliance issues. This fix simplifies the settings and ensures accurate tax calculations according to ZATCA regulations.
Original PR description
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT`…
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT` is visible with the other `0%` taxes such as `0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT` instead of the actual `0%` taxes according to the characteristics of the supply; leading to non-compliance with the ZATCA rules. Before this commit: - `15% PH PE HS` tax was `active`. - `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and distribution for refunds: `base tax grid = 3(B)`. - `0% Not Subject to VAT` tax was `active` and had distribution for invoice: `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)` - `0% IT G and 0% QT` taxes were `active`. After this commit: - `15% PH PE HS` tax is `inactive`. - `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)` and distribution for refunds: `base tax grid = 2(B)` - `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid has been removed. - `0% IT G and 0% QT` taxes have been set to `inactive`. task-5959979 Forward-Port-Of: odoo/odoo#253598
This update resolves visual issues and ensures accurate Saudi document formatting. Specifically, it dynamically updates VAT information and standardizes paper formats for Saudi companies, improving the clarity and reliability of printed 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 the Dutch translations for the 'l10n_nl_returns' module were missing from the project's translation files. Adding these translations ensures accurate and complete functionality for Dutch-speaking users of the Enterprise software. This resolves a potential display issue and improves the user experience.
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 an issue preventing correct December pay calculations after migrating to a new data structure. The fix adds necessary input definitions, ensuring the wizard accurately writes pay values and avoids calculation errors. This ensures accurate payroll processing for Belgian users.
Original PR description
Purpose: after migrating to property inputs, the inputs for december pay weren't added to the properties definition so when you use `action_validate` in the december pay wizard, the values weren't written to these inputs as they don't exist in the definition task-id: 6103779 Forward-Port-Of: odoo/enterprise#105075
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
This update resolves an issue where channel mentions stopped functioning correctly. A technical error allowed code with failing tests to be merged, causing the disruption. This fix ensures channel mentions are working as expected, improving communication within Odoo.
Original PR description
Forward-port of PR introduced regression where channel mention was no longer working [1]. There was a bug on runbot that didn't prevent merging code with failed test. This commit fixes the typo. [1]: https://github.com/odoo/odoo/pull/260457 Forward-Port-Of: odoo/odoo#261083
This update corrects a calculation error related to Pay-As-You-Go (PFA) and Determined Pension Value (DPV) in the Belgian payroll module. Separating these computations ensures more accurate payroll processing and compliance with Belgian tax regulations, minimizing potential discrepancies.
This update corrects a recent change in how Odoo uses its GeoIP databases. Previously, the system incorrectly favored the larger city database as a fallback, which could have impacted location accuracy. This fix reverts the previous change, ensuring the system utilizes the appropriate database based on compatibility for optimal performance and location data.
Original PR description
There are two geoip database: a small and fast-to-query country database, and a big but slower-to-query city database. As the City record inherits from the Country record, we can access the country…
There are two geoip database: a small and fast-to-query country database, and a big but slower-to-query city database. As the City record inherits from the Country record, we can access the country informations from the City record. In our case it means that when the ip was geolocalized against the city db, we can reuse the city record for the country informations, we don't need to query the country db. It also means that in case the country database does not exist, we can query the city database for the equivalent country information: it is slower but returns the information. In commit 06b0e0017651 we tried to simplify the code a bit, and decided to return the city database as fallback to the country database when the latter was not found/corrupt. This is wrong because if the city and country *records* are indeed compatible, the city and country *databases* are not. This commit reverts the changes that were included in the `[MOV]` commit. Reference-to: 06b0e0017651 ([MOV] core: http.router.root.geoip -> http.geoip)
This update resolves a problem where Nilvera was not consistently retrieving recently created invoices due to a timezone mismatch. The end_date parameter has been adjusted to account for Nilvera's TR timezone (Istanbul), ensuring that all invoices are synchronized correctly. This prevents missed invoices and improves data accuracy.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera does not return recently created documents (within ~3 hours), which can lead to missing invoices during synchronization. # Current behavior before PR: The end_date was set to the current time, causing recently created documents to be excluded from the fetch results. # Desired behavior after PR is merged: The end_date is extended by 3 hours (TR GMT+3), ensuring recently created documents are included and not missed during synchronization. task-id: [6123171](https://www.odoo.com/odoo/my-tasks/6123171) I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#259306
This update resolves an issue where the POS category grouping feature incorrectly displayed products marked as 'special' or excluded. The fix extracts and applies the existing filtering logic to the grouped products, ensuring only intended items are shown. This improves the accuracy and usability of the POS category functionality.
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 resolves an issue preventing users from changing chart templates for companies without journal entries when cash rounding is enabled. The fix ensures that chart template swaps no longer cause errors, providing greater flexibility in managing company financial settings. This improves usability and reduces potential disruptions.
Original PR description
Allow changing chart template for companies without journal entries even if cash rounding exists. Previously, profit_account_id in account.cash.rounding caused a traceback because this account is deleted during the chart's swap. task-5232399
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.
Original PR description
This commits fixes the pivot id in some formulas. Task: 5875749 Forward-Port-Of: odoo/enterprise#114559
This update fixes a bug where an unwanted image option was visible in the email marketing builder. The changes ensure that only relevant options are displayed, improving the user experience and preventing confusion. The update also streamlines the alert option to use the correct template and remove redundant size options.
Original PR description
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced…
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced the `OptionComponent` with some modified version. As the `OptionComponent` is no longer present in the base option, patching the same won't use the modified option. Hence, the option became visible in the mass mailing builder. This commit adapts the mass mailing builder with the refactoring of the options API to keep the image transform option hidden. Also, the size option for the image have been adapted to consider the original options condition. [commit]: https://github.com/odoo/odoo/commit/179480d996a19dff4d56265a610259b1c6e33f99 Commit 2 ------------------- ### 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. 2. The width option for the `Alert` block is already added by original `width_option_plugin`, therefore we remove the patch of the selector inside mass mailing to avoid redundancy. [commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6 Task-5999942 Forward-Port-Of: odoo/odoo#262361 Forward-Port-Of: odoo/odoo#260923
This update resolves a bug where adding a lot to a detailed operation in stock management would reset the quantity and erase the lot. The fix ensures that picked states are correctly updated when detailed operations are used, preventing data loss and ensuring accurate stock tracking. This improves the reliability of the subcontracting process.
Original PR description
### Steps to reproduce: - Create and confirm an MO for 1 unit of product without bom - Set the producing quantity to 1 - Add a new component line for a product tracked by SN - Click on details…
### Steps to reproduce: - Create and confirm an MO for 1 unit of product without bom - Set the producing quantity to 1 - Add a new component line for a product tracked by SN - Click on details operation and add a lot > Save - Produce all #### > The quantity is of the component move is reset to 0 and the lot erased ### Cause of the issue: Setting the producing quantity to 1 will set the state of the of the MO to `to_close`. After which, adding a new move will add it in the appropriate `picked` state so that the move is considered when validating the MO: https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/mrp/models/stock_move.py#L269-L270 However, clicking on the detailed operation and selecting a lot will create a new `move_line` without set `picked`. As such the related picked compute method of the stock move will be launched: https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L123-L127 resetting the picked state of the move to False as a new move line was added (triggering a dependency of its compute method): https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move_line.py#L126 https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/stock/models/stock_move.py#L280-L286 Additional change: The test `TestSubcontractingBasic.test_flow_tracked_1` underlined that the `auto_pick_move_lines` context key added to `action_show_details` had to be cleaned in subcontracting flows before synchronizing the subcontracted productions: https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/mrp_subcontracting/models/stock_move_line.py#L34-L38 Otherwised, if a receipt for tracked subcontracted product is picked and additional move lines are added via the detailed operations, the subcontracted backorders created to fulfill the additional demand will will pick each of their move leading to subcontracted MO's that will avoid assignment: https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L1914-L1916 and be cancelled at the picking validation: https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/mrp/models/mrp_production.py#L1924 https://github.com/odoo/odoo/blob/6d7b1ffb8bbea77baa9feb9087b320a9e01ea715/addons/stock/models/stock_move.py#L2107-L2109 This can be checked by launching the test without the `clean_context`. We also improve the `TestSubcontractingBasic.test_flow_tracked_1` test as it is not possible to edit moves to be picked prior to confirmation and since move lines can not manually be created in picked state. ### Fix: Note that we rely on a context key to adapt the compute method of the picked field of the `stock.move.line` instead of adding a `default_picked` context in the `action_show_details` because the new move lines added to the list view of the `move` form are generated via the UI by opening a list of `stock.quant` which cleans the `default_context` key prior to generation of the `new` move line. In particular, the exact UI flow can not be tested by relying on the `Form` class of stock moves since the new move lines will then be created by via the `O2MForm` class: https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L642-L658 and an onchange of the stock move line will be triggered to determine its value relying on the `default_picked` context key to create the new move line in picked state: https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L332-L339 https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/odoo/tests/form.py#L579 https://github.com/odoo/odoo/blob/06bc382d8f722ef87c23e360992df0743e350172/addons/web/models/models.py#L2005-L2008 By contrast performing the flow from the interface will highlight that the `default_picked` context key does not solve the issue. opw-5991985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258935
A recent update caused manufacturing orders to incorrectly process only the first 40 components of a Bill of Materials (BoM) with more than 40 components. This fix ensures that all BoM components are accurately reflected in the manufacturing order moves, preventing errors and ensuring complete production tracking. This resolves an issue impacting order fulfillment accuracy.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/14d3893c763f6413581e7f36099cee0adb2caa83 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 resolves a problem where the 'unfold all' option was incorrectly applied during the export of aged receivable reports (like PDFs). Previously, this resulted in overly complex reports. This change ensures that reports are generated with the correct level of detail, improving usability and report clarity.
Original PR description
This commit introduced a small issue: https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 When exporting a report (the aged receivable in pdf for example), the option key "unfold_all" was set but shouldn't be.
This update resolves an issue in the Belgian payroll module where holiday attestation occupations were being calculated incorrectly. The fix replaces a direct field access with a more reliable method, ensuring accurate holiday entitlement calculations for employees. This improves payroll accuracy and compliance.
Original PR description
. use _get_hours_per_week() method instead of calling the field on the version task-6185339
This update resolves an issue where users lacking specific permissions on employee records would encounter an access error when attempting to view attendance data. The change corrects a technical error related to accessing employee data fields, ensuring a smoother experience for all users. This fix improves usability and prevents disruptions to attendance reporting.
Original PR description
Steps to reproduce: ---------------------------------------- - Connect with a user having no rights on Employee - Try to open Attendances - Access error Cause: ---------------------------------------- Since 218b91cad3e50b27a84624145c89ed6bb23f18c5 we read the field `is_flexible` on employee which is a field only accessible to `hr.group_hr_user` ([src](https://github.com/odoo/odoo/blob/70ade77937bfc171a3352e70c5c78bfd87ceb4d1/addons/hr/models/hr_version.py#L154)). opw-6179252
This update resolves an issue where manufacturing order confirmations incorrectly triggered consumption alerts for certain components. The fix ensures that component compatibility with the specific product variant is now checked, preventing unnecessary alerts and streamlining the production process. This improves accuracy and reduces potential delays.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color -> Red & Blue
- BoM: -Components: - C1: apply on variant Blue - C2: apply on all variant
- Create a manufacturing order to produce one P1 red
- only the move raw C2 is created -> expected behavior
- Confirm the MO
- Try to validate the production
Problem:
A consumption issues is triggered to indicate that C1 is missing
Explication:
When confirming a manufacturing order, we checks if some BoM components are missing and may trigger a consumption issue.
However, the check was done on all BoM lines of the exploded BoM, without verifying whether the component was compatible with the variant being produced.
As a result, a consumption issue could be raised even when the missing component was not supposed to be consumed for the selected variant.
opw-6062762A small bug fix has been implemented to ensure that operation durations displayed in the Gantt view are accurately shown in hours instead of minutes. This ensures that users see the correct time estimates for work orders, improving planning accuracy. The change was triggered by a previous formatting update.
Original PR description
Issue ----- In the gantt view, operation duration is displayed as minutes but is actually in hours. Steps to reproduce ----- - Enable work orders - Create a product with a BoM - Add an operation with some duration on the BoM - Creation a MO for the product, confirm & plan - Open the gantt view > Duration is displayed in minutes Cause ----- Overlooked by the rework of formatter done in b764335. Value is in hours but unit is set to "minutes". https://github.com/odoo/enterprise/blob/8281fe6c830dce94ca851bf4bd5c768443721f17/mrp_workorder/static/src/mrp_workorder_gantt_renderer.js#L46-L49 ----- Ticket: opw-6109524
This update fixes an issue where invoices were incorrectly including non-validated timesheets in service orders. The change ensures that invoices only reflect validated timesheets, aligning with the 'only validated TS' invoicing policy setting. This prevents over-invoicing and maintains accurate financial records.
Original PR description
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product.…
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product. - From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them. - Invoice the SO, using a timesheets period that includes both TS. - Notice that the quantity of the invoice line includes the non-validated timesheet. **Cause** The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1 **Change** Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain. opw-6116670 Forward-Port-Of: odoo/odoo#261835 Forward-Port-Of: odoo/odoo#259224
This update resolves a discrepancy in invoice subtotals caused by rounding errors during the import process. The fix prevents rounding of discounts when importing invoices, ensuring accurate calculations and matching imported data with Odoo's subtotal. This improves data integrity for Italian 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 ensures discounts are correctly applied to vendor bills when a product's price is set to $0.00, even if charges are included. Previously, products with a zero price prevented discount calculations. This change corrects a discrepancy between the imported invoice total and the Odoo total, ensuring accurate financial reporting.
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
A technical error prevented importing emissions data through the ESG reporting module. This update restricts imports to manual emissions data, resolving a database conflict issue related to journal entry emissions. This ensures data integrity and stability within the ESG reporting functionality.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#115856 Forward-Port-Of: odoo/enterprise#115306
This update optimizes appointment scheduling by calculating availability only for the current month, rather than pre-computing slots for the entire booking period. This change significantly reduces the system's workload and improves response times when users are scheduling appointments. It's a performance enhancement focused on a key user experience.
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 corrects a bug that prevented users from saving 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.
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
This update resolves an issue where tours for the purchase and stock modules didn't initiate correctly in community builds. The fix leverages an existing utility function to ensure tours open properly, regardless of whether the enterprise version is installed. This ensures a consistent and functional experience for all users.
Original PR description
The tours: - `test_basic_purchase_flow_with_minimal_access_rights` - `test_basic_stock_flow_with_minimal_access_rights` fail to perform the first step if enterprise is not in the addons path since the app icons are not in the the main view. Fortunately, a general util is already present to perform the task of opening the app in both community and enterprise builds: https://github.com/odoo/odoo/blob/e258de4235b4872e0427017e22b46495080c25dc/addons/web_tour/static/src/tour_utils.js#L81-L101 https://github.com/odoo/odoo/blob/e258de4235b4872e0427017e22b46495080c25dc/addons/web_tour/static/src/tour_utils.js#L36-L43 runbot-240934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262559
This update ensures that barcode validations in the stock picking app correctly check if a destination has been scanned before processing, even when 'Force a destination' is enabled. Previously, the validation wasn't triggered, leading to potential issues. This change ensures accurate picking and reduces the risk of incorrect inventory updates.
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 fixes a bug that prevented users from assigning recruiters to new job positions when the hr_payroll module wasn't installed. The fix ensures the necessary data is consistently available, resolving an error message and improving the user experience. This change enhances the reliability of the recruitment process.
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
This update ensures continued functionality with Sendcloud by adding a compatibility key. Sendcloud has transitioned to a new API version, and this change allows Odoo to continue using the older, supported version for existing customers. Future work will focus on upgrading to the latest Sendcloud API.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114544 Forward-Port-Of: odoo/enterprise#114441
This update fixes an issue where the product amount in the sales preview was incorrectly showing tax excluding prices. The fix ensures that the preview accurately reflects the total price, including taxes, when 'Tax Included' is selected in company settings. This improves the accuracy of sales quotes and order previews.
Original PR description
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a…
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a quotation with this product. - Confirm the line amount shows 10 (tax included). - Click on preview. **Observation:** - In the preview, the product line amount is shown as tax excluded. **Root cause:** - At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`. - This logic is not applied in the portal preview and PDF report. **Solution:** - Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`. [1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663 Before: --- <img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" /> After: --- <img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" /> opw-6089473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261892 Forward-Port-Of: odoo/odoo#258551
This update fixes an issue where the quantity received on purchase orders was incorrectly calculated when products had different unit of measures. Specifically, the system was using the product's unit of measure instead of the purchase order's unit of measure, leading to incorrect invoicing suggestions. Additionally, a translation error was resolved that caused confusing error messages during the receiving process.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45 Steps to reproduce: - Create a new database with only the Purchase module installed - Enable the "Units…
Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45 Steps to reproduce: - Create a new database with only the Purchase module installed - Enable the "Units of Measure & Packagings" option - Create a storable product "P1" with the following vendor pricelist: - Vendor: Azure Interior (1 pack of 6 for $10) - Create a purchase order: - Vendor: Azure Interior - Quantity: 3 packs of 6 of P1 - Confirm the PO - Click the Receive button (available without the Stock module since v19.1) Problem: 1:/ Expected behavior: qty_received = 3 (in purchase UoM: packs of 6) Actual behavior: qty_received = 18 (product UoM: units) `product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6. 2:/ The parameter `invalid_targets` was not properly passed to the translation function in the error message, causing a traceback when trying to receive a PO in an invalid state. opw-6080527 Forward-Port-Of: odoo/odoo#260163
This update fixes a minor calculation error in the 'l10n_ar_withholding' module related to payment processing. The system was incorrectly calculating withholding taxes, resulting in a slight discrepancy in the total payment amount. This fix ensures accurate withholding calculations for payments, guaranteeing correct tax reporting.
Original PR description
**Steps to reproduce:** * Install `l10n_ar_withholding` module. * Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%) * Select 'Own Checks'…
**Steps to reproduce:** * Install `l10n_ar_withholding` module. * Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%) * Select 'Own Checks' within the payment method. * Clear Withholding lines and add line with tax `IIBB WTH CABA`. * In the Checks tab, input the check number, date, and amount (30000) natively. * The computation of the withholding lines is triggered. **Observed behavior:** * The total gross amount registered computes to exactly $30,247.93 instead of mathematically converging to the true original invoice debt of $30,250.00. **Cause:** * The `l10n_ar_withholding` module uses an iterative mathematical solver to progressively bump `wizard.amount` upward to effortlessly offset and scale the equivalent proportionate withholding taxes accurately. * However, inside Odoo's iterative memory loop (`for i in range(201)`), the ORM caches computed values across passes for NewId performance. As `wizard.amount` increments upwards, the dynamically dependent `l10n_ar_withholding_ids.base_amount` and `amount` fields fail to automatically invalidate their internal cache. * The loop relies on these statically cached values (e.g., $247.93) to verify if equilibrium has been reached, wrongfully satisfying the balancing exit condition and halting the loop prematurely. **Fix:** * Recompute the `base_amount`, `amount` using `add_to_compute` on the `l10n_ar_withholding_ids` automatically inside the iterative loop in `account_payment_register.py`. * This signals the ORM to cleanly dump the stale cache dependencies, natively forcing mathematically correct recalculations of the proportionate untaxed withholdings at every incremental `wizard.amount` step. The solver now strictly converges optimally to exactly block the correct value in 1-2 rapid passes without hanging on legacy computation artifacts. opw-5934489 Forward-Port-Of: odoo/odoo#254635