Monday, December 16, 2024
7 changes · 18.0
Enhancements to existing features
Accounting reports can now use read-only database replicas when a report does not need temporary write operations. This helps spread system load and can improve report responsiveness without changing the report content users see.
Original PR description
api.readonly allows running the queries of an rpc call in readonly mode, on a replicate of the database, in order to better spread the load. So far, accounting reports didn't use them because, in some cases, their computation requires the creation of a temporary table. We improve that by introducing a new option key telling whether the report can run in readonly mode or not, depending on the fact such temporary table is in use or not. The value of this option key then influences which end point is called to compute the report between the regular one, or an api.readonly version of it.
Resolved issues and error corrections
Portal users can now create API keys without encountering an error after the related setting is enabled. This restores the expected self-service flow for customers who need API access.
Original PR description
Reproduce --- - tick "Customers can generate API Keys" in settings - login as portal user - Connection & Security -> New API key -> give name -> Confirm ->BUG ``` TypeError: APIKeyDescription.create() missing 1 required positional argument: 'vals_list' ``` opw-4385632
Point of Sale refunds now calculate cash rounding consistently with normal sales. This prevents valid refunds from being blocked or left unpaid when cash rounding is applied, improving checkout reliability for stores using rounding rules.
Original PR description
The tax totals helper has been designed to manage business document expressed with positive lines. A refund in the pos is negative. So when dealing with cash rounding up and down, the computation wasn't the same for a refund than a regular sale. Then, the customer wasn't able to validate the refund because the cash rounding was consider as wrong and then, the refund wasn't paid even when making the same input as a sale pos order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payments in Invoicing-only setups now remain in process instead of being automatically marked as paid when no reconciliation is required. This prevents payments from being blocked from batch payments while still allowing them to be marked paid manually or when a batch is validated.
Original PR description
Currently, a payment without outstanding is set as paid as soon as the invoice is paid, most likely through the reconciliation widget. However, the decision was made to not require the reconciliation when using the enterprise Invoicing[^1]. These two facts are conflicting with batch payments since they can be used in Invoicing, but a payment cannot be added to a batch payment if it is already paid. The fix is to always keep a payment as "in process" if the full Accounting is not installed. They will still be marked if the user sets it manually, or through the batch payment when it is validated. [runbot-104545](https://runbot.odoo.com/web#id=104545&model=runbot.build.error) [^1]: odoo/enterprise@adfe6c2d5feb431043e78c423748ab87fae64084
Exporting all records from a grouped list now shows accurate group totals. Archived records are no longer counted unless they are actually included in the export, preventing misleading spreadsheet results.
Original PR description
Before this commit, exporting all records in a grouped list view generated wrong group counts in the sheet, because archived records where taken into account (even though they weren't exported). The issue comes from [1], which we kind of revert. [1] https://github.com/odoo/odoo/pull/166097 task~4375142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users on phones and other small screens can now start new comment threads in Knowledge articles. This fixes a mobile editing issue so feedback and collaboration work consistently across devices.
Original PR description
In small UI mode (designed for smartphones and mobile devices), new comment threads could not be added (through they could be replied to). Steps to reproduce: - Access a Knowledge article in mobile UI mode - Tap and hold on a word in an article body to create a selection - Scroll the toolbar at the bottom of the screen - Click on the Comment button This commit makes it so that users of mobile devices can now add new comment threads to a Knowledge article. task-4399014
SEPA Direct Debit payments now correctly find a customer's mandate when an invoice is issued to one of that customer's invoice addresses. This prevents valid direct debit payments from being blocked simply because the mandate and bank details are stored on the main customer record.
Original PR description
**Steps to reproduce:** - Install contacts, accountant and l10n_be - Switch to a Belgian company - In Accounting settings, activate "Customer Addresses" and "SEPA Direct Debit (SDD)" - Create a contact: * Country: Belgium * Bank Account: [a Belgian IBAN] - Add an invoice address to the created contact - Go to "Accounting / Customers / Direct Debit Mandates" - Create a mandate for the created contact - Create an invoice with the invoice address as customer - Confirm the invoice - Try to pay with "SEPA Direct Debit" **Issue:** No valid SEPA mandate is found for the customer. **Cause:** The mandate search is performed on the ID of the customer. As the customer is an invoice address, he is not associated to a bank account and a SEPA mandate. All these data are configured for his commercial partner. **Solution:** Search the mandates based on the ID of the commercial partner. opw-4276655