Daily updates from Odoo
Friday, September 12, 2025
8 changes · 17.0
Resolved issues and error corrections
Users with approval rights can now view other users' timesheets on private project tasks they follow. This prevents approvers from missing relevant time entries when they already have access to the task.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877
This update adds the missing SZJ product code required by Hungary's official NAV electronic invoicing specification. It helps ensure Hungarian invoice data can be classified correctly and stay aligned with regulatory documentation.
Original PR description
Description of the issue/feature this PR addresses: In the official NAV XML 3.0 documentation (available at: https://onlineszamla.nav.gov.hu/dokumentaciok page 123), according to the list of possible product codes, there is an 'SZJ' code that is missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
DIN5008 invoice reports no longer show the customer phone number in the address block, and customer VAT details are moved out of that address section. This keeps the report layout cleaner and better aligned with the intended DIN5008 presentation.
Original PR description
This commit removes the phone number from the DIN5008 report layout. The customer's VAT is also no longer displayed in the customer's address section. The VAT is moved to another section. Description of the issue/feature this PR addresses: Current behavior before PR: The customer's phone number and VAT are displayed in the customer's address in the DIN5008 report layout. Desired behavior after PR is merged: The customer's phone number is no longer displayed and VAT moved to another section in the DIN5008 report layout. opw-5049074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes Italian electronic invoicing so ENASARCO is treated correctly as both a withholding tax and a pension fund contribution. It ensures newly installed configurations and invoice XML exports match Italian reporting requirements, reducing compliance errors.
Original PR description
* = l10n_it, l10n_it_edi, l10n_it_edi_withholding The ENASARCO tax works both as a Withholding (negative) tax and as a Pension Fund tax. It must appear in the XML in both sections DatiRitenuta and CassaPrevidenziale. - We modified the master data to amend this error. Now the correct Withholding type appears right after installing the module. - Since there was an explicit check on taxes being both, we removed it. - Removed an exception where ENASARCO taxes were allowed to have positive values
Bank synchronization now starts after a company's accounting lock date, preventing transactions or opening balances from being created inside locked periods. This helps avoid incorrect transaction dates and keeps bank statement balances consistent when connecting a bank account.
Original PR description
If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing…
If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date. As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date). Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction. The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created. To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day. As for the opening balance, we do not try to set it one day prior to the oldest transaction, but the same day. The `internal_index` computed will ensure it is displayed as the first transaction of that journal. Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes. opw-4890538
Customers can no longer apply a coupon reward meant for a future purchase to the order that generated it. This keeps next-order promotions working as intended and avoids unintended discounts on the current sale.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a next-order coupon program; 2. create an order that would generate a coupon; 3. confirm order; 4. click on the "Reward" button. Issue ----- It's possible to claim the reward on the current order. Cause ----- When retrieving claimable rewards, it checks the coupons generated by the current order using `coupon_point_ids`, but does not verify whether the program should be applicable to the current order. Solution -------- If the program only applies on future orders, and the coupon's `order_id` is the current order, skip the coupon when retrieving claimable rewards. opw-4910922 opw-4948757 Forward-Port-Of: odoo/odoo#221536
The product margin calculation now uses net invoice amounts when calculating average sales prices. This prevents tax-included and tax-excluded invoice lines from being mixed together, giving businesses more reliable margin reporting.
Original PR description
The price_unit of a account.move.line can be with or without tax. The sale_avg_price should be either incl. or excl. tax. To ensure the avg price is always excl. tax the price_subtotal can be used. Forward-Port-Of: odoo/odoo#199209
Point of Sale now correctly receives cancellation updates from Worldline payment terminals even after the browser page is refreshed. This prevents orders from getting stuck during payment cancellation and adds clearer terminal error messages for staff.
Original PR description
This PR fixes a bug where the point of sale didn't receive notifications from the Worldline payment terminal for the cancellations if the browser webpage was refreshed How to reproduce: 1. Open a POS session with Worldline terminal 2. Send a transaction to the terminal 3. Refresh the browser webpage before paying 4. Click on "Cancel" on the POS screen --> your order will be stuck and never receive the confirmation This PR removes the check for the iot longpolling action identifier which changes on refresh of the webpage + adds more error messages for Worldline terminals Related PR in >= saas-18.3: https://github.com/odoo/enterprise/pull/94629 task-5075860