Thursday, April 24, 2025
14 changes · 18.0
Resolved issues and error corrections
This fixes cases where intercompany dropship purchases could be assigned to an incorrect stock location when the final customer address was unavailable. The system now uses the dropship operation’s default destination instead, helping keep inventory movements accurate and avoiding misleading stock routing.
Original PR description
In some case, the dest_address is not available when the picking type is dropship. In those cases, the final_location will be arbitrary fallback on default behavior and set to stock depsite we don't go through it. Instead we use the default location dest on the picking type as the final location since we can't guess where it goes. Also remove a location_final propagation through push rule if we already reach it. 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
The website menu editor now gives clearer visual feedback when users drag items into sub-menus. This makes it easier and less confusing to organize navigation menus, especially when creating nested menu items.
Original PR description
This commit fixes the following two issues in the menu creation dialog: **Issue 1:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu…
This commit fixes the following two issues in the menu creation dialog: **Issue 1:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu Editor." - Drag a menu item (without dropping it) to the right to create a sub-menu. - The issue is that while dragging the menu item, when the placeholder is in a sub-menu position, the menu item keeps its original width instead of taking the width of a sub-menu item. This is confusing and unclear from a UX perspective. | BEFORE | AFTER | | ------------- | ------------- | |  |  | ---------------- **Issue 2:** - Install the Website app and go to the homepage. - In the backend navbar, click on "Site" and then on "Menu Editor." - Drag and drop the second menu item to the right to create a sub-menu. - Drag another menu item (without dropping it) to the right to create a second sub-menu below the first one. - Without releasing it, continue dragging it to the right. - The issue is that the placeholder disappears at this point. To make it reappear, the menu item must be moved slightly to the left again. This results in a very poor user experience and makes sub-menu creation messy. | BEFORE | AFTER | | ------------- | ------------- | |  |  | task-4422810
Leave-related timesheets and work entries now use the expected daily hours for employees with flexible schedules instead of counting the full time span between leave start and end. This prevents inflated leave totals, such as a 4-day leave being recorded as 83 hours instead of 32, improving payroll and project tracking accuracy.
Original PR description
### Steps to reproduce: - Create a leave type that creates timesheet - Create a leave for a flexible employee for 4 days - Check the timesheet created for this leave - Notice the amount of this…
### Steps to reproduce: - Create a leave type that creates timesheet - Create a leave for a flexible employee for 4 days - Check the timesheet created for this leave - Notice the amount of this timesheet is 83 hours not 32 ### Cause: When creating a timesheet or a work entry for a leave we get the difference between the start and the end date in milliseconds and divide it by 3600 to get the hours. Timesheet: https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_mixin.py#L208-L213 Work entry: https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L522-L525 This doesn't work for flexible hours as when fetching attendance intervals for flexible employee we return one big block for the whole period as there is no attendance intervals for the flexible employees. https://github.com/odoo/odoo/blob/c3c63c3d00852010be4fe61a6f2314a099d99215/addons/resource/models/resource_calendar.py#L370-L376 ### Fix: When fetching the attendance intervals for flexible employee we return the hours per day as duration hours not the diff between the start and the end date of the period. We only use the diff between the dates in case of fully flexible. Then we use this duration hours in timesheet and work entry creation opw-4628296
This fix prevents payments from incorrectly moving back to “In Process” when their account setup does not support reconciliation. It helps accounting users see the correct payment status and avoids confusion after linking payments to invoices.
Original PR description
### Steps to reproduce: - Accounting > Journals > Bank - Set the journal "Bank" as "Outstanding Receipts Account" on the line "Manual Payment" in the page "Incoming Payments" - Create a payment with…
### Steps to reproduce:
- Accounting > Journals > Bank
- Set the journal "Bank" as "Outstanding Receipts Account" on the line "Manual Payment" in the page "Incoming Payments"
- Create a payment with a partner
- Confirm it, its state should be "Paid"
- Create an invoice with the same partner and amount
- Confirm and click the add button to link the payment
- Return on the payment, its state is back to "In Process"
### Cause:
This [commit](https://github.com/odoo/odoo/commit/533984ac5c10fbd91742f34b740c63c04fbef094) added the return to the state "In process" when payment are unreconciled. The check is:
`if move.currency_id.is_zero(sum(liquidity.mapped('amount_residual')))`
When setting the journal "Bank" as the outstanding account, the line which appear in `liquidity` has the payment amount in `amount_currency` and `amount_residual`. So the amount is not 0 and the payment state is set back to "In Process".
### Solution:
When the account of the payment does not allow reconciliation, the payment is never supposed to be in the state "In Process". To prevent this, this commit adds a check on `account_id.reconcile`.
opw-4718717Bank statement lines created through bank synchronization now keep the correct transaction date even when a default Invoice/Bill Date is configured. This prevents imported bank data from showing misleading dates and helps users reconcile statements accurately.
Original PR description
The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_write)`, the date field gets considered 'dirty' by the ORM (unless it is explicitly set in the vals), and when the `account.move.line` tries to set-up its date, which is related to the move, the compute method for the date is triggered as the field was flagged as dirty. opw-4662209
This fixes an issue where a recipient bank account stayed locked after an invoice was sent and then reset to draft. Users can now correct an incorrect bank account in draft invoices without needing to create a credit note.
Original PR description
Steps to reproduce - Have a bank account in the accounting tab of the current company partner - Create an invoice for a customer - Confirm it - Send&Print - Reset the invoice to draft Issue: In 'Other Info' tab, the Recipient Bank (`partner_bank_id`) is still red-only. It occurs since 5c7eefed412e676c6ddf67f62bce514e5bade44c The bank account is now editable even when the invoice is posted but become readonly once the invoice is sent. This means that if a wrong bank account has been set by mistake it is impossible to change it, and a credit note is needed. opw-4683997
This fixes how invoice tax base amounts are rounded when global rounding is used, ensuring totals are calculated from the overall amount rather than partial base amounts. It helps Portuguese-certified accounting outputs stay accurate and compliant, reducing small rounding discrepancies on invoices.
Original PR description
Compute the delta for base amounts in '_round_base_lines_tax_details' from the total instead of from the base amounts only. See test in this commit. task-4457168
This fixes an issue where down payments made in Point of Sale were not deducted when settling a sales order. Sales order settlement now includes the related down payment lines, so customers see the correct remaining balance and order details.
Original PR description
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the product with it's full price, even though we already payed a part of it in the down payment. The down payment won't be displayed and won't be taken into account. **Steps to reproduce:** - Make a Sale Order in the sales app - Go to POS and make a down payment for it. - Settle the order - See that the down payment has not been applied and only the product is present **Why the fix:** When reading the order we are trying to settle from the backend we also trigger the `missingRecursive` function as the lines corresponding to the downpayment line and the line sections were missing from the loaded records. `sale.order.line` records are thus read from the backend but are not linked back to the sale order leading to the missing lines on the pos order as well. opw-4718691
Resized WebP images now use higher-quality smoothing, reducing blur and pixelation in smaller previews such as 128px thumbnails. This improves the visual clarity of images shown in Odoo without changing user workflows.
Original PR description
Enable canvas image smoothing with high quality settings to improve the visual output of resized images. The issue was most noticeable in the 128px version, which appeared blurry or pixelated. <img width="1279" alt="Screenshot 2025-04-02 at 11 03 17" src="https://github.com/user-attachments/assets/dd2c9f92-1ad9-409b-9c17-184059dc5adf" /> opw-4689905 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a role check so employees assigned as Point of Sale managers are recognized correctly. As a result, authorized managers can change product prices during sales instead of being incorrectly blocked.
Original PR description
Fix the condition to assign 'manager' role by checking employee ID instead of user_id in manager_ids. This aligns with the actual filtering done earlier where manager_ids contains employee IDs. Original condition could incorrectly assign roles when user_id was set but didn't match the manager group check. --- **Description of the issue/feature this PR addresses:** 1. Set user as Point of Sale manager 2. Open Point of Sale with user having a closed cash register 3. Start sale by selecting product 4. Change product price **Current behavior before PR:** - Error appears stating "Price change not allowed" **Desired behavior after PR is merged:** - Allow price change **Screenshoot**  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a customer pays a down payment on a sale order through Point of Sale, the system now correctly shows only the unpaid balance when the order is later settled. This prevents staff from being asked to collect the full order amount again and reduces payment errors at checkout.
Original PR description
- Ensure accurate computation of remaining amount on a Sale Order when a down payment is settled first in POS. - Add test to verify the correct behavior of the remaining amount after down payment. Steps to reproduce : Create a Sale order ( total : $ 1000) - Open POS - Action btn, quotation / order - Settle a down payment (fixed or percentage). Let's say you want to make a downpayment of $ 500. - Go to payment, validate the payment - Go back to product screen - Action btn, quotation / order - Select the same Sale order - Settle the order (only $ 500 left to pay) - In the cart, the amount to pay is $ 1000 (it should be $ 500) task-id: 4720154 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Bank statement lines imported through bank synchronization now keep the correct transaction date even when a default invoice or bill date is configured. This prevents misleading accounting dates and reduces the risk of reconciliation or reporting errors.
Original PR description
The date used in statement lines is invalid when lines are created via bank synchronization, and the user has configured a default date for the Invoice/Bill Date field. Steps to reproduce: - Set a default value for the Invoice/Bill Date field. - Connect to Demo Bank and import the test statement line. - Check the statement line date; it will use the default Invoice/Bill Date value instead of the correct one. The issue comes from the fact that during the `st_line.move_id.write(to_write)`, the date field gets considered 'dirty' by the ORM (unless it is explicitly set in the vals), and when the `account.move.line` tries to set-up its date, which is related to the move, the compute method for the date is triggered as the field was flagged as dirty. opw-4662209
Approval purchase requests now allow RFQ creation as long as the product has a vendor, even if the requested quantity does not match a vendor pricing rule. This prevents valid purchase requests from being blocked unnecessarily and keeps purchasing workflows moving.
Original PR description
This commit backports a change done in https://github.com/odoo/enterprise/pull/83876. The check on the product vendor was based on the `_select_seller` method, which does not give any result if the quantity does not match any vendor. However, the check should be more permissive and allow the RFQ creation if a vendor exists, no matter the quantity. Part of task-4680780 Backport of https://github.com/odoo/enterprise/pull/83876
Odoo now checks incoming UrbanPiper orders to avoid creating duplicate draft orders when the same delivery request is received through multiple domain webhooks. This helps businesses keep point-of-sale delivery orders accurate and reduces manual cleanup.
Original PR description
In this commit, --------------- When multi-domains are configured in Odoo, it will generate various webhooks at UrbanPiper, which leads to the creation of duplicate draft orders along with the original order. Added a check to restrict duplicate orders with the same delivery ID and the same delivery provider. task - 4727174