Wednesday, April 16, 2025
8 changes · 18.0
Resolved issues and error corrections
Users can now duplicate several payment terms at once from the Invoicing list view without triggering an error. This keeps bulk setup and maintenance of payment terms working smoothly.
Original PR description
Currently, an error occurs when a user tries to duplicate more than one payment term at once from the list view. **Steps to produce:** - Install the `account` module. - Navigate to `Invoicing > Payment Terms` (list view). - Select at least two records and duplicate them. - Observe the error. `ValueError - Expected singleton: account.payment.term(3, 4, 5, 6, 7, 8, 9, 10)` An error occurs because the **copy** method accesses `self.name`, assuming a single record, when multiple records are duplicated, causing the `ValueError`. [1] - https://github.com/odoo/odoo/blob/6b970a0bfbcdac92d05389aac994c0db36730a34/addons/account/models/account_payment_term.py#L270 This commit ensures that each duplicated payment term has its name individually updated after being copied. Sentry - 6531350963
The payment provider test setup was adjusted so Worldline and AsiaPay no longer depend on accounting-only test data. This prevents failures when testing community-only installations where the accounting app is not installed.
Original PR description
It doesn't seem to be of any use, and neither module depends on account. It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve. If you only have community tho, it blows up in your face. Which I guess is what happens in the single app tests. https://runbot.odoo.com/odoo/error/163117
Unarchiving a company now correctly refreshes the related company access information for users. This prevents errors when users try to open accounting records, such as charts of accounts, after a company has been restored.
Original PR description
Issue: When a company is unarchived, the cache for some fields are not updated. Steps to reproduce: - create company b - archive company b - access CoA - unarchive company b - try to access specific chart of account, error will be raised Purpose of this PR: when we unarchive a company we call the `_get_company_ids` method on the user to update the cache. opw-4427576
This fix adjusts payment-related tests so they only run checks when the optional supporting apps they rely on are installed. It helps avoid false test failures and keeps development and release validation smoother without changing customer-facing payment behavior.
Original PR description
`payment` does not depend on `account`, it thus can't unconditionally use `account` groups. Skip tests if `account` is not installed (matches `account_custom` behaviour). `account_custom` does not depend on `product`, so can't use `product.product` unconditionally. `setUpClass` doesn't seem useful so just remove it entirely.
Peppol demo mode has been adjusted to behave more like the production service. This helps teams test electronic invoicing scenarios with more realistic results before using Peppol in live operations.
Original PR description
… behavior Fix the demo mode of Peppol to be closer to the behavior in production. task-no (review with TSB/PMAX 31/03/25)
Users now get a clearer warning when they try to create a bank account that already exists but was archived. This avoids a confusing uniqueness error and updates activity history wording from deleted to archived, matching what actually happens.
Original PR description
Commit ebb09234e6444576e7e934f53de1d23a0d9760d2 made it so that bank account are archived instead of deleted meaning that they are never deleted in the DB. If a user tries to create a new bank account for the same partner with the same account number, the following validation error is raised: "The operation cannot be completed: The combination Account Number/Partner must be unique." This commit introduces a new UserError when a user attempts to create an account that was previously archived. It also updates the message in the chatter from "deleted" to "archived." opw-4669340 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clearing the description from a section line on an invoice no longer causes an error. This prevents interruptions while editing invoices and keeps the invoicing workflow stable.
Original PR description
This error occurs when a user `adds a section` in an `invoice line`, enters a description, and then remove the description. Step to reproduce : - Install module `Invoicing`. - Create a `new Invoice`. - In the Invoice Line, `add a section`. - Enter a description and save. - Remove the description and click anywhere on the screen. KeyError: `name` This error occurs when the system tries to update an invoice line section but the `name` field is missing from the update values, causing a KeyError. This commit fixes the issue by using optional chaining and nullish coalescing to ensure productName returns an empty string instead of undefined. Sentry - 6327760196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes test setup problems in the Sales Manufacturing area by avoiding attempts to fill fields that are hidden in certain scenarios. It helps keep automated checks reliable as test coverage expands across all modules, reducing noise from false failures.
Original PR description
Revealed by the changes to single app tests (which now test every module). While at it, remove a few unnecessary setting of product-id on non-variant scenarios, they don't blow up but they look a lot like odoo/odoo#206050 and why bother? https://runbot.odoo.com/odoo/error/163244