Daily updates from Odoo
Navigate
Branch
Wednesday, December 3, 2025
210 changes
20 changes
Enhancements to existing features
This update clarifies the Peppol settings within the Odoo configuration. Previously, users lacked a visual indicator of their current Peppol mode (demo/test/prod), potentially leading to configuration errors. Now, a label clearly displays the active mode, reducing the risk of mistakes and improving usability.
Original PR description
Before this PR : The Peppol settings section in the settings page did not show the current mode (demo/test/prod). Users had no clear indication of the active mode, which could lead to mistakes. After this PR : A small label is now displayed in the Peppol settings section to clearly indicate the current mode when not in production. task-5149768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238039 Forward-Port-Of: odoo/odoo#236072
This update replaces the specific "Uruware" name in the Odoo settings with a generic "UCFE Provider" label for the electronic invoicing provider. This ensures customers contact Odoo support directly, streamlining assistance and maintaining a consistent configuration for Uruguayan users.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539 Forward-Port-Of: odoo/enterprise#101053 Forward-Port-Of: odoo/enterprise#99065
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key partner data changes. A new feature has been added for Belgium, leveraging the VAT number to automatically identify the Peppol identifier, streamlining data entry and validation.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378 Forward-Port-Of: odoo/odoo#238251 Forward-Port-Of: odoo/odoo#233160
Resolved issues and error corrections
This update resolves an issue where duplicate account IDs were causing data overwrites. The changes accurately reflect new Singapore tax specifications by segregating CPF and SHG accounts and adjusting account numbers. This ensures accurate financial reporting for Singapore businesses.
Original PR description
Two accounts were using the same XML ID `account_account_864`, causing second definition to overwrite the first. This commit resolves the duplication and updates/segregates accounts for CPF and SHG according to new specifications.
Changes:
- Update `account_account_864` (Employee Expense) to `account_account_866`.
- Update in accounts:
* 862 → CPF Withheld (Employee)
* 863 → CPF Accrued (Employer)
* 864 → SHG Withheld (Employee)
* Add new 865 → SDL Accrued (Employer)
* 859 → CPF Employer Expense
* 860 → SDL Employer Expense
* Removed 861
- Fix `transfer_account_code_prefix` in the template:
* Change from `101100` to `10110` to avoid generating 7-digit account codes.
task-5360160
Forward-Port-Of: odoo/odoo#238264
Forward-Port-Of: odoo/odoo#237506A minor typo in the SEPA Direct Debit payment provider configuration has been fixed. The message displayed to users now uses the correct grammatical form ('a unique' instead of 'an unique'), ensuring consistent and professional communication. This update improves the overall user experience.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
A technical error was preventing users from correctly adjusting salary benefits during the offer generation process. This update resolves a 'TypeError' that occurred when a specific benefit type ('Always Selected') was used, ensuring the salary package website page functions smoothly for all users. This improves the user experience and prevents potential data inconsistencies.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update resolves an issue preventing payroll officers from accessing salary offer details. The fix prevents access errors when opening offers by intelligently handling permission restrictions related to candidate records. This ensures payroll officers can continue generating salary offers without needing recruitment rights.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712 Forward-Port-Of: odoo/enterprise#100980 Forward-Port-Of: odoo/enterprise#95869
This update fixes an issue where discounts on purchase orders weren't correctly reflected in accrued expense entries. The system now accurately displays the total tax excluding the discount, ensuring accurate financial reporting. This resolves a discrepancy between the purchase order and the expense record.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848 Forward-Port-Of: odoo/odoo#229441 Forward-Port-Of: odoo/odoo#225375
This update fixes a visual glitch in the website header animation. Previously, the header would unexpectedly disappear after a short delay, even when scrolling. This change ensures a smoother and more reliable user experience when using the 'Fade Out' scroll effect.
Original PR description
Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the "Scroll Effect" dropdown, select "Fade Out" - Drop some snippets to allow scrolling on the page - Scroll down then scroll to top QUICKLY The timeout to hide the header after the fade animation end is not cleared. Therefore, after 400ms, the header is shifted upward and disappears, even if the user scrolled up and made the header reappear. task-5357217 Forward-Port-Of: odoo/odoo#237515
This update fixes an issue where Argentinian invoices weren't correctly displaying taxes in the company's local currency, even when the setting was enabled. The previous code was unintentionally removing the tax section. This change ensures invoices accurately reflect tax amounts in the appropriate currency for Argentinian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Switch to a Argentinian company (e.g. (AR) Responsable Inscripto) - In Accounting settings, enable "Taxes in company currency" option - Activate another currency (e.g. USD) - Create an invoice in USD - Confirm the invoice - Print the invoice **Issue:** The section showing the taxes in the company currency doesn't appear on the invoice despite the enabled option. Cause: An override of "report_invoice_document" from l10n_are is removing the section no matter what the configuration. **Solution:** Do not remove the section. It was done originally in 17.0 where "Taxes in company currency" option didn't exist. opw-5351010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238204
This update resolves an issue where PayPal payments were failing due to missing shipping address information. The fix adds a default value to shipping address fields, ensuring PayPal transactions can proceed smoothly. This improves the reliability of our payment processing system.
Original PR description
Paypal was failing when the address fields were `False` **Solution:** Add a fallback to missing fields in the shipping address Fixes: https://github.com/odoo/odoo/issues/237360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238340
This update corrects a test within the MRP Work Order module that was failing without the use of Odoo's demo data. The fix addresses a requirement that users must be part of a specific group to correctly view lot IDs when selecting quantities in the shopfloor. This ensures consistent test results and accurate reporting.
Original PR description
The user need to be part of the group `stock.group_production_lot` to see the `lot_id` in the view used to select a quant in the shopfloor. https://github.com/odoo/odoo/blob/0e50df1ea86b3c9584f407bdbc39b4e308b9c8d8/addons/stock/views/stock_quant_views.xml#L164-L166 Forward-Port-Of: odoo/enterprise#101064
This update resolves an issue where administrators could still access documents from archived companies within the Documents app. The fix ensures that archived company folders are excluded from the admin search, maintaining data privacy and security. This prevents sensitive information from being inadvertently viewed by non-admin users.
Original PR description
**Steps to reproduce:** - Install Documents app - Create a bunch of companies with their own folders - Archive the companies - Try to open Documents app with admin - Access Error is raised **Issue:** Archived companies not properly taken into account in the search permission. **Fix:** Explicitly check of archived status for the folders company. The behavior is that normal users won't see documents from archived companies but admins still can. From related PR: > Also need to ensure archived companies are not removed from the admin search > domain even if the user has `active_test=False` related: https://github.com/odoo/enterprise/commit/b7e6acba60e50c86627b177a86b357d2bb956cbc opw-5127040 Forward-Port-Of: odoo/enterprise#100652 Forward-Port-Of: odoo/enterprise#100133
This update fixes a visual issue where buttons within the image field were not vertically centered. The change uses SCSS flexbox to reliably center the buttons, ensuring a consistent and professional appearance. This was implemented in SCSS for easier maintenance and to accommodate potential variations in the component.
Original PR description
The buttons in image_field are not centered vertically. Since it's a custom sized button, using flex is reliable (it's now centered on both flex axis). Note: Done in SCSS instead of utilities because the flex is there to compensate the custom size set in SCSS (easier to maintain) + there could be injected buttons in the component. task-5258887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235964
This update fixes a bug where reverse charge tax amounts were incorrectly recorded as debits when creating invoices with down payments from sales orders. The change ensures the tax amount is correctly applied to the credit side, aligning with accounting regulations and improving invoice accuracy. This resolves issue OPW-5172402.
Original PR description
When creating an invoice with down payment from a sales order, the reverse charge tax amount goes into the debit side. Make sure the reverse charge tax amount goes into the credit side. opw-5172402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237557
This update resolves an issue where fiscal printers were blocked when printing receipts with reward lines and multiple order items. The fix reorders how discounts are applied to prevent the printer from incorrectly blocking due to a small discount on the last line. This ensures accurate receipt printing for all transactions.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale Forward-Port-Of: odoo/enterprise#98699
This update fixes a technical issue that prevented completion notifications in the MRP Work Order module from being translated into different languages. The fix ensures that users receive localized notifications, improving the user experience for international customers. This was a necessary step to fully support Odoo's multi-language capabilities.
Original PR description
The `_t()` was put around the wrong thing, making the strings never translatable. Followup to: 4403621 Forward-Port-Of: odoo/enterprise#101119
The POS digest email now accurately reflects all POS orders, regardless of invoicing status. Previously, the ‘Open Report’ link within the digest would fail when all orders were uninvoiced. This fix ensures the digest provides a complete and reliable report for all POS transactions.
Original PR description
The POS digest email shows metrics based on *uninvoiced* POS orders, but the “Open Report” link in the digest opens a report filtered to *invoiced* orders only. As a result, when all POS orders are uninvoiced, the link leads to an empty view. ### Steps to reproduce 1. Ensure that all existing POS orders are **uninvoiced**. 2. Enable Developer Mode, then navigate to **Settings → Technical → Email → Digest Email**. 3. Open any digest and click **"Send Now"** to generate a new digest email. 4. Open the generated digest and click the **POS report** link. This results in a blank page. ### Cause There is a mismatch between: * the digest computation (showing only uninvoiced orders), and * the report view called by the digest link (showing only invoiced orders). ### Fix Ensure the POS report shows unvoiced orders. opw-5087701 Forward-Port-Of: odoo/odoo#236727
This update corrects a bug where discounts from purchase orders were incorrectly being added to sale orders during import. The change ensures that sale order discounts always default to zero, aligning with business expectations that discounts shouldn't automatically transfer from purchase orders. This was resolved through a refactoring and a new check implemented in 18.0.
Original PR description
Discounts are always sent by `_retrieve_line_vals` in `account_edi_ubl_cii` In Sale orders, discounts aren't expected to be automatically imported from the purchase order, it should always be 0. `test_so_import_product_from_po` didn't use to fail because discount wasn't checked until the recent refactor https://github.com/odoo/odoo/pull/190310 Check was added in 18.0 to avoid this error in the future. Steps to reproduce: - Disable discount in sale app - Create a PO with a discount on any POL - Enable discounts - Import SO from PO Issue: Discount is added to the Sale order lines. Runbot: 232724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238203 Forward-Port-Of: odoo/odoo#237743
This update resolves an issue where the Odoo application remained listed after uninstalling on Windows. The fix ensures the correct registry keys are removed during uninstallation, preventing persistent entries in the installed software list. This improves the user experience and maintains accurate software tracking.
Original PR description
Since d0d0fa2b8e the Windows installer only supports 64 bit version of the OS. It was recently noticed that when uninstalling the app with the provided uninstaller that the app remains listed in the installed software. Although the directories and third party apps were correctly cleaned and removed. The reason is that the Odoo app registry key is still present after the uninstall process. When a 32 bit process tries to write a registry key in `HKLM\SOFTWARE` it's redirected by the OS to `HKLM\SOFTWARE\WOW6432Node`. By using the `SetRegView 64` NSIS directive, the installer writes the registry key at the right place ... but the uninstaller is lacking that directive and thus tries to remove a non existing key in `HKLM\SOFTWARE\WOW6432Node`. With this commit, the uninstaller is fixed by using the directive too. Forward-Port-Of: odoo/odoo#238476
16 changes
Enhancements to existing features
This update clarifies the Peppol settings within the Odoo configuration. Previously, users lacked a visual indicator of their current Peppol mode (demo/test/prod), potentially leading to configuration errors. Now, a label clearly displays the active mode, reducing the risk of mistakes and improving operational efficiency.
Original PR description
Before this PR : The Peppol settings section in the settings page did not show the current mode (demo/test/prod). Users had no clear indication of the active mode, which could lead to mistakes. After this PR : A small label is now displayed in the Peppol settings section to clearly indicate the current mode when not in production. task-5149768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238039 Forward-Port-Of: odoo/odoo#236072
Resolved issues and error corrections
This update resolves an issue where duplicate account IDs were causing data overwrites. The changes update account codes for CPF, SHG, and SDL tax calculations, aligning with new Singapore tax regulations. The change also simplifies account code formatting to prevent excessively long codes.
Original PR description
Two accounts were using the same XML ID `account_account_864`, causing second definition to overwrite the first. This commit resolves the duplication and updates/segregates accounts for CPF and SHG according to new specifications.
Changes:
- Update `account_account_864` (Employee Expense) to `account_account_866`.
- Update in accounts:
* 862 → CPF Withheld (Employee)
* 863 → CPF Accrued (Employer)
* 864 → SHG Withheld (Employee)
* Add new 865 → SDL Accrued (Employer)
* 859 → CPF Employer Expense
* 860 → SDL Employer Expense
* Removed 861
- Fix `transfer_account_code_prefix` in the template:
* Change from `101100` to `10110` to avoid generating 7-digit account codes.
task-5360160
Forward-Port-Of: odoo/odoo#238264
Forward-Port-Of: odoo/odoo#237506A minor typo in the SEPA Direct Debit payment provider configuration has been corrected. The change ensures grammatically correct messaging is displayed to users, improving clarity and professionalism. This fix addresses a simple formatting issue.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update fixes an issue where Argentinian invoices weren't correctly displaying taxes in the company's local currency, even when the setting was enabled. The previous code was inadvertently removing the tax section. This change ensures invoices accurately reflect tax amounts in the appropriate currency for Argentinian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Switch to a Argentinian company (e.g. (AR) Responsable Inscripto) - In Accounting settings, enable "Taxes in company currency" option - Activate another currency (e.g. USD) - Create an invoice in USD - Confirm the invoice - Print the invoice **Issue:** The section showing the taxes in the company currency doesn't appear on the invoice despite the enabled option. Cause: An override of "report_invoice_document" from l10n_are is removing the section no matter what the configuration. **Solution:** Do not remove the section. It was done originally in 17.0 where "Taxes in company currency" option didn't exist. opw-5351010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238204
This update fixes an issue where discounts on purchase orders weren't being correctly reflected in the final accounting. The fix ensures that the total price, including discounts and taxes, is accurately displayed when creating accrued expense entries after a purchase order with a discount is confirmed and received. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848 Forward-Port-Of: odoo/odoo#229441 Forward-Port-Of: odoo/odoo#225375
A technical error was causing a traceback when generating salary package offers. This update corrects a flaw in the system's logic that occurred when 'Always Selected' benefits were present, preventing the offer generation process from failing. This ensures smooth and reliable offer creation for employees.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update fixes an error that prevented payroll officers from accessing salary offer details. The issue stemmed from the module attempting to access candidate records, which required recruitment rights. The fix ensures payroll officers can now open and manage offers without needing these additional permissions.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712 Forward-Port-Of: odoo/enterprise#100980 Forward-Port-Of: odoo/enterprise#95869
This update fixes a visual glitch on the Odoo website where the header would unexpectedly disappear after scrolling. The issue was caused by a timeout in the animation process, now resolved to ensure a smoother and more reliable user experience. This improves the overall appearance and usability of the website.
Original PR description
Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the "Scroll Effect" dropdown, select "Fade Out" - Drop some snippets to allow scrolling on the page - Scroll down then scroll to top QUICKLY The timeout to hide the header after the fade animation end is not cleared. Therefore, after 400ms, the header is shifted upward and disappears, even if the user scrolled up and made the header reappear. task-5357217 Forward-Port-Of: odoo/odoo#237515
This update resolves an issue where PayPal payments were failing when shipping address fields were left blank in Odoo. The fix adds a default value to these fields, ensuring PayPal transactions can proceed smoothly. This improves the reliability of our payment processing.
Original PR description
Paypal was failing when the address fields were `False` **Solution:** Add a fallback to missing fields in the shipping address Fixes: https://github.com/odoo/odoo/issues/237360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238340
This update corrects a bug where discounts from purchase orders were incorrectly being added to sale orders during import. The fix ensures that sale order lines always reflect a discount of 0, aligning with expected business logic. This was triggered by a recent code change and addressed with a targeted test.
Original PR description
Discounts are always sent by `_retrieve_line_vals` in `account_edi_ubl_cii` In Sale orders, discounts aren't expected to be automatically imported from the purchase order, it should always be 0. `test_so_import_product_from_po` didn't use to fail because discount wasn't checked until the recent refactor https://github.com/odoo/odoo/pull/190310 Check was added in 18.0 to avoid this error in the future. Steps to reproduce: - Disable discount in sale app - Create a PO with a discount on any POL - Enable discounts - Import SO from PO Issue: Discount is added to the Sale order lines. Runbot: 232724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238203 Forward-Port-Of: odoo/odoo#237743
This update fixes a visual issue where buttons within the image field were not vertically centered. The change utilizes SCSS flexbox to ensure consistent and reliable centering, accommodating the field's custom sizing. This improves the overall appearance and usability of the image field.
Original PR description
The buttons in image_field are not centered vertically. Since it's a custom sized button, using flex is reliable (it's now centered on both flex axis). Note: Done in SCSS instead of utilities because the flex is there to compensate the custom size set in SCSS (easier to maintain) + there could be injected buttons in the component. task-5258887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235964
This update resolves a printer blocking issue that occurred when printing receipts with reward lines and multiple order items. The fix ensures accurate discount calculations, preventing errors that previously caused the printer to halt. This improves receipt printing reliability for Italian POS users.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale Forward-Port-Of: odoo/enterprise#98699
This update resolves an issue where users without the correct access rights to a project couldn't upload documents. The fix checks user permissions before attempting the upload, preventing a 'NotFound' error and ensuring proper functionality for all users.
Original PR description
Step To Reproduce: - install Project - login with admin and open any Project settings, say Project 1. - create a upload document activity for 'marc demo' - ensure marc demo has 'User' access for…
Step To Reproduce: - install Project - login with admin and open any Project settings, say Project 1. - create a upload document activity for 'marc demo' - ensure marc demo has 'User' access for project - login with marc demo - open same project (kanban card -> view) - upload a document for the created activity Observation: - Traceback ``` TypeError: Cannot destructure property 'id' of '(intermediate value)' as it is undefined at Activity.onFileUploaded ``` Cause: - upload request to `/mail/attachment/upload` , calls `mail_attachment_upload` which then tries to access thread for 'write' mode, 'project.project ' model . - as marc demo does not have write access to this model, no thread is returned - so `NotFound()` is raised https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mail/controllers/attachment.py#L48-L55 Fix: - we check if selected user has appropriate rights or not for upload activity opw-5160132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234936
This update fixes an issue where the table editor incorrectly selected adjacent cells when users tried to select all text within a cell using Shift and arrow keys. Now, after selecting all text, only the current cell is selected, allowing for more precise editing and selection of individual cells.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In an m × n table, type some text inside a cell. - Place the cursor at the end of the text. - Hold Shift and repeatedly press ArrowLeft until the entire cell becomes selected. Once the cell content is fully selected, the cell itself is selected along with its adjacent cell, instead of only the current cell. **Desired behavior after PR:** After selecting all text, the current cell alone should become selected. Pressing Shift + ArrowLeft again should then extend the selection to the adjacent cell. task-5268801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235959
The POS digest email now accurately reflects all POS orders, regardless of invoicing status. Previously, the ‘Open Report’ link within the digest would only display invoiced orders, resulting in a blank page when all POS orders were uninvoiced. This fix ensures the digest provides a complete and accurate report.
Original PR description
The POS digest email shows metrics based on *uninvoiced* POS orders, but the “Open Report” link in the digest opens a report filtered to *invoiced* orders only. As a result, when all POS orders are uninvoiced, the link leads to an empty view. ### Steps to reproduce 1. Ensure that all existing POS orders are **uninvoiced**. 2. Enable Developer Mode, then navigate to **Settings → Technical → Email → Digest Email**. 3. Open any digest and click **"Send Now"** to generate a new digest email. 4. Open the generated digest and click the **POS report** link. This results in a blank page. ### Cause There is a mismatch between: * the digest computation (showing only uninvoiced orders), and * the report view called by the digest link (showing only invoiced orders). ### Fix Ensure the POS report shows unvoiced orders. opw-5087701 Forward-Port-Of: odoo/odoo#236727
This update resolves an issue where the Odoo application remained listed after uninstalling on Windows. The fix ensures the correct registry keys are removed during uninstallation, preventing persistent entries in the installed software list. This improves the user experience and maintains accurate software tracking.
Original PR description
Since d0d0fa2b8e the Windows installer only supports 64 bit version of the OS. It was recently noticed that when uninstalling the app with the provided uninstaller that the app remains listed in the installed software. Although the directories and third party apps were correctly cleaned and removed. The reason is that the Odoo app registry key is still present after the uninstall process. When a 32 bit process tries to write a registry key in `HKLM\SOFTWARE` it's redirected by the OS to `HKLM\SOFTWARE\WOW6432Node`. By using the `SetRegView 64` NSIS directive, the installer writes the registry key at the right place ... but the uninstaller is lacking that directive and thus tries to remove a non existing key in `HKLM\SOFTWARE\WOW6432Node`. With this commit, the uninstaller is fixed by using the directive too. Forward-Port-Of: odoo/odoo#238476
6 changes
Resolved issues and error corrections
A minor typo in the SEPA Direct Debit payment provider configuration has been fixed. The message displayed to users now uses the correct grammar ('a unique' instead of 'an unique'), ensuring consistent and professional communication. This update improves the overall user experience.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update resolves an issue where document previews were not updating correctly after renaming documents. Previously, the preview displayed the old attachment name even after a successful rename. This fix ensures that document previews always reflect the most current document name, regardless of how the document was renamed.
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433
Forward-Port-Of: odoo/enterprise#95111A technical error was causing a traceback when generating salary package offers. This update corrects a problem in the system's logic that occurred when 'Always Selected' benefits were configured. This ensures the offer generation process works reliably for all benefit configurations.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881A bug in the payment state test was corrected to accurately reflect the behavior of invoices when the 'accountant' module is installed or not. This ensures consistent invoice payment state management, particularly when payments are reset to draft.
Original PR description
The `test_bill_state_change_on_payment_state` is throwing an exception. ``` self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ```…
The `test_bill_state_change_on_payment_state` is throwing an exception. ``` self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` The test was incorrectly expecting invoice `payment_state` to always be `not_paid` when payment is reset to draft, but behavior differs based on whether `accountant` module is installed or not. - With `accountant`: Payment has no move_id (no journal entry created by default), so when drafted, `invoice.matched_payment_ids` filters exclude it, resulting in 'not_paid' state. - Without `accountant`: Payment has move_id (journal entry auto-created) so filter conditions fail (`not p.move_id` is `False`), and invoice stays `paid` due to existing reconciliations in `draft` state. Test was introduced here: https://github.com/odoo/enterprise/pull/100834/commits/402bd85af79fa68fa2cb957d40307edf62f7525c Commits that introduced the behavior change: https://github.com/odoo/odoo/pull/182390/commits/b572fcd78289013f28f11157b1bfbb75c9ea7344 https://github.com/odoo/odoo/blob/57f1053b031f293c6cd8dc8f590dccda4fb3e665/addons/account/models/account_move.py#L1308-L1314 Runbot [link](https://runbot.odoo.com/odoo/error/234573) runbot error: 234573
This update significantly speeds up the process of matching bank transactions with sale orders. By optimizing the query, the system now utilizes indexes, resulting in a much faster search time. This improves overall system performance and responsiveness.
Original PR description
Finding a match between the bank transactions and sale orders is currently done via an unoptimized query that is preventing postgres from using any index. This commit removes the unnecessary CTE by simply doing the query directly on the sale_order table. This way we can also use a trigram index on the regex used for matching and postgres will be able to utilize it for faster search. Benchmarks: | Num sale_order | Before | After | | -------------- | ------ | ------ | | 1391909 | 3.88 s | 0.27 s | Ticket [link](https://www.odoo.com/odoo/project.task/5139457) opw-5139457 Forward-Port-Of: odoo/enterprise#100623 Forward-Port-Of: odoo/enterprise#100470
This update resolves a technical issue preventing fiscal printers from correctly handling reward lines and multiple order lines. The fix ensures accurate receipt printing by adjusting how discounts are applied, preventing printer blocking and ensuring correct calculations.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale Forward-Port-Of: odoo/enterprise#98699
15 changes
New functionality added to Odoo
This update introduces a new contingency invoicing feature for Colombia, allowing businesses to continue issuing invoices even if their connection to the DIAN electronic invoicing system is temporarily unavailable. This ensures ongoing tax compliance and maintains accurate customer records, providing a backup solution for invoice processing.
Original PR description
Purpose: Contingency Invoices ensures the continuity of the invoicing process in the event of technical failures, service interruptions, or inability to connect to the DIAN electronic invoicing system. It allows the user to issue valid invoices, ensuring compliance with tax obligations and maintaining commercial traceability. Expected Behavior: For customer invoices, when the user selects the document type to be a contingency, the user will be able to print the contingency invoice report without DIAN information to send to their customers. Once the connection establishes with the DIAN, the user can send the invoice to the DIAN and print a completed invoice with all the information received by the DIAN. task-5091290
Enhancements to existing features
This update streamlines the rendering of templates within Odoo Enterprise modules by removing outdated syntax and promoting cleaner, more efficient code. The changes enhance performance and maintainability, ensuring a smoother user experience for Enterprise users. This work addresses inconsistencies and improves the overall structure of the templates.
Original PR description
see community: https://github.com/odoo/odoo/pull/235469 see: https://github.com/odoo/odoo/pull/197296
Resolved issues and error corrections
This update resolves an issue where discount calculations on Mexican global invoices were producing incorrect values, leading to errors. The fix ensures accurate rounding of discount amounts during invoice generation, aligning with Mexican tax regulations. This improves the reliability of invoice creation for our Mexican customers.
Original PR description
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ```…
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ``` Code : CFDI40108 Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. ``` Why the fix: ------------ The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63. https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336 Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62. opw-5023597 Forward-Port-Of: odoo/enterprise#95982 Forward-Port-Of: odoo/enterprise#94438
This update fixes an issue where Brazilian vendor bills incorrectly applied sales taxes instead of purchase taxes due to a flaw in the external tax calculation. The fix ensures that the correct tax type ('COFINS Incl.' etc.) is used when computing taxes for vendor bills, improving financial accuracy for Brazilian businesses using Odoo.
Original PR description
**Steps to reproduce:** - Install accountant, l10n_br and l10n_br_avatax - Switch to a Brazilian company - In Accounting settings, configure AvaTax (require credentials) - Create a bill - Compute taxes with AvaTax **Issue:** If a tax like "COFINS Incl." should be added, the Sales tax is added instead of the Purchases one, resulting in an incorrect account for the tax line. **Cause:** Brazilian localization allows to use AvaTax for vendor bills, but the external tax feature doesn't take into account the type of the tax when searching for one. It just returns the first one based on the name, the amount and some other domains. **Solution:** Add the tax type in the domain when searching a Brazilian tax. **PR (Community):** https://github.com/odoo/odoo/pull/236930 opw-5044423 Forward-Port-Of: odoo/enterprise#100854 Forward-Port-Of: odoo/enterprise#100340
A technical error was preventing users from correctly adjusting salary benefits within the offer generation process. This update resolves a 'TypeError' that occurred when a specific benefit type ('Always Selected') was present, ensuring the salary package website page functions as intended. This fix improves the user experience for generating salary offers.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update fixes an error that prevented payroll officers from accessing salary offers. The issue stemmed from the module attempting to access candidate information, which required recruitment rights. The fix ensures payroll officers can now open and manage offers without needing these additional permissions.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712 Forward-Port-Of: odoo/enterprise#100980 Forward-Port-Of: odoo/enterprise#95869
A minor grammatical error in the SEPA Direct Debit payment provider configuration message has been corrected. This ensures consistent and accurate messaging for customers, improving the overall user experience. The change replaces 'an unique' with 'a unique' in the 'Pending Message'.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update removes a redundant view used in appointment scheduling that was causing crashes in certain Odoo modules. The change prevents Odoo from incorrectly attempting to use this view, ensuring stability and proper functionality for all appointment-related features. This resolves a technical issue that could impact users.
Original PR description
Remove the extra pos_list view used for calendar_event_list by the pos because Odoo would try to use it by default to all calendar_event_list views and that would cause it to crash for modules which didn't have the view initialized Runbot Error:[234475](https://runbot.odoo.com/odoo/runbot.build.error/234475)
This update resolves an issue where clicking 'Details' on completed signed documents resulted in an error. The fix ensures the correct sign request record is retrieved, allowing users to now seamlessly view the details of signed documents and maintain workflow efficiency.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Open a template that has at least one completed signed request. - Click the Signed Document state button. - See all documents - Click on the detail button Before: - Clicking the Details button on a completed signed document caused a traceback. - This happened because the view was using the record ID from this.props.record.context, which referred to the sign template instead of the sign request, causing incorrect data to be fetched. After: - Use this.props.record.evalContext to retrieve the correct sign request record ID, with this.props.record.context as a fallback. Impact: - Users can now view signed document details without errors, improving workflow continuity and overall usability. task-5253632 Forward-Port-Of: odoo/enterprise#99221
This update addresses inconsistent focus states on buttons, particularly in dark mode, making them easier to see and use. The change standardizes the focus style across the Enterprise module, enhancing user experience and accessibility. This resolves a usability issue reported by users.
Original PR description
The focus states on buttons are inconsistent and sometimes hard to see (eg. darkmode secondary buttons). This PR defines the `focus-ring-*` variables to make the focus state use `o-component-active-border` everywhere. [task-4878272](https://www.odoo.com/web#id=4878272&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Community PR: https://github.com/odoo/odoo/pull/235780
This update fixes a reporting issue where the partner filter in the Partner Ledger report wasn't consistently displaying all transactions related to a partner. The fix ensures that both invoices and related operations (like misc entries) are visible when using the filter, improving reporting accuracy and data visibility.
Original PR description
To reproduce: - create an invoice for partner Bernard Gagnant (very important) - reconcile that invoice with a misc operation ; make sure not to set any partner on the receivable line of that entry - Open the Partner Ledger: both the invoice and misc operation appear under "Bernard Gagnant". This is due to a hack in that report and is the intended behavior - Use the partner filter, on top of the report, to only display partner "Bernard Gagnant" ====> The misc operation does not appear anymore. After this fix, if the filter is applied, we will be able to see both the invoice and the misc operation under the partner. task-5150419 Forward-Port-Of: odoo/enterprise#97528
This update fixes a misleading warning that appeared when renewing subscriptions in version 19.0. The change prevents the system from flagging renewal quotes as duplicates, ensuring a smoother process for users. This improves the user experience and avoids unnecessary notifications.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Renew the subscription to generate a renewal quote (state '2_renewal'). Issue: A duplicate order warning is displayed when renewing a subscription Solution: Exclude renewal quotes (`subscription_state == '2_renewal'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening renewal quotes. taskid-5258963 Forward-Port-Of: odoo/enterprise#99344
This update adds logging to the automated reconciliation process, making it easier to identify and resolve issues when it runs in user environments. Previously, debugging was difficult, but these new loggers provide greater visibility into the process's execution. This improves reliability and reduces troubleshooting time.
Original PR description
For the moment, it's difficult to debug in users databases in the cron and the try auto reconcile. This commit will add some loggers to be more aware of what's going on. task-5358849 Forward-Port-Of: odoo/enterprise#101003 Forward-Port-Of: odoo/enterprise#100601
A bug causing internal server errors when printing audit reports has been resolved. The update ensures the correct PDF export function is used for this specific report type, improving the reliability of the annual report generation process. This prevents errors and ensures accurate report output.
Original PR description
Steps to reproduce: - Go to "Accounting/Review/Audit/Annual Report" and create an Audit Report. - click "Print" -> Internal Server Error This happens when generating the Journal Audit pdf, this report needs to uses the `export_to_pdf` that is defined in its custom handler `account.journal.report.handler`. The solution is to use `dispatch_report_action`, as it will determine which function to use in order to export the pdf for each report. no-task Forward-Port-Of: odoo/enterprise#100949
This update removes outdated configurations that forced specific start dates for reports. Now, users can easily set the correct start date through the standard form view, simplifying the reporting process. This change improves usability and ensures accurate reporting data.
Original PR description
These overrides are useless now that the user can access the return type form view and configure himself the start_date. Overriding _get_start_date_elements should be avoided as much as possible as this is making the field on the form view useless if set. Forward-Port-Of: odoo/enterprise#100728
28 changes
Enhancements to existing features
This update ensures that invoices for B2G transactions in Germany comply with local regulations. It adds a mandatory 'Leitweg-ID' to the UBL invoice format, correctly directing invoices to the appropriate government entity. This improves compliance and accuracy for German accounting processes.
Original PR description
*= l10n_account_edi_ubl_cii_tests For B2G transactions in Germany, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. Adding this Leitweg-ID for the UBL syntax. task-5194484 Description of the issue/feature this PR addresses: For electronic invoicing in Germany, for B2G transactions, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. We want to add this identifier for the XRechnung format. Current behavior before PR: The Leitweg-ID is not present in the UBL xml format. Desired behavior after PR is merged: The Leitweg-ID is added in the header of the invoice in the cbc:BuyerReference tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238255 Forward-Port-Of: odoo/odoo#236333
This update replaces the specific "Uruware" name in the Odoo settings with a generic "UCFE Provider" label for the electronic invoicing provider. This ensures customers contact Odoo support for assistance and maintains a consistent configuration for Uruguayan users. The core functionality remains unchanged.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539 Forward-Port-Of: odoo/enterprise#101053 Forward-Port-Of: odoo/enterprise#99065
This update enhances the Odoo call menu by adding mute and deafen controls, improving the user experience for calls. The visual design of the call menu has also been updated for a cleaner and more modern look. This change provides a more intuitive and effective way to manage calls within Odoo.
Original PR description
Currently, there is no way that we can deafen or mute in call menu directly. This commit adds mute and deafen button in call menu for better user experience. Also, adjust the call menu UI for better visual effect. task-5262772 before: <img width="260" height="51" alt="image" src="https://github.com/user-attachments/assets/206b3b3d-cafa-492f-95ed-db8075f16298" /> after:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key partner data changes. A new feature has been added specifically for Belgium, leveraging the VAT number to automatically populate the Peppol identifier through the company registry endpoint, streamlining data entry and validation.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378 Forward-Port-Of: odoo/odoo#238251 Forward-Port-Of: odoo/odoo#233160
Resolved issues and error corrections
This update resolves an issue where the partner filter in the Partner Ledger report incorrectly removed reconciliation entries. The fix ensures that both invoices and related operations (like misc operations) are visible when using the filter, providing a more complete view of partner transactions. This improves reporting accuracy and usability.
Original PR description
To reproduce: - create an invoice for partner Bernard Gagnant (very important) - reconcile that invoice with a misc operation ; make sure not to set any partner on the receivable line of that entry - Open the Partner Ledger: both the invoice and misc operation appear under "Bernard Gagnant". This is due to a hack in that report and is the intended behavior - Use the partner filter, on top of the report, to only display partner "Bernard Gagnant" ====> The misc operation does not appear anymore. After this fix, if the filter is applied, we will be able to see both the invoice and the misc operation under the partner. task-5150419
This update resolves an issue where duplicate account IDs were causing data overwrites. The changes now correctly segregate accounts for CPF, SHG, and SDL tax calculations according to Singapore's latest tax regulations. The fix also simplifies account code formatting to prevent excessively long account numbers.
Original PR description
Two accounts were using the same XML ID `account_account_864`, causing second definition to overwrite the first. This commit resolves the duplication and updates/segregates accounts for CPF and SHG according to new specifications.
Changes:
- Update `account_account_864` (Employee Expense) to `account_account_866`.
- Update in accounts:
* 862 → CPF Withheld (Employee)
* 863 → CPF Accrued (Employer)
* 864 → SHG Withheld (Employee)
* Add new 865 → SDL Accrued (Employer)
* 859 → CPF Employer Expense
* 860 → SDL Employer Expense
* Removed 861
- Fix `transfer_account_code_prefix` in the template:
* Change from `101100` to `10110` to avoid generating 7-digit account codes.
task-5360160
Forward-Port-Of: odoo/odoo#238264
Forward-Port-Of: odoo/odoo#237506A minor typo in the SEPA Direct Debit payment provider configuration message has been corrected. This ensures consistent and accurate communication with the payment provider, improving data integrity. The change updates a grammatical error regarding the use of 'an' versus 'a'.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update enhances the reliability of our point-of-sale (POS) certification process by automatically retrying failed payments due to server unavailability. Specifically, it addresses errors from the FISKAL system (TSS) and ensures tills remain operational even when the system is temporarily unreachable, improving transaction success rates.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693 Forward-Port-Of: odoo/enterprise#100911 Forward-Port-Of: odoo/enterprise#93694
This update fixes an issue where Odoo incorrectly processed attachment file types, leading to potential errors. The changes ensure attachments are handled correctly, particularly with binary files, and streamline the attachment creation process for better efficiency.
This update resolves an issue where unnecessary data was being passed to the AI agent's data processing. The system now correctly handles data encoding and checksum calculations, ensuring more reliable AI agent functionality. This change improves the stability and performance of the AI features.
Original PR description
The cron is encoding the `content` to compute its checksum already. Also don't set `index_content`, as far as I can tell it's unconditionally computed by `ir.attachment` on both create and write (via `_set_attachment_data` in the latter case).
This update fixes an issue where Argentinian invoices weren't correctly displaying taxes in the company's local currency, even when the setting was enabled. The previous code was unintentionally removing the tax section. This change ensures invoices accurately reflect tax amounts in the appropriate currency, improving financial reporting for Argentinian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Switch to a Argentinian company (e.g. (AR) Responsable Inscripto) - In Accounting settings, enable "Taxes in company currency" option - Activate another currency (e.g. USD) - Create an invoice in USD - Confirm the invoice - Print the invoice **Issue:** The section showing the taxes in the company currency doesn't appear on the invoice despite the enabled option. Cause: An override of "report_invoice_document" from l10n_are is removing the section no matter what the configuration. **Solution:** Do not remove the section. It was done originally in 17.0 where "Taxes in company currency" option didn't exist. opw-5351010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238204
This update resolves an issue preventing portal users (subcontractors) from accessing picking details within subcontracted manufacturing orders. The fix uses `sudo()` to grant necessary read access to the required models, ensuring a smooth user experience. This improves the functionality for portal users managing subcontracted inventory.
Original PR description
Issue Before This Commit: ======================= When a subcontractor (portal user) tries to open a picking from the Manufacturing orders section in the portal view, the page appears blank with no…
Issue Before This Commit: ======================= When a subcontractor (portal user) tries to open a picking from the Manufacturing orders section in the portal view, the page appears blank with no data loaded on the frontend, while in the the backend logs show read Access Error is raised on the `product.supplierinfo` and on `product.template.attribute.value` models. Steps to Reproduce: ======================= -Install `MRP` and `Purchase` modules, and enable Subcontracting. -Create a product attribute with values and `variant creation` set to `Never`. -Create a product and Assign the created attribute to the product’s attributes. -Create a portal user and grant portal access. -Create a BOM for the product, set it for subcontracting, and assign the portal user as a subcontractor. -Create a Purchase Order for a subcontracted product linked to that vendor. -Log in to the portal view as the portal user and open Manufacturing Orders. -Try to open the related picking and the page fails to load and appears blank. Cause of the issue: ======================= In this [PR](https://github.com/odoo/odoo/pull/177390), The `_compute_description_picking` method was extended to include vendor product code and product name using the `selected_seller_id` field, and the product attribute values using the `product_no_variant_attribute_value_ids` field. Since `selected_seller_id` points to `product.supplierinfo` model and `product_no_variant_attribute_value_ids` points to `product.template.attribute.value` model, `group_portal` do not have read access to these models causing access errors when the picking description is computed, so the page appears blank while opening the picking. After This Commit: ======================= The `_compute_description_picking` method now uses `sudo()` to safely access `selected_seller_id` and `product_no_variant_attribute_value_ids` fields, allowing portal users to compute stock move descriptions without encountering access errors. This prevents the page from appearing blank when opening picking in the portal without granting direct model access. Task-4958070 Forward-Port-Of: odoo/odoo#225519
This update resolves an issue where clicking 'Details' on completed signed documents caused errors. The fix ensures the correct sign request record is retrieved, allowing users to now properly view and access the details of signed documents, improving workflow efficiency.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Open a template that has at least one completed signed request. - Click the Signed Document state button. - See all documents - Click on the detail button Before: - Clicking the Details button on a completed signed document caused a traceback. - This happened because the view was using the record ID from this.props.record.context, which referred to the sign template instead of the sign request, causing incorrect data to be fetched. After: - Use this.props.record.evalContext to retrieve the correct sign request record ID, with this.props.record.context as a fallback. Impact: - Users can now view signed document details without errors, improving workflow continuity and overall usability. task-5253632 Forward-Port-Of: odoo/enterprise#99221
This update fixes an error that prevented payroll officers from accessing salary offer details. The issue stemmed from the module attempting to access candidate records, which required recruitment rights. The fix ensures payroll officers can now open and manage offers without needing these additional permissions.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712 Forward-Port-Of: odoo/enterprise#100980 Forward-Port-Of: odoo/enterprise#95869
A technical error causing a traceback during salary package offer generation has been resolved. This issue occurred when a specific benefit type (Always Selected) was configured, leading to a data processing error. This update ensures the offer generation process functions correctly for all benefit configurations.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update removes a confusing step in the Finance actions process, streamlining how documents are created and linked. Previously, actions first moved documents to the Taxes folder before creating records, leading to unnecessary complexity. This change improves the user experience and clarifies the action workflow.
Original PR description
Issue: The embedded actions of the Finance folder are multi-step actions that first do a move to the Taxes folder, before creating relevant records linked to the action. The move to the Taxes folder is unnecessary and confusing. It adds to the confusion that when synchronisation is activated for a journal, the record will immediately be moved to the synced folder after triggering the action. The result is that the document ends up in the right place, but the action definition is confusing. When there is no synchronisation activated for a journal, the document will be moved to the Taxes folder. But this does not make any functional sense. Cause: Multi-action step moves it towards the Taxes folder before creating the relevant record. Solution: Remove the move step of the multi-action. In a later commit an IMP will be made to clean up the actions. Task-5380590
This update resolves a bug preventing the 'Reviewed' button from appearing correctly in certain accounting scenarios. Additionally, a security enhancement has been added to disable secondary buttons during statement reconciliation, improving data accuracy. This ensures the 'Reviewed' button is always visible when appropriate.
Original PR description
Before this commit, we called the wrong variable to know whether the "Reviewed" button is available or not. It leads to have a no show of this button even when it was needed. This commit also adds a small security check to remove the secondary buttons when the statement is reconciled. no task id
This update relaxes a constraint on stock pickings, enabling users to schedule pickings with dates that fall outside the company's fiscal year lock date. Previously, this restriction caused issues with certain pickings. This change improves flexibility without impacting core accounting functionality.
Original PR description
### Issue: The `_check_backdate_allowed` constraint on `scheduled_date` and `date_done` of pickings: https://github.com/odoo/odoo/blob/5375b865570efb714720096c34aeec2e833dd1f9/addons/stock_account/models/stock_picking.py#L13-L19 is suppose to check if these dates happen prior to the `fiscal_year` lock date and (of course) before the hard lock date. However, the `_get_lock_date_violations` set all its parameters to `True` by default: https://github.com/odoo/odoo/blob/5375b865570efb714720096c34aeec2e833dd1f9/addons/account/models/company.py#L664-L673 and only the fiscalyear variable is set in the constraint calls: https://github.com/odoo/odoo/blob/5375b865570efb714720096c34aeec2e833dd1f9/addons/stock_account/models/stock_picking.py#L27-L32 opw-5329858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where attendance was incorrectly flagged as overtime when employees worked on the same day as a company holiday. The change ensures that only holidays specific to the current company are considered when calculating overtime, preventing inaccurate calculations and improving payroll accuracy.
Original PR description
A bug was found that set attendances as overtime when done in the same day another company had a public holiday with no working schedule set. This fix adds the current company to the filter of _get_unusal_days to get only public holidays of the current company. task-5347555 ## To do - [x] Add tests
This update resolves an issue where printing receipts with reward lines and multiple order lines would cause the printer to block. The fix reorders the lines to correctly apply discounts, preventing the error related to the last line's discount amount. This ensures receipts print reliably with reward items.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale Forward-Port-Of: odoo/enterprise#98699
This update fixes a minor visual issue in the event creation modal by increasing its width. Previously, a scrollbar would appear when focusing on the editable area. This change ensures a smoother user experience and prevents unnecessary scrollbars.
Original PR description
**Current behavior before PR:** - The new event modal was reduced in width, causing the placeholder to have insufficient space. When focusing the editable area, this resulted in an unnecessary scrollbar. **Desired behavior after PR is merged:** - The width of the event creation modal has been increased, preventing the scrollbar from appearing when the cursor is inside the editable area. task-5207448
This update enhances the HTML editor's powerbox functionality by adding the 'title' keyword. Now, users can easily create and display headings (H1-H3) within the powerbox using the '/title' command. This improves content formatting and organization.
Original PR description
#### Desired behavior after PR is merged: - `title` is added to the list of keywords in `powerbox_items`, allowing `/title` to display the `heading (H1–H3)` commands in the powerbox. task-5367576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue preventing completion notifications in the MRP Work Order module from being translated into different languages. The previous code placement blocked the translation process. This ensures that users receive notifications in their preferred language, improving the overall user experience.
Original PR description
The `_t()` was put around the wrong thing, making the strings never translatable. Followup to: 4403621 Forward-Port-Of: odoo/enterprise#101119
This update fixes a bug that caused payment transactions to remain in an 'error' state after processing with Razorpay. The fix prevents the system from skipping necessary updates during error handling, ensuring transactions complete correctly. This improves payment processing reliability.
Original PR description
Steps: - Install razorpay provider. - Set up provider and try to make payment with UPI PM. - Cancel processing payment in Razorpay form while processing keep form open. - Now complete that same tx in same Razorpay form. Issue: - Transaction stays in `error` state. Cause: - _process method skips calling _apply_changes for `error` stage transactions even though it should allowed. Fix: - Improve condition to only skip `_apply_changes` only if `_validate_amount` fails. issued PR: https://github.com/odoo/odoo/pull/224627 Note: This is just temporary fix for the stable in master we will make `_validate_amount` method return boolean value depending on that we will decide whether to apply changes or not.
This update resolves an issue where PayPal payments were failing when required shipping address fields were left blank. The fix adds a default value to these fields, ensuring PayPal transactions can proceed smoothly. This improves the reliability of our payment processing.
Original PR description
Paypal was failing when the address fields were `False` **Solution:** Add a fallback to missing fields in the shipping address Fixes: https://github.com/odoo/odoo/issues/237360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238340
This update fixes a bug where reverse charge tax amounts were incorrectly recorded as debits on invoices created with down payments from sales orders. The change ensures that reverse charge tax amounts are correctly reflected as credits, aligning with accounting regulations and improving invoice accuracy. This resolves an issue reported in opw-5172402.
Original PR description
When creating an invoice with down payment from a sales order, the reverse charge tax amount goes into the debit side. Make sure the reverse charge tax amount goes into the credit side. opw-5172402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237557
This update fixes a visual issue where buttons within the image field were not vertically centered. The change uses SCSS flexbox to reliably center the buttons, ensuring a consistent and professional appearance. This improvement simplifies maintenance and accommodates potential future customizations to the image field.
Original PR description
The buttons in image_field are not centered vertically. Since it's a custom sized button, using flex is reliable (it's now centered on both flex axis). Note: Done in SCSS instead of utilities because the flex is there to compensate the custom size set in SCSS (easier to maintain) + there could be injected buttons in the component. task-5258887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235964
This update corrects a bug where pressing arrow keys while the table picker was open caused incorrect navigation within tables. Now, arrow keys only control the table picker itself, preventing unintended cell selection. This improves the user experience when working with tables in the Odoo interface.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When the table picker was open inside a table, pressing the up/down arrow keys incorrectly moved the selection to the cell above or below. Desired behavior after PR is merged: While the table picker is open, arrow up/down no longer navigate between table cells. task-5349547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236886
8 changes
Enhancements to existing features
This update enhances the system's ability to access information related to signed documents (o2m relationships). Previously, limitations prevented developers from leveraging these relationships, now they can be customized, allowing for more comprehensive sign management. This improves the flexibility and functionality of our sign workflows.
Original PR description
The class `SignerX2Many` is inheritable, but if we need another value from the o2m, we can't use it because the `signerX2Many` is not exportable. Enable `signerX2Many` customization, allowing more fields to be read from the `sign.send.request.signer` model.
Resolved issues and error corrections
A minor typo in the SEPA Direct Debit payment provider configuration has been fixed. The message displayed to users now uses the correct grammatical form ('a unique' instead of 'an unique'), ensuring consistent and professional communication. This change improves the overall user experience.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update resolves an issue where the timesheet grid incorrectly displayed unavailable days when flexible hours were enabled for a company. The fix ensures that all days are treated as working days when flexible hours are in use, eliminating the random greyed-out weekdays. This improves accuracy and usability for companies utilizing flexible scheduling.
Original PR description
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days…
**Description** When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent. **Steps to reproduce** 1. Enable flexible hours on company's working schedule 2. Go to Timesheets > All timesheets 3. Switch to Grid view and filter by month 4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out **Fix** The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days. This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths: 1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback 2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found This follows the same pattern as the gantt view fix #100385 opw-5215646
This change adjusts Odoo's VAT processing to accommodate a wider range of testing VAT codes provided by our EDI partner. Previously, we only supported specific VATs, but now our partner offers a more comprehensive testing range. This update ensures seamless integration with the EDI system, improving data accuracy for VAT calculations.
Original PR description
When we merged EDI for Guatemala we allowed two specific testing VATs [1]. Because our EDI is proving popular our EDI provider has now created a specific range of testing VATs just for Odoo. We allow them explicitly because they're not valid VATs. [1] 6ef9c1085cd648ad2bbd78caf4a83fe30c969d59 opw-5381791
This update fixes an issue where buttons within the image field were not vertically centered. The change uses SCSS flexbox to reliably center the buttons, ensuring a consistent and professional appearance. This was implemented in SCSS for easier maintenance and to accommodate potential variations in the component's design.
Original PR description
The buttons in image_field are not centered vertically. Since it's a custom sized button, using flex is reliable (it's now centered on both flex axis). Note: Done in SCSS instead of utilities because the flex is there to compensate the custom size set in SCSS (easier to maintain) + there could be injected buttons in the component. task-5258887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235964
This update resolves an issue where users were unable to set invalid data types (like numbers) as default values for fields within customer records. The fix ensures that users cannot enter incorrect data, maintaining data integrity and preventing potential errors in reporting and business processes. This improves data reliability.
Original PR description
Steps:
- Create a user defined defaults value
- Model: res.partner
- Field: date
- Value: 1
- Create a new contact
Actual result:
- invalid field type
- 'int' object is not subscriptable (depends of field type)
Expected result:
- No error
- User is not able to put an invalid value as a default
task-3729963
Forward-Port-Of: odoo/odoo#225991This fix resolves an issue where reordering rules could incorrectly update locked manufacturing orders after a quality check was performed. Previously, the system would attempt to add new quantities to these locked orders, causing an error. This update ensures that reordering rules only update quantities when the manufacturing order is not locked, improving order management accuracy.
Original PR description
## Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an…
## Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ## Steps to reproduce: - Create a product tracked by quantity - Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point) - Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1) - Click on Order - Open the created MO and the Shop Floor (Remove the filters to see the WO) - Complete the Quality Point - Modify the Reordering Rule (Min/Max: 2) - Click on Order - the error should be raised ## Cause: The MO to update is retrieved here: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153 In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561 However, it could still theoretically be triggered under specific conditions In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created opw-5012588 Odoo: https://github.com/odoo/odoo/pull/238537
This update resolves an issue where the Odoo application remained listed as installed after uninstalling on Windows. The fix ensures the uninstaller correctly removes the necessary registry keys, preventing persistent entries in the installed software list. This improves the user experience and simplifies application management.
Original PR description
Since d0d0fa2b8e the Windows installer only supports 64 bit version of the OS. It was recently noticed that when uninstalling the app with the provided uninstaller that the app remains listed in the installed software. Although the directories and third party apps were correctly cleaned and removed. The reason is that the Odoo app registry key is still present after the uninstall process. When a 32 bit process tries to write a registry key in `HKLM\SOFTWARE` it's redirected by the OS to `HKLM\SOFTWARE\WOW6432Node`. By using the `SetRegView 64` NSIS directive, the installer writes the registry key at the right place ... but the uninstaller is lacking that directive and thus tries to remove a non existing key in `HKLM\SOFTWARE\WOW6432Node`. With this commit, the uninstaller is fixed by using the directive too. Forward-Port-Of: odoo/odoo#238476
7 changes
Enhancements to existing features
This update improves database storage efficiency by converting certain indexes to a more space-saving format (`btree_not_null`). This change primarily focuses on reducing the amount of disk space used by the Odoo database, without impacting core functionality. It's an internal optimization.
Original PR description
## Description Update indexes that have a large `null_frac` (the % of NULL value in the column) into `btree_not_null` to save some disk space. Fields who had lookups based on their `False` value weren't converted, unless it's a model we use often and its `null_frac` was `>0.4` which is often the threshold when Postgres will estimate doing a `Seq.Scan` instead. Fields that had no lookup at all on them, the index was removed. ## Reference task-3875080
Resolved issues and error corrections
This update fixes a minor issue where an unwanted error dialog appeared in the background during Razorpay payments. The fix removes redundant code that triggered the dialog, ensuring a smoother payment experience for users. This improves the overall user interface and prevents unnecessary distractions.
Original PR description
Steps: - Install and setup razorpay provider. - Create a SO and try to pay SO with UPI PM. - Cancel payment in between. Issue: - Error dialog in background appear even Razorpay form is still open. Cause: - We were opening Error dialog on `payment.failed` notification. Fix: - Remove Error dialog related code on `payment.failed` notification as it is already handled in `_initiatePaymentFlow` method.
This update fixes an issue where loyalty discounts weren't accurately applying based on product quantity. The change ensures discounts are calculated correctly, preventing over-discounts and maintaining accurate order totals. This improves the reliability of loyalty program promotions.
Original PR description
Discounts based on the cheapest line were not accounting for the quantity on the line and this was causing issues with the computations when using a maximum discount amount. Changing the discountable value to be a ratio of the quantity on the line allows the cheapest product to be discounted at the correct amount without messing with the discount factor. opw-4998557
This update adds crucial database indexes to the WhatsApp module, enhancing its speed and efficiency. These indexes optimize how the system searches for WhatsApp messages and channels, leading to faster response times and a smoother user experience. This change addresses a performance bottleneck and ensures the WhatsApp feature remains reliable.
Original PR description
Missing indexes: - `whatsapp.message.wa_template_id` - hits domain given by `action_open_messages` and in `_compute_messages_count`. - `whatsapp.message.mobile_number_formatted` - used in `_find_active_channel`, it's more selective than `wa_account_id`. - `discuss.channel.whatsapp_number` - used in `_get_whatsapp_channel` when there is no `related_message` provided
This update improves database storage efficiency by changing certain index types to `btree_not_null`. This change reduces disk space usage, primarily impacting performance and storage costs. It ensures Odoo utilizes the most effective index structure for data retrieval.
Original PR description
## Description Update indexes that have a large `null_frac` (the % of NULL value in the column) into `btree_not_null` to save some disk space. Fields who had lookups based on their `False` value weren't converted, unless it's a model we use often and its `null_frac` was `>0.4` which is often the threshold when Postgres will estimate doing a `Seq.Scan` instead. ## Reference task-3875080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the vehicle availability calculations for the payroll and fleet modules. It now accurately excludes vehicles flagged for change (plan_to_change_car or plan_to_change_bike) with a 'False' status, ensuring they are correctly marked as unavailable. This prevents incorrect vehicle availability reporting.
Original PR description
Refine _get_available_vehicles_domain to consider only vehicles with plan_to_change_car or plan_to_change_bike set to True as available. This ensures vehicles planned for change but marked False are treated as unavailable. Related task: 4963484. Forward-Port-Of: odoo/enterprise#90812
This update resolves an issue where the Odoo application remained listed as installed after uninstalling on Windows. The fix ensures the uninstaller correctly removes the necessary registry keys, preventing persistent installations and improving the user experience. This improves the reliability of the uninstallation process.
Original PR description
Since d0d0fa2b8e the Windows installer only supports 64 bit version of the OS. It was recently noticed that when uninstalling the app with the provided uninstaller that the app remains listed in the installed software. Although the directories and third party apps were correctly cleaned and removed. The reason is that the Odoo app registry key is still present after the uninstall process. When a 32 bit process tries to write a registry key in `HKLM\SOFTWARE` it's redirected by the OS to `HKLM\SOFTWARE\WOW6432Node`. By using the `SetRegView 64` NSIS directive, the installer writes the registry key at the right place ... but the uninstaller is lacking that directive and thus tries to remove a non existing key in `HKLM\SOFTWARE\WOW6432Node`. With this commit, the uninstaller is fixed by using the directive too. Forward-Port-Of: odoo/odoo#238476