Saturday, February 22, 2025
10 changes · 17.0
Enhancements to existing features
This update replaces several custom database savepoint patterns with a shared helper, reducing the chance of inconsistent behavior and making maintenance easier. It is an internal cleanup with no expected change to day-to-day user workflows.
Original PR description
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times...
This update replaces a low-level database checkpoint pattern with a standard helper in affected Odoo flows. It reduces maintenance risk and keeps behavior stable for users by avoiding unnecessary changes to data flushing.
Original PR description
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change.
Resolved issues and error corrections
Customer portal payments now correctly apply eligible early payment discounts instead of charging and recording the full invoice amount. This helps prevent overpayments and keeps accounting entries aligned with the discount shown to customers.
Original PR description
Steps to reproduce: - Go to accounting > configuration > payment terms > NEW - Create a new payment terms with Early Discount checked > confirm - Go to customer > invoices > NEW - Create a new…
Miscellaneous changes
Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state t
Original PR description
Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state to saas18.1, where each unit points to its reference as a parent. Having multiple references in the same category caused a having a cycle in this link. See: https://github.com/odoo/upgrade/blob/master/migrations/uom/saas~18.1.1.0/pre-migrate.py#L16-L25 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197634
Steps to reproduce: - Go to accounting > configuration > payment terms > NEW - Create a new payment terms with Early Discount checked > confirm - Go to customer > invoices > NEW - Create a new invoice with the payment terms selected > confirm. - When clicking "Restiger Payment" to manually pay, the modal will display the early discount informations if the invoice is eligible. - Click on Preview (short cut to access to the invoice through the portal) - Assuming the invoice is eligible for early payment discount, the informations are not displayed in the side bar. - Click on pay > select a payment provider > confirm - Notice how the full payment was registered in accounting chart of account. Cause: the early discount feature is not properly handled in the portal view. Analysis: When previewing the transaction, the context sent `amount` is not well computed (controller portal). This `amount` context is the one used when creating the transaction https://github.com/odoo/odoo/blob/3ef9310ec36f1d5abd3f55e92eedb2ac7133d97a/addons/account_payment/controllers/payment.py#L40-L42 Therefore, we need to make sure that the `amount` defined in the view is the discounted amount if early_payment and the full amount if not. Solution: Mainly backport from https://github.com/odoo/odoo/pull/177905/ XML: - we keep the the `t-if="0"` to not break Xpath in stable - `t-if="amount"` just to make sure it does not break for a credit note https://github.com/odoo/odoo/blob/17.0/addons/account_payment/controllers/portal.py#L14-L16 opw-3632594
The import screen now correctly keeps and applies the “No Separator” option when users import bank statement CSV files. This prevents the system from accidentally treating commas as the thousands separator, helping avoid incorrect import previews or results.
Original PR description
**Steps to reproduce:** - Install Accounting - On Accounting dashboard, click on "Import File" button of Bank journal - Select a CSV file with bank statements - On the left menu, select "No…
**Steps to reproduce:** - Install Accounting - On Accounting dashboard, click on "Import File" button of Bank journal - Select a CSV file with bank statements - On the left menu, select "No Separator" as "Thousands Separator" **Issue:** "Comma" is displayed as selected instead the first time. The second time "No Separator" stays as selected. However, the value sent when testing or importing is not the correct one. **Cause:** "No Separator" option should have an empty string as value. However, during the generation of the "select" element, the value for the "option" element is evaluated with: `opt.value or opt` As `opt.value` is the empty string (evaluated to False), `opt` is used instead, even if it is an object, which is not correct. The main issue is that the empty string is not handled as a valid value. **Solution:** Handle the empty string as an acceptable value. opw-4325310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the Accounting dashboard from breaking for Turkish companies when used by employees without administrator rights. Non-admin users can now access the accounting module and journal dashboard normally, avoiding disruption to daily finance work.
Original PR description
Before this commit: Steps 1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 2) Switch to TR company 3) Create a user without administration access 4) Try to open accounting module using the created user => An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal dashboard view due to missing access After this commit: The Accounting module and journal dashboard view work correctly for non-admin users Reproducing the issue in Runbot: https://drive.google.com/file/d/1YIjvoXNDe6atVyzWC1dVU58rDFnoYH7x/view?usp=drive_link opw-4551932
The Discuss call interface now checks the correct connection status before showing a warning. This prevents users from seeing misleading call connection alerts when there is no actual issue.
Original PR description
Before this commit, the condition for displaying the call warning was using `rtc.connectionType` instead of `rtc.state.connectionType`, which resulted in the warning being shown in the wrong situations.
This fixes an issue where saving an edited related record could crash or discard the user's changes when the list had a custom ordering using hidden fields. After the fix, edited records stay in place and the saved changes are preserved, making form dialogs more reliable for users.
Original PR description
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that…
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog. 1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because we tried to sort records on a field that is unknown. 2) if it wasn't the first field of the order, e.g. `default_order="x,y"` but y wasn't in the view: the changes done in the dialog were lost, so it was no possible to edit records. Both issues had the same root cause. After the edition, we tried to sort the relation (as the order might have changed). We do that since [1], but it wasn't the main purpose of this commit. It has been done because it looked like a quick win at the time, and we thought it was a good idea. However, functionally speaking, sorting the records after the edition isn't wanted. If I just clicked on a record, edited it, I expect the record to remain where it was after closing the dialog. So as sorting isn't necessarily wanted, and it even produces issues in some cases, this commit reverts that "feature". [1] https://github.com/odoo/odoo/commit/17e198153ecfd9c5c32b3b22f43e2f1b8100a1c3 Closes #197867 opw-4499150 (case (2)) 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
Steps to reproduce the bug: - Create a “quality.point”: - Operations: Manufacturing - Add a Work Order Operation - save - Update the operations to Receipt. Problem: The Work Order Operation field becomes invisible, but it is still filled so the quality point will still be applied. opw-4536136 Forward-Port-Of: odoo/enterprise#79868
Original PR description
Steps to reproduce the bug:
- Create a “quality.point”:
- Operations: Manufacturing
- Add a Work Order Operation
- save
- Update the operations to Receipt.
Problem:
The Work Order Operation field becomes invisible, but it is still filled so the quality point will still be applied.
opw-4536136
Forward-Port-Of: odoo/enterprise#79868This commit adds one flow test to `l10n_ec_edi` that mocks `zeep` when sending an invoice to the SRI. This complements the existing tests that check the generated XML. task-none Forward-Port-Of: odoo/enterprise#77578
Original PR description
This commit adds one flow test to `l10n_ec_edi` that mocks `zeep` when sending an invoice to the SRI. This complements the existing tests that check the generated XML. task-none Forward-Port-Of: odoo/enterprise#77578