Daily updates from Odoo
Thursday, April 24, 2025
29 changes
1 change
Resolved issues and error corrections
Double-clicking a table border in the HTML editor no longer selects an entire column or triggers an error when the cursor is outside the table. This makes table editing more predictable and prevents a disruptive crash scenario for users editing content.
Original PR description
**Current behavior before PR:** - Double-clicking on a table border would select the table column if the selection was inside a table cell. - If the selection was outside the table, a traceback will occur. **Desired behavior after PR is merged:** - Now, a table cell is now only selected when the double-click is performed inside the cell, not on its border. task:4730234
6 changes
Resolved issues and error corrections
This fix ensures a required access rule file is included when the Planning Attendance app is installed or updated. It helps prevent permission-related issues for users working with planning and attendance data.
AI field processing now follows a clearer order and the related prompt code has been simplified, making behavior more predictable. The update also fixes an issue that prevented regular users from saving approved AI prompt expressions, reducing friction for day-to-day use.
Original PR description
…cation Task-4742523
The payroll accounting partner bank view has been adjusted so fields remain properly aligned after a related partner field was moved. This prevents a visual layout gap and keeps the form easier for users to read and complete.
Original PR description
- as the `partner_id` place changed in the view the empty div is missing the arragment Task: 4531266
This fixes a missing setup entry that prevented point of sale IoT connection requests from being accepted by the IoT Box. Businesses using connected POS hardware should see more reliable communication with their IoT Box.
Original PR description
The manifest was missing the path to the longpolling override in the IoT module. As a result, no longpolling call was signing their request and the IoT Box refused them.
The GST reporting flow now prevents users from creating duplicate return periods for the same month or quarter. This improves filing accuracy and avoids confusion when return periods are created around the government portal deadline window.
Original PR description
Steps to Reproduce: =================== The user creates a GST return period for example January 2025 between 1st - 10th April. After 10th April, the user creates another GST return period for…
Steps to Reproduce: =================== The user creates a GST return period for example January 2025 between 1st - 10th April. After 10th April, the user creates another GST return period for January 2025. The system allows the creation of a duplicate record. Reason: ======= As per GST filing rules, the return period for the previous month can be filed on the government portal until the 10th of the following month. The system automatically sets the month and quarter values to the previous month and previous quarter respectively if the current date is between the 1st and 10th of a month, when the periodicity is set to monthly or quarterly. Cause: ====== Both records are considered different by the system based on the quarter value or month value and the system does not block the creation of duplicate GST return periods. Technical: ========== Modified the SQL constrains into two separate constrains for checking unique return period monthly and quarterly. Also, changed the default method to the compute method and added quarter logic in the creation of the Return period from the 'fetch from GSTN` button. Changed the quarter's key because with the start month, it's considered as IFF **UPGRADE PR:** https://github.com/odoo/upgrade/pull/7270 **Task**-4534812
VoIP contact loading no longer fails for users who do not have permission to view recruitment applicant records. Applicant details are now only included when the user is allowed to access them, improving reliability while respecting existing access rules.
Original PR description
Before this commit, the code unconditionnally reads and sends hr.applicant records linked to a VoIP contact, leading to a crash in case the current user doesn't have access to hr.applicant records. After this commit, applicant data are only sent if the user has access to hr.applicant.
22 changes
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
Users can now remove a fully selected link formatted as a button without leaving behind an empty visible button. This prevents confusing leftover link elements in the HTML editor and keeps edited content clean.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a link in button primary format. - Select the label of the link either double clicking on the text. - Try to remove link from toolbar. - Notice that the link is not removed properly. This issue happens because if there is an adjacent `feff` character before or after selected text node of link and it is not traversed in selection then `splitAroundUntil` ends up creating an adjacent empty link. If link is in button format then empty links are visible. **Desired behavior after PR is merged:** Link should be removed entirely. task-4622487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Warehouse creation for repair operations now shows a clear message when a required production location is missing. This helps users understand and fix the setup issue themselves instead of encountering a confusing system error.
Original PR description
Previously, an inline search was used to fetch the production location. If no production location existed for the company,a SQL constraint error would occur during warehouse creation due to the missing field default_location_dest_id. This change uses the existing _get_production_location method to raise a clear UserError instead, making the issue easier to understand. I have seen this on several tickets now so this would prevent future tickets from ending up in our pipe as now the user can just create a production location themselves. --- 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
Fixed a display issue in the HTML editor where the bottom border could scroll away when content exceeded a fixed height. The change also prevents editor action buttons from appearing outside the visible editing area, making fixed-height editing clearer and less confusing for users.
Original PR description
**Current behavior before PR:** - When the height option is passed to the editor and the content exceeds that fixed height, the bottom border scrolls along with the content instead of staying anchored at the bottom. - When Enter was pressed at the bottom of a fixed-height editor, the newly inserted block was positioned outside the editable area. As a result, power buttons were also shown outside the editor until the block was scrolled into view. **Desired behavior after PR is merged:** - The bottom border now remains fixed at the bottom of the editor when the height option is set, even if the content overflows and becomes scrollable. - Power buttons are no longer displayed while the block is outside the visible editable area. task: 4718217
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
The HTML editor’s automated tests for the translate button were adjusted to avoid timing-related failures under heavy system load. This helps keep development and release validation more stable without changing the user-facing editor experience.
Original PR description
Using `setContent` inside a test with a selection change and rely on the selectionchange event to trigger a modification of the interface that is the very subject of the test is error-prone as the sequence of events in that case is non-deterministic under heavy cpu load and thus ends up creating a hidden race condition.
This fixes automated editor tests that were failing after a Chrome browser update changed how table selections are handled. The change helps keep quality checks reliable without changing behavior for end users.
Fixes a Firefox issue where the font size control in the HTML editor did not show the current size or open properly on the first click. This makes text formatting in apps like To-Do more predictable and easier for users.
Original PR description
### Browser: Firefox ### Steps to Reproduce: - Go to To-Do - Type something - Select the typed text - Font size is not visible and dropdown doesn't appear on single click ### Description of the issue/feature this PR addresses: - Font size input inside the iframe was not properly initialized in Firefox due to delayed iframe load. - Clicking once on the font size selector did not open the dropdown. ### Desired behavior after PR is merged: - Font size input initialization is deferred until iframe is fully loaded. - Dropdown now opens correctly on single click and displays current font size. task-4735622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
The Point of Sale order sync now only clears orders that were actually synchronized. This prevents pending, unsynced orders from being accidentally removed, reducing the risk of lost sales data.
Original PR description
In `syncAllOrders`, we can specify which orders should be synced using options. This means that not all pending orders need to be synced at once. However, `clearPendingOrder` currently removes all pending orders, even those that haven't been synced, leading to order loss. This commit ensures that only synced orders are removed from pendingOrders. Task: 4702408
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
Users can now assign credit card journals when linking online accounts, matching the existing behavior for bank journals. This fixes a selection limitation in the online synchronization setup and helps keep credit card account connections properly organized.
Original PR description
In the account online link form view, you have a tab with the tree view of the existing online accounts. In that tab, you can directly assign a bank journal to an online account. But you can't do it for credit card journal as they were not added to the domain. This PR adds the credit type journal in two domains. opw-4698397
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