Daily updates from Odoo
Thursday, April 24, 2025
48 changes · 18.0
New functionality added to Odoo
Belgian payroll declarations can now be sent to and synchronized with the official ONSS portal through a dedicated SFTP connection. This reduces manual handling of DmfA files, improves compliance workflows, and includes fixes that make declaration generation and signature handling more reliable.
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
Documentation and clarification updates
This pull request adds an individual contributor license agreement signature for the contributor ohoc. It supports legal compliance by documenting contribution rights for the project.
Miscellaneous changes
To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and f
Original PR description
To reproduce: - Install both `hr_contract_salary` and `project_timesheet_holidays` - Create a public holiday for the company (ex. on May 01) - Create a employee => This create leaves for employee's company public holidays - Create a contract for that employee - Send a signing request to both employee and HR responsible - The employee sign the document - The responsible sign the document => At that time, we're going to update the contract after both parties signed the contract and force unarchiving the employee even if it's already active. This commit ensure that unarchiving an already active employee does not create duplicate *future* public holidays. opw-4134712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206997
In Hungary, when you fully reverse what is left to pay of an invoice with a Credit Note, it's usually called a "Storno" invoice, meaning an invoice that fully cancels what was previously sent. In the Hungarian EDI, invoices and credit notes are linked together, and they make a clear difference between a "modification" invoice (like a partial credit note, a debit note, etc) and a "cancellation" (Storno) invoice. We used to send it as a "modification" even when the residual amount was zero. Thi
Original PR description
In Hungary, when you fully reverse what is left to pay of an invoice with a Credit Note, it's usually called a "Storno" invoice, meaning an invoice that fully cancels what was previously sent. In the Hungarian EDI, invoices and credit notes are linked together, and they make a clear difference between a "modification" invoice (like a partial credit note, a debit note, etc) and a "cancellation" (Storno) invoice. We used to send it as a "modification" even when the residual amount was zero. This fix makes sure that it is sent as "cancellation" (Storno) in that case. task - 4707254 Forward-Port-Of: odoo/odoo#205390
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 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 Forward-Port-Of: odoo/odoo#205048
### Description of the issue/feature this PR addresses: - The `_t` call was used with non-static string (title), which breaks translation extraction since only static strings can be exported to .pot files. - Additionally, the title was directly injected into the DOM without escaping. ### Desired behavior after PR is merged: - The `_t` call is removed, as title passed to `_getBannerCommand` is already a translated static string. The value is now also passed through `htmlEscape()` befo
Original PR description
### Description of the issue/feature this PR addresses: - The `_t` call was used with non-static string (title), which breaks translation extraction since only static strings can be exported to .pot files. - Additionally, the title was directly injected into the DOM without escaping. ### Desired behavior after PR is merged: - The `_t` call is removed, as title passed to `_getBannerCommand` is already a translated static string. The value is now also passed through `htmlEscape()` before being used in the aria-label attribute. task-4639885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206954 Forward-Port-Of: odoo/odoo#205322
**Current behavior before PR:** - When gradient image is applied on element other than font or span, applying a gradient color to its child text would trigger a traceback. **Desired behavior after PR is merged:** - Now, if the gradient image is applied on element other than font or span, applying gradient color on its child text will applied gradient color properly. task:4730500 Forward-Port-Of: odoo/odoo#206272
Original PR description
**Current behavior before PR:** - When gradient image is applied on element other than font or span, applying a gradient color to its child text would trigger a traceback. **Desired behavior after PR is merged:** - Now, if the gradient image is applied on element other than font or span, applying gradient color on its child text will applied gradient color properly. task:4730500 Forward-Port-Of: odoo/odoo#206272
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#206985
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#206985
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the
Original PR description
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details:…
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the refund amounts to some special report line (modification/correction of base/taxes), whereas the modelo 390 uses the negative tax tags corresponding to the tax line in the report. The issue lies in the multiple cross report references from modelo 303 to modelo 390. In section 1, some base and tax amounts are referrenced from modelo 303, as well as the modification amounts (the total of refunds mentionned above). When we compute the totals for that section, some refunds can be counted twice (once from the report using the negative tax tags, and a second time if we count the modification cross referenced from modelo 303). Since we have more taxes using the negative tags than cross-referenced in that section, it is better to omit the modification from the totals (i.e. we do not subtract [30] for the totals, as the negative amounts are already accounted for for the majority of the taxes). The totals will still be incorrect for that section, but less wrong. A future PR for master will fix the report by splitting all the tags used for the two reports. In section 2, we are in a similar case, so we remove the subtraction of [62] from the totals. In this case, the totals are correct after this modification. Forward-Port-Of: odoo/odoo#205860
**Steps to reproduce:** - Install Accounting and Studio - Go to "Accounting / Customers / Invoices" - Enable Studio and go to "Reports" tab - Duplicate "Invoices without Payment" report - Note the id of this custom report (e.g. account.report_invoice_copy_1) - Go to "Settings / Technical / Email / Email Templates" - Open "Invoice: Sending" - In "Settings" tab, set the custom report as dynamic report - Go to "Settings / Technical / Parameters / System Parameters" - Add a new param
Original PR description
**Steps to reproduce:** - Install Accounting and Studio - Go to "Accounting / Customers / Invoices" - Enable Studio and go to "Reports" tab - Duplicate "Invoices without Payment" report - Note the id…
**Steps to reproduce:** - Install Accounting and Studio - Go to "Accounting / Customers / Invoices" - Enable Studio and go to "Reports" tab - Duplicate "Invoices without Payment" report - Note the id of this custom report (e.g. account.report_invoice_copy_1) - Go to "Settings / Technical / Email / Email Templates" - Open "Invoice: Sending" - In "Settings" tab, set the custom report as dynamic report - Go to "Settings / Technical / Parameters / System Parameters" - Add a new parameter: * Key: account.custom_templates_facturx_list * Value: [id of the custom report] (e.g. account.report_invoice_copy_1) - Create an invoice - Confirm the invoice - Send the the invoice via "Send & Print" button - Check the attached PDF **Issue:** 2 PDF are sent: the default invoice report and the custom one as configured on the email template. The default one has the factur-x version embedded in it, but not the custom one. **Cause:** The hook that embed factur-x into the PDF is called after the creation of the default PDF report. The custom reports (i.e. the dynamic ones) are created afterwards. However, the code that should trigger the hook for these ones is only doing it when coming from "Print" action and not from "Send & Print" action. **Solution:** Also trigger the hook to embed factur-x in custom report when using "Send & Print" action. opw-4645564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206512 Forward-Port-Of: odoo/odoo#204588
Versions -------- - 17.4+ Steps ----- 1. Ensure that Mitchell Admin has a child delivery partner in the database with the following information: 'name': 'Mitchell Admin', 'email': 'admin@yourcompany.example.com', 'street': '215 Vine St', 'country': 'US', 'city':'Scranton', 'zip':'18503' 2. Log in to eCommerce as Mitchell Admin 3. Add any deliverable product to the cart 4. Pay using Express Checkout Issue ----- Express Checkout fails when customers use different billing and s
Original PR description
Versions -------- - 17.4+ Steps ----- 1. Ensure that Mitchell Admin has a child delivery partner in the database with the following information: 'name': 'Mitchell Admin', 'email': 'admin@yourcompany.example.com', 'street': '215 Vine St', 'country': 'US', 'city':'Scranton', 'zip':'18503' 2. Log in to eCommerce as Mitchell Admin 3. Add any deliverable product to the cart 4. Pay using Express Checkout Issue ----- Express Checkout fails when customers use different billing and shipping addresses. If the shipping address is unknown to the system, a validation error blocks payment. If known, the payment goes through but results in a generic shipping error with no further details or options for the user. Cause ----- `billing_address` was wrongly parsed as `shipping_address` in a5df1a7. Solution -------- Parse `shipping_address` correctly. opw-4710674 Forward-Port-Of: odoo/odoo#207010
…ne with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206848
Original PR description
…ne with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206848
Changing the syntax of the product code line in the invoice to not have a space before the colon. Example: `VTSZ : 8604000` -> `VTSZ: 8604000` task-4707459 Forward-Port-Of: odoo/odoo#206602
Original PR description
Changing the syntax of the product code line in the invoice to not have a space before the colon. Example: `VTSZ : 8604000` -> `VTSZ: 8604000` task-4707459 Forward-Port-Of: odoo/odoo#206602
We get an Access Error when trying to print check from a journal that is shared between branches. Steps: - Have a company X and a branch Y - Make a vendor payment with only X selected in company selector, set payment method as 'Checks' - Confirm and print check - Now select only branch Y in company selector - Create a vendor payment with same config as previous one - Condirm, and try to print check -> Access Error This is because we try to get the previous check number from the last payment
Original PR description
We get an Access Error when trying to print check from a journal that is shared between branches. Steps: - Have a company X and a branch Y - Make a vendor payment with only X selected in company selector, set payment method as 'Checks' - Confirm and print check - Now select only branch Y in company selector - Create a vendor payment with same config as previous one - Condirm, and try to print check -> Access Error This is because we try to get the previous check number from the last payment of the journal, but even if the record shares the same journal, we don't necessary have access to it. Fix: Get `check_number` directly from the SQL query instead of a record opw-4520708 Forward-Port-Of: odoo/odoo#206304
Explanation: Includes previously missing supported payment methods for AsiaPay, such as Alipay (distinct from AlipayHK). Forward-Port-Of: odoo/odoo#206836
Original PR description
Explanation: Includes previously missing supported payment methods for AsiaPay, such as Alipay (distinct from AlipayHK). Forward-Port-Of: odoo/odoo#206836
## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login` is checked; - Share the survey (copy the `Survey Link`); - In a private navigator (to ensure no login data are saved): - Log in as Demo user; - Answer the survey (using the copied link above); - Go to Surveys / Participations; - Enter the record of your test (`Contact` field shoul
Original PR description
## Issue: Survey's PDF certifications no longer display the company logo when printed by other companies' users. ## Steps to reproduce: - Create a survey with certification and ensure `Require Login`…
## Issue:
Survey's PDF certifications no longer display the company logo when printed by other companies' users.
## Steps to reproduce:
- Create a survey with certification and ensure `Require Login` is checked;
- Share the survey (copy the `Survey Link`);
- In a private navigator (to ensure no login data are saved):
- Log in as Demo user;
- Answer the survey (using the copied link above);
- Go to Surveys / Participations;
- Enter the record of your test (`Contact` field should match Demo's data);
- Open the PDF certification in the chatter.
## Cause:
The company `logo` field is a Binary field related to the partner's `image_1920`.
The retrieval method was changed to access `partner_id.image_1920` directly with `sudo`, since `sudo` does not apply when accessing the related field (`logo`) directly.
However, this change broke the standard certification printing layout, likely due to rendering issues with the direct access method.
## Fix:
Reverts logo access back to the related field `company_id.logo` to restore compatibility with certification printing.
Partial revert of commit 9b4c4ad8d1a238c6f7f4bea52d3f64016a6ff325 as already applied by JKE on Odoo.
Ensures the certification printing is still allowed for other companies' users.
opw-4266445
opw-4657294
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#204262Fixes an issue in `test_pos_js` when executed in a database without demo data, where missing payment methods cause test failures. This commit adds the necessary payment methods and a required product to the configuration, ensuring proper test execution. Runbot Error: 135208 Forward-Port-Of: odoo/odoo#199913
Original PR description
Fixes an issue in `test_pos_js` when executed in a database without demo data, where missing payment methods cause test failures. This commit adds the necessary payment methods and a required product to the configuration, ensuring proper test execution. Runbot Error: 135208 Forward-Port-Of: odoo/odoo#199913
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present
Original PR description
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form…
**Issue** Menu items starting with helpdesk in their URL were not dispalyed to the public user in some cases. **Steps to reproduce** - Have `website_helpdesk` installed. - Activate the website form for a helpdesk team. - Create a menu item for the website, using a URL starting with helpdesk, e.g. `/helpdesk-123-test` - This menu is always invisible to the public user. **Cause** This issue was fixed in previous versions, but it appears the duplicated `_compute_visible` code present in `website.py` was not deleted in forward ports of the fix (see enterprise PR 63105). https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L24-L26 As a result, the menu item starting with `/helpdesk` is matched as a helpdesk menu, but will logically not be part of the helpdesk published menus: https://github.com/odoo/enterprise/blob/b320390d23d3f009beb809e0334c8fa61c44d824/website_helpdesk/models/website.py#L30-L32 opw-4560291 Forward-Port-Of: odoo/enterprise#82824
Open Trial Balance report in debug mode Access report options In Column tab, check 'Blank if Zero' for all columns Go back to report Issue: If Initial/End Balance columns are blank, also the total line will be blank. This occurs since f3c230817087d452f810b8473f813add0ead30d0 were the formatting of values has been delayed to improve performances but the exception on 'blank_if_zero' was lost opw-4624006 Forward-Port-Of: odoo/enterprise#83493
Original PR description
Open Trial Balance report in debug mode Access report options In Column tab, check 'Blank if Zero' for all columns Go back to report Issue: If Initial/End Balance columns are blank, also the total line will be blank. This occurs since f3c230817087d452f810b8473f813add0ead30d0 were the formatting of values has been delayed to improve performances but the exception on 'blank_if_zero' was lost opw-4624006 Forward-Port-Of: odoo/enterprise#83493
Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels and Export Documents * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on z
Original PR description
Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In…
Currently, when validating deliveries, if multiples attachments are posted in the same chatter message, the printing jobs do not complete. Steps to reproduce: ------------------- * Install fedex * In operation types, select Delivery Orders then hardware * In print on validation, enable Carrier Labels and Export Documents * In the shipping methods, select fedex international * Change Label format to ZPL11 * Connect the database to an iot box * Set up the shipping labels to be send on zebra printer * Set up commercial invoice (/invoice) to be sent to another printer * Create a sale order, using fedex international as shipping * Confirm the SO * Select the delivery * Validate the delivery > Observation: Nothing prints, jobs are sent to CUPS bu not printing Why the fix: ------------ https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_fedex_rest/models/delivery_fedex.py#L192-L196 As show, when sending the shipping, if the invoice is generated, it gets added to the attachements. The function `message_post` will post all attachments in the same chatter message. In `delivery_iot` the `message_post` function is overridden to allow sending the printing jobs to the iot. https://github.com/odoo/enterprise/blob/8075101192fb81a78f2a984cf2adf67fc77c0194/delivery_iot/models/stock_picking.py#L33-L46 Here, `attachments_names` will both contain `Label` and `ShippingDoc`. Since we enter the first if condition, the report is related to the shipping labels. Then we send the data related to all attachments to the device linked to the shipping labels, aka the zebra printer. Since the other attachment is of type PDF, the zebraprinter does not know what to do with it and ends up printing nothing. Since we can have multiple different attachment, the if/elseif condition does not make sense. By breaking it in two if, we can send both reports separately, while still keeping all attachments in the same chatter message. opw-4546715 Forward-Port-Of: odoo/enterprise#82094
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#82980
Original PR description
Issue : Given a pivot grouped by date with anything else than year as aggregate (I tried with week, quarter and month), Given the pivot is exploded When I autofill the date cells and the date passes from one year to another, it crashes hard New behaviour: For bounded date fields, the autofill loop around when reaching the upper bound. Task: 4700703 Forward-Port-Of: odoo/enterprise#82980
- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterpr
Original PR description
- Adding 'invoice_received' as an accepted state in account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment to enable SAT status display on vendor bills in 17.0, making SAT status no longer remain None. - Making adjustments to functions updating SAT status related fields for vendor bills. - Adding a test for SAT status for creating and cancelling vendor bills. The change necessary to display 'Update SAT' button was already implemented in 17.0 in https://github.com/odoo/enterprise/commit/931d7b199f1183acfbb42325025a6b62b2e73de1 but not forward ported yet. task-4368532 Forward-Port-Of: odoo/enterprise#83842 Forward-Port-Of: odoo/enterprise#80201
…n manual line with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 Forward-Port-Of: odoo/enterprise#83809
Original PR description
…n manual line with tax - Open the bank rec widget - Set a tax on a line - Change the currency to one that is not the journal one nor the transaction one => Traceback '_prepare_counterpart_amounts_using_st_line_rate' wasn't managing this case. opw-4526096 Forward-Port-Of: odoo/enterprise#83809
Before this commit: The technical name was not clearly visible in dark mode, making it difficult for users to read. After this commit: The technical name is now clearly visible in dark mode. Task-4680365 Forward-Port-Of: odoo/enterprise#82429
Original PR description
Before this commit: The technical name was not clearly visible in dark mode, making it difficult for users to read. After this commit: The technical name is now clearly visible in dark mode. Task-4680365 Forward-Port-Of: odoo/enterprise#82429
Steps: - duplicate a worksheet template - add a field on the new template - print the original template --> error : field doesn't exist on original worksheet model Current behaviour: Duplicating a worksheet template creates a new model, but the _generate_qweb_report_template method doesn't create a new view for the new template because we copied the original one. It also removes the customizations on the original template's view New behaviour: A new view is created for the dupli
Original PR description
Steps: - duplicate a worksheet template - add a field on the new template - print the original template --> error : field doesn't exist on original worksheet model Current behaviour: Duplicating a worksheet template creates a new model, but the _generate_qweb_report_template method doesn't create a new view for the new template because we copied the original one. It also removes the customizations on the original template's view New behaviour: A new view is created for the duplicated template and remove the duplicate option from the list view, as it is already hidden in form view opw-4664600 opw-4656835 Forward-Port-Of: odoo/enterprise#83529 Forward-Port-Of: odoo/enterprise#83166
…arning domain The unposted entries warning was sometimes triggered unnecessarily due to the domain used for querying move not accounting for the companies accessible by the report. This led to cases where unposted entries from unrelated companies were considered, resulting in misleading warnings. This commit addresses the issue by using the company IDs returned by `get_report_company_ids()` to properly scope the domain. no-task Forward-Port-Of: odoo/enterprise#83846 Forward-Port-Of
Original PR description
…arning domain The unposted entries warning was sometimes triggered unnecessarily due to the domain used for querying move not accounting for the companies accessible by the report. This led to cases where unposted entries from unrelated companies were considered, resulting in misleading warnings. This commit addresses the issue by using the company IDs returned by `get_report_company_ids()` to properly scope the domain. no-task Forward-Port-Of: odoo/enterprise#83846 Forward-Port-Of: odoo/enterprise#83025