Wednesday, December 3, 2025
30 changes · saas-18.4
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
This update fixes a usability issue where replying to messages with only attachments didn't clearly show the original message being responded to. Now, users will always see the context of the message they're replying to, regardless of whether they include text or attachments, leading to a smoother and more intuitive communication experience.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent message context is not displayed. This makes it unclear which message the user is replying to when they only attach files without typing any text. **Current behavior before PR:** ---------------------------------------------- - Reply messages with only attachments do not show the parent message context - Users cannot see what message they are replying to when only attaching files - The MessageInReply component is not rendered for attachment-only replies **Desired behavior after PR is merged:** ---------------------------------------------- - Reply messages with only attachments now display the parent message context - Users can clearly see what message they are replying to, even with only attachments - The MessageInReply component renders consistently for all reply types - Visual structure maintains proper Odoo message styling - Better user experience with clear reply context Task-5109159 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238066 Forward-Port-Of: odoo/odoo#230574
This update resolves an issue where users couldn't access subchannels within group chats without being explicitly invited. The fix automatically creates channel membership for subchannels when a user has write access to the parent group chat, ensuring seamless access to all subchannels.
Original PR description
Before this commit, typing in a subchannel of a group DM of which you are not member of would result in an access error. Steps to reproduce: 1. Log in as user A 2. Create group chat with user B 3. Create a subchannel in said group 4. Log in as user B 5. Open the subchannel in the group chat 6. Write in the composer -> access error This is caused by incomplete access rules for the `discuss.channel.member` model. Specifically the issue stems from the fact that a subchannel of a group channel is considered a group, and as such it's only possible to join it via invitation. Since typing in a channel attempts to join it, an access error is raised. This commit fixes the issue by executing the creation of a channel member for subchannels as superuser, on the condition of having write access to the parent channel. task-5357621 Forward-Port-Of: odoo/odoo#237611
This update resolves an issue where Sale Orders with lot-tracked products were incorrectly duplicated when imported into POS. The fix prevents unnecessary line splitting during import, ensuring accurate order processing and avoiding data inconsistencies. This improves the reliability of the POS system when handling lot-based inventory.
Original PR description
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the…
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the `settleSO` function, the line is first split because the UoM differs and is not `pos_groupable` Among the default UoMs, only Units, Pack of 6, and Dozen have `is_pos_groupable` = True, meaning most other UoMs will trigger a line split After duplicating the line due to the UoM split, an additional line is then added for each lot to link, causing duplicate entries in the POS order ## Steps to reproduce: - In Settings, enable Lots & Serial Numbers and Units of Measure & Packagings - Create a Product (Tracking: Lot, Sale Unit: g) - Update the Quantity On Hand (Lot: "LOT", Quantity: 5) - Create and confirm a Sale Order for the product (Quantity: 2) - Open POS and import the SO - Before the fix, there is 3 lines (2x no lots, 1x with lot + qty 2 ## Other issues: - The discount was not imported on the lot lines - Some lines were missing when importing lines where part of the quantity had no available lot - (This fix was already made in PR: https://github.com/odoo/odoo/pull/229075/files but was not forward-ported) opw-5018295 Forward-Port-Of: odoo/odoo#238237 Forward-Port-Of: odoo/odoo#234165
This update fixes an issue where payslips generated from payruns were named 'new payslip' instead of including the employee's name and pay period. Now, PDF payslips will correctly display 'Salary Slip - <employee name> - <time period>', ensuring accurate and professional payroll documentation. This improves the clarity and usability of payroll reports.
Original PR description
[FIX] hr_payroll: write full name on payslip generated from payrun _ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip…
[FIX] hr_payroll: write full name on payslip generated from payrun _ ## Short functional explanation of the error When generating a payslip from a payrun for an employee, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>" ## Reproduction Steps 1. Go to Payroll and click on the Payslips tab > payslips. 2. Click on Pay Run. Select Regular Pay and click Continue. 3. Select an employee for which you'd like to generate the payslip. 4. Click on the employee row in the list view. 5. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - <employee name> - <time period>" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5216796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where an IoT printer was still loaded when both an IoT and ePos printer were set up. Now, the system automatically prioritizes the ePos printer, ensuring the correct printer is used as intended. This improves the user experience and prevents errors.
Original PR description
When setting an IoT printer and an ePos printer, a message is displayed to inform the user the ePos printer will be used. However, this is not the case and the IoT printer is still loaded. We now avoid loading if there already is a printer.
This update corrects a bug that caused inconsistent start dates for financial returns due to reliance on the current date. The fix ensures returns are generated with the correct fiscal year start date, regardless of the current date. This improves the accuracy of financial reporting across Belgium, New Zealand, and the UK.
Original PR description
compute_fiscalyear_dates using date.today() is wrong and can lead to different start_dates depending the current date. For instance if we create a custom fiscal_year from sept 2025 to Dec 2025 and we are currently the 10th Sept 2025. Then, we try to generate a return for January. The start date would be set to the 1st Sept. Then later, when trying to generate the same return for January 2025 but being after that custom fiscal year (for instance 20th January 2026), We get a completely different start date. The fix is to avoid using the custom fiscal years in get_start_date_elements. An improvement will be done in master to add that feature. We can also safely remove the custom start_date from the belgian localization as now it is not used anymore. See: https://github.com/odoo/enterprise/pull/100034
This update fixes an issue where the table editor incorrectly selected adjacent cells when users attempted to select all text within a cell using Shift and the arrow keys. Now, after selecting all text, only the current cell is selected, allowing for more precise editing. This improves the user experience and ensures accurate cell selection.
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
This update resolves an issue where the 'I agree' button on the website's cookie bar stopped working when its font size was adjusted. The fix corrects a technical error in how the button's click event was handled, ensuring the cookie consent process continues to function correctly across different font sizes.
Original PR description
The "I agree" button in the cookie bar would stop working if its font size was changed. Steps to reproduce: =================== - Enable the cookie bar in website settings. - Go to the website and…
The "I agree" button in the cookie bar would stop working if its font size was changed.
Steps to reproduce:
===================
- Enable the cookie bar in website settings.
- Go to the website and enter Edit mode.
- Click on the cookie bar.
- Select the "I agree" button's text and change its font size.
- Save and visit the page as a guest (e.g., in a private window).
- Click on the "I agree" button text.
-> The maps doesn't show and the Cookie bar disappear.
Cause:
======
Applying a font size to the button's text wraps that text within a `<span>` element.
The event listener for accepting cookies is attached to the elements with IDs `#cookies-consent-essential` and `#cookies-consent-all`. in that case it ID `cookies-consent-essential` exist in the parent element. However, the code was checking the ID of `event.target`. When a user clicks directly on the newly created
`<span>`, `event.target` refers to the `<span>` itself, not the element who owns the event.
Since the `<span>` does not have the required ID ('cookies-consent-all'), the condition to accept the cookies was false.
Solution:
=========
Use `event.currentTarget` instead of `event.target`.
Unlike `event.target`, `event.currentTarget` always refers to the element to which the event handler was attached—in.
check:
https://developer.mozilla.org/en-US/docs/Web/API/Event/currentTarget
opw-5004645
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238238
Forward-Port-Of: odoo/odoo#237786This update resolves a technical issue that caused inconsistent behavior when editing websites, specifically when using slower network connections. By ensuring the website editor waits for the iframe to fully load, the system now provides a more reliable and predictable editing experience for users.
Original PR description
In this commit, we fix a non deterministic behavior by ensuring the iframe is loaded before it try to open editor. runbot-232846
This update resolves an issue where commas in payment memos for EFT files were causing errors and rejections. The fix removes commas from generated files, ensuring they conform to the BNZ export format and preventing payment processing failures. This ensures accurate EFT file submissions.
Original PR description
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This…
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field. - The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124'). - The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002'). - The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124' This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields. While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220) opw-5099220 Forward-Port-Of: odoo/enterprise#100670 Forward-Port-Of: odoo/enterprise#98613
This fix resolves an issue where the website page URL input field would jitter and reset, particularly with slow connections. It also corrects a related problem where the 'Redirect Old Url' feature wasn't properly hidden after reverting changes. The update ensures a smoother and more reliable user experience when editing website pages.
Original PR description
Scenario: - edit a website page (eg: /test that you create) - go to Site > Properties - have a slow connection and write in field "Page URL" for some seconds Result: the input jitter, if going too…
Scenario: - edit a website page (eg: /test that you create) - go to Site > Properties - have a slow connection and write in field "Page URL" for some seconds Result: the input jitter, if going too fast the text can be removed to get previous version. Secondary issue: if we cancel our change and set back the original URL, the "Redirect Old Url" part is not hidden. Reason: we trigger onchange at each input event, so if we write 20 letters we will possibly still have 20 onchange that are ongoing and will set back older version of the field value. The secondary issue is because we are using a field using useInputField and FieldUrl but we are hacking it to remove the "/" prefix inside the input. So when the invisible modifier is checked, we check eg. "old_url=/test" against "url=test" that are always different. With this fix: Since the triggered onchange were only to update quicker the condition `invisible="old_url == url"`, we trigger them only if that condition will change, and debounce it to prevent the now single onchange of happening in the middle of text input. And for the secondary issue, we add and remove the / when triggering the onchange. opw-4517181 Forward-Port-Of: odoo/odoo#237610 Forward-Port-Of: odoo/odoo#200016
This update fixes a discrepancy in a payment state test related to the Accountant module. The test now correctly reflects the payment state ('not_paid') when a payment is drafted, depending on whether the Accountant module is installed or not. This ensures consistent invoice tracking.
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 Forward-Port-Of: odoo/enterprise#101089
This update corrects a technical issue where default Incoterms were incorrectly applied to bills generated by external vendors. Bills represent transactions from third-party suppliers, who may use different trade terms. This change ensures bills accurately reflect the vendor's terms, improving data accuracy and consistency.
Original PR description
Incoterms are usefull to indicates the rules and terms in sale contracts. It makes sense to add the company default on invoices, but not on bills, as those originate from another vendor than us, who can use different rules. opw-5169146 Forward-Port-Of: odoo/odoo#236709