Monday, June 2, 2025
40 changes · 18.0
Enhancements to existing features
This update speeds up processing of historical point-of-sale orders when upgrading to Odoo 18 or enabling French POS certification on an existing database. Large databases that previously spent close to an hour preparing order links can now complete the same step in about a minute, reducing upgrade downtime and deployment risk.
Original PR description
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to…
**Patch description:** - This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to `v18.0` because field `previous_order_id` got introduced in `v18.0` or when installing the `l10n_fr_pos_cert` module on an existing db with many POS orders in `v18.0`. - In both cases, the compute method is triggered for all `pos.order` records to assign the `previous_order_id`, causing significant delay due to per-record lookups. **Example from a real DB with ~113k orders:** ```sql apan_2840187=> select count(*) from pos_order; count -------- 113342 (1 row) ``` **Observation:** - Before the fix (compute took nearly 50 minutes): ```py 2025-05-29 06:31:12,587 28 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 2025-05-29 06:31:12,799 28 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id 2025-05-29 07:17:37,855 28 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml ``` - After the fix (completed within 1 min): ```py 2025-05-30 06:56:59,510 24 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 2025-05-30 06:56:59,584 24 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id 2025-05-30 06:57:12,531 24 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml ``` **Note:** The issue reported in the OPW was not originally about perf, but it was clearly exposed during the upgrade of the mentioned db. opw-4812874 upg-2840187 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting dashboard now shows the "Fetch from CodaBox" action as a link-style button. This improves spacing and alignment with nearby actions, making the dashboard look cleaner and easier to use.
Original PR description
The "Fetch from CodaBox" link displayed on the accounting dashboard had no gap between it and the button at the left of it, and wasn't aligned horizontaly with the other buttons next to it making it look out of place. It is now displayed as a link button, which solve both problems. task-4671468 Purpose The fetch from CodaBox is too sticky to the upload button  After this commit : 
Resolved issues and error corrections
This fixes a mail-sending issue where Odoo could raise an error if the SMTP connection had already been closed. The change helps email processing finish more reliably and reduces avoidable failures during outgoing mail handling.
Original PR description
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
Miscellaneous changes
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
Original PR description
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
Invoice PDFs now handle very long tax group names without pushing total amounts off the page. This keeps invoice totals visible and readable for customers and accounting teams.
Original PR description
**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary. **Fix** Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page. Opw-4795941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small configuration error in the self-order testing setup was corrected. This helps keep automated checks reliable so issues in the customer self-order flow can be caught before release.
Original PR description
The test for the self-order feature was failing due to a validation error in the web_tour registry. The issue comes from the use of an unrecognized key 'test' in the tour configuration of 'self_order_pricelist'. This change removes the invalid 'test' key from the tour definition.
Installing Point of Sale no longer resets customized warehouse operation settings such as delivery barcodes, source locations, or sequence prefixes. This protects existing stock configurations when adding PoS or related apps, reducing unexpected setup changes for users.
Original PR description
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error:…
Installing PoS will change some values on existing operations types. To reproduce the issue 1. Install stock 2. Operations Types, edit Delivery: - Change the barcode 3. Install point_of_sale Error: the barcode of Delivery is reset When installing PoS, it will execute a generic method that creates and updates all operation types: https://github.com/odoo/odoo/blob/0bc90e7d74bd0792b9af7464256ba8770d894a25/addons/point_of_sale/data/point_of_sale_data.xml#L4 https://github.com/odoo/odoo/blob/14e9a698e333c3d6d2f7830353c34311de9ecb2c/addons/point_of_sale/models/stock_warehouse.py#L45-L50 https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L350-L356 Thanks to this, the PoS operation type will be created. However, as said in its docstring, the method will also update the existing operation types. For instance, for Delivery: https://github.com/odoo/odoo/blob/03478253c166238442d2f81f095de9fbcdfb265f/addons/stock/models/stock_warehouse.py#L1003-L1006 Its barcode and default source location will be reset. The update will also reset the sequence prefix. As said by the method name in PoS (`_create_missing_pos_picking_types`), the idea here is just to create missing PoS types. Similar issue with repair: the operations types of the user-created wh will be reset. OPW-4668505
The website shop payment form now consistently receives the related sales order information. This helps customizations and extensions work reliably when they depend on order details during checkout.
Original PR description
Before this commit, sale_order information were used in some payment form but only website_sale_order was available. This would cause issue in overrides. task 4808806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds test coverage for an issue where copying an invoice could unintentionally change the original invoice. This helps ensure future fixes protect existing accounting records from unwanted changes during duplication.
Original PR description
When duplicating an account move, the origin move shouldn't be modified. The reason for that is when `create` is called, operations are done on self, like check and sync balance, which is wrong. create is an `api.model` method and shouldn't alter the record if set. This PR doesn't include a fix, just tests that reproduces issue explained on ticket `#4823689` ping @william-andre --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Hungarian electronic invoice XMLs now use the currency conversion rate already stored for the invoice instead of an estimated rate. This prevents small rounding differences that could cause Hungary's NAV system to reject submitted invoices.
Original PR description
Problem --------- Currently, when generating the XML to send to NAV, the XML currency rate is computed using an MMSE estimator. This leads to approximation error itself leading to a slight difference from the rate applied and given by the MNB of Hungary for that day. This is noticed by the NAV upon submiting the invoice who returns an error. Objective --------- Make it so that the rate returned by the HU bank is used during the XML generation. Solution --------- Instead of computing a MMSE estimator, we get the conversion rate stored in the database at the time of the invoice. task-4707316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-ordering carousel test now uses the point-of-sale session's test mode instead of waiting for a timeout. This makes automated checks more stable and helps prevent false failures without changing the customer-facing experience.
Original PR description
In this commit: =============== - We use session.test_mode instead of relying on a timeout while testing the carousel in all self-ordering modes in test_self_order_pos_landing_page_carousel Runbot error: 226322
This fix makes an automated live chat check wait until the web client is fully ready before continuing. It reduces false failures in quality checks, helping keep live chat behavior stable without changing the user-facing experience.
Original PR description
runbot-error-108129 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
This fixes an issue where certain online sales configuration options could be hidden when the system could not determine whether the related view was enabled. The intended behavior is restored so the option remains visible by default, helping avoid missing choices during website purchase configuration.
Original PR description
commit 163b337fce6d3d67412f0e34e8120fbd5d02f463 didn't take into consideration that is_view_enabled can return None and the intended default behavior should be to show it by default --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users switch companies and open an asset created in another company. It adds a safeguard so accounting setup data that is unavailable in the current company does not cause the asset screen to crash.
Original PR description
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with…
**Steps to reproduce :** 1) Install Accounting and enable Analytic Accounting from the configuration. 2) Create an analytic plan under Accounting > Configuration > Analytic Plans. 3) Add a line with domain set to miscellaneous, applicability as mandatory and a prefix 4) Create an analytic account using the smart button on the plan. 5) Create an asset record in one company in a multi-company setup. 6) Switch to another company and try to access the asset created in the first company. **Issue:** A traceback occurs ``` AttributeError: 'bool' object has no attribute 'startswith' ``` **Cause:** - When switching companies, all the chart of accounts records code for the previous company, will set as False. - When accessing an asset record expects a account code to call .startswith(), but it fails when code is False. This leads to the above traceback. https://github.com/odoo/odoo/blob/5a321b2327e36f3250b33c669bdb8bb344ab4cbd/addons/account/models/account_analytic_plan.py#L64-L67 **Solution:** - Add a check to ensure that the account’s code exists before attempting to call .startswith(). This makes the code more robust across multi-company environments. opw-4745633
This update gives an internal messaging test more time to confirm websocket subscriptions, reducing occasional false failures when systems are under heavy load. It helps keep automated quality checks stable without changing customer-facing behavior.
Original PR description
The test "Message shows up even if channel data is incomplete" can occasionally fail, most likely due to high CPU usage. The websocket subscription check is timing out too early. Increase the timeout, as done in 18.1, to reduce the likelihood of such failures. runbot-224044
This update improves the spreadsheet tool by removing unused clipboard behavior and making moved rows or columns keep affected ranges aligned correctly. Users should see more reliable spreadsheet editing with fewer layout or formula range issues after reorganizing data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4cea5f8cd [FIX] clipboard: remove empty code Task: 4743039 https://github.com/odoo/o-spreadsheet/commit/1c33198f2 [FIX] MOVE_COLUMNS_ROWS: adapt range on col/row move Task: 4743039 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
When sending and printing invoices, Odoo now attaches only the invoice template selected for the customer instead of adding both the standard invoice and the chosen template. This avoids duplicate invoice attachments and ensures customers receive the intended document.
Original PR description
[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report…
[FIX] account: customer's default invoice template as only attachment Currently, when the user define an invoice template other than the standard 'account.account_invoices', both the standard report and the one defined by the user are attached to the mail when he hits the Send & Print. We want the template chosen by the user to be the one sent & printed. The fix is to remove the default accounting action report from the dynamic attachments : before, we were just removing the default action report used for the current move. But e.g. if the partner had a default report set in the field invoice_template_pdf_report_id, the default report for the move was this one, and so we weren't removing the accounting default one. This was causing the duplicate placeholder because the default accounting report placeholder is already processed in another method. Also, we remove the configuration that sets the 'account.account_invoices' report as a default dynamic attachment. Task-4681142 Runbot : https://runbot.odoo.com/runbot/bundle/18-0-invoice-report-per-partner-roto-361127
This fixes an access rights error that could appear when users searched for tasks from Timesheets. The change prevents the system from using task stage information that the current user is not allowed to access, making task search work more reliably for permitted users.
Original PR description
The sudo function allowed the current user to fetch data (stage IDs) which were used to browse. The user does not have access to this data; therefore, an access error message is triggered task-4194357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes internal HTTP-related tests less likely to fail because of harmless differences in text or URL formatting. It improves confidence in automated checks without changing product behavior for users.
Original PR description
**[FIX] test_http: make test_webjson_list_args reliable** The domain in the query-string is quoted by werkzeug, but there are multiple possible equivalent quoting strategy and the test sometimes fails because it is quoted differently. The test is not about testing the different quoting strategy, use a proper url parser to make the test more resilient. **[FIX] test_http: more reliable test_models3** The quote in the returned text sometimes get escaped, sometimes not, sometimes with a different QP code. Remove the quote, since the test is not about them, to make the test more reliable.
This fix adds the missing 'Error' status for Romanian E-Factura records so users can correctly see when an electronic invoice has failed. This helps businesses identify failed submissions more clearly and take follow-up action without confusion.
Original PR description
Description of the issue/feature this PR addresses: add missing 'Error' status to E-Factura selection 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
This update improves how Uruguayan electronic vendor bills are created from uploaded XML files and Uruware synchronization. It helps prevent duplicate or ambiguous records, supports files containing multiple invoices, and improves reliability by processing scheduled imports in smaller batches.
Original PR description
Task Adhoc side: 43467 1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE. Create those CFE. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests.
The rental search feature now sends product attribute filters using the parameter expected by the shop page. This ensures visitors who choose a rental attribute see correctly filtered results, improving the website shopping experience.
Original PR description
When selecting an attribute value in the Rental Search snippet, the generated URL incorrectly uses the `attrib` parameter. However, the `/shop` route expects the parameter to be named `attribute_value`. As a result, the filter is not applied, and the search results are not correctly filtered. This fix ensures consistency between the snippet and the `/shop` route by replacing `attrib` with `attribute_value`, so the attribute filter works as expected. The change improves the user experience by ensuring that search filters behave consistently across the website. Steps to reproduce: - Add the "Rental Search" snippet to a website page. - Configure it by selecting an attribute value. - Observe the resulting URL using `attrib`, which fails to filter results on the `/shop` page.
Helpdesk ticket satisfaction ratings now display the correct emoji face and color. This makes customer feedback easier to understand at a glance and avoids misleading rating indicators.
Original PR description
### Issue: `helpdesk.ticket` ratings were converted to emojis in https://github.com/odoo/enterprise/pull/42972, but currently do not display the correct color or face. ### Solution: Correctly check the value of `rating_avg_text` to determine which face should be shown, and remove class decoration that was recently added that hides the proper color. opw-4703331
This fix ensures loans using the "skip until" option show the correct remaining balance by counting earlier skipped payments as already accounted for. This prevents overstated outstanding loan amounts and gives finance teams more accurate loan reporting.
Original PR description
When using the 'skip until' option, we assume the early entries have been already posted elsewhere and their value should be accounted for. However, the outstanding balance of the loan will not keep into account skipped entries, resulting in an incorrectly higher amount, Steps to reproduce: - Create a new loan with: - Amount Borrowed: 24000 - Loan Date: 01/01/2024 - Duration: 48 months - Skip Until: 01/01/2025 - Compute (Duration of 4 years, Interest 1%) - Confirm Issue: Outstanding balance should be 16,105.73 and not 22,016.71 This occurs because, from the amount borrowed, the system subtracts only the posted entries amount, not considering the 'skip until' option opw-4711642
Users can no longer save a blank name when renaming a document or folder from the side panel. If the field is left empty, Odoo shows an error notification and restores the previous name, helping avoid confusing unnamed items.
Original PR description
Fix the possibility to enter an empty document name when editing a file or folder name from the side panel. If the name is empty, a danger notification should be displayed and the previous name should be restored. Task-4794447
Edited vendor payments now keep their original payment number when reposted, instead of receiving a new sequence number. This helps accounting teams maintain consistent records and avoid confusion or audit issues after correcting a payment.
Original PR description
**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than…
**Issue** When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than preserving the original. This issue only occurs when the Outstanding Payments account is configured for the journal. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Accounting > Configuration > Journals, and open a Bank journal. 3. In the Outgoing Payments tab, set an Outstanding Payments Account. 4. Go to Accounting > Vendors > Payments. 5. Create and post two vendor payments (e.g., 00001 and 00002). 6. Reset the first one (00001) to draft, change any field (e.g., amount), and repost it. 7. The number changes to 00003 instead of preserving 00001. **Root Cause** When a vendor payment is modified and reposted, Odoo cancels and regenerates the associated account.move. If an Outstanding Payments account is configured — or was configured at any point — this triggers additional logic causing the move name to be reset to '/'. This placeholder indicates that the move is treated as if it were new, prompting Odoo to assign it the next number in the journal’s sequence. As a result, the payment loses its original number even though it conceptually refers to the same transaction. **Fix** The fix ensures the original number is preserved by restoring the payment's previous name only when it's clear that the move is being regenerated, not newly created. This is determined by checking that the move is linked to exactly one payment (i.e., a one-to-one relationship) and that its name is '/', indicating the move was regenerated. Opw-4805870
Sending Colombian electronic invoices no longer fails when the Electronic Invoice Type field is left unset. This helps users complete invoice sending without encountering an unexpected error caused by missing optional invoice information.
Original PR description
Currently, sending an invoice can raise an error if the **Electronic Invoice Type** is not set on the invoice. **Steps to Reproduce:** - Install the `l10n_co_dian` module. - Change the default company to **CO Company**. - Create and confirm a customer invoice, but leave the **Electronic Invoice Type** unset. - Send the invoice. **Error:** `AttributeError - 'bool' object has no attribute 'rjust'` Here, an issue occurs because the system attempts to call `rjust()` on the field `l10n_co_edi_type` without ensuring it is a string. When the field is `False`, it results in an Attribute error. - [1] This commit ensures the right access to `rjust()` only when `l10n_co_edi_type` is a valid string, preventing the error. [1] - https://github.com/odoo/enterprise/blob/8d7a13822e9fd480a6e279ff93e29834a6668536/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L974-L975 Sentry - 6622171121
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 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#209471 Forward-Port-Of: odoo/odoo#208850
**Issue:** when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events **Steps to reproduce:** - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 Forward-Port-Of: odoo/odoo#210100
Original PR description
**Issue:** when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events **Steps to reproduce:** - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 Forward-Port-Of: odoo/odoo#210100
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice t
Original PR description
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's…
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice to be considered a TD05 instead of a TD01. The debit note used to take the document id of the original customer invoice, which is TD01. So `l10n_it_document_type` field is set as non-copy. A `debit_note` key is added in the mapping of invoice features to document features if the invoice is a debit note. - The tag in the XML template with the invoice linked to the debit note was changed based on requirements. Also, reference invoice name and date were added in XML if invoice is debit note. tasks-4744444 Current behavior before PR: - When uploading TD05 in the Purchase journal, it's considered a Vendor Credit Note. - When creating a debit note from a customer invoice, the new invoice has TD01 document type Desired behavior after PR is merged: - When uploading TD05 in the Purchase journal, it's considered a Vendor Bill. - When creating a debit note from a customer invoice, the new invoice has TD05 document type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209072
Requested by @cima-odoo Forward-Port-Of: odoo/odoo#211848
Original PR description
Requested by @cima-odoo Forward-Port-Of: odoo/odoo#211848
Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since readi
Original PR description
Description ----------- Upon importing contracts, in `_recompute_work_entries`, a wizard is created where we set the employee and a timeframe. The field `employee_ids` is a stored `Many2many` and upon reading its content, an active test is performed in `convert_to_record`, meaning that if the employee is archived, reading `employee_ids` would yield `[]`. This is problematic in `regenerate_work_entries` which therefore will search and write on *all* work entries in the timeframe, since reading `employee_ids` returns an empty list -> all employees. This commit adds a context key to take archived records when regenerating work entries. Reference --------- opw-4813590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212117 Forward-Port-Of: odoo/odoo#211748
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2. Select or create a product 3. Select or create an attribute and values 4. Archive the product 5. Go to the attribute page 6. Click on related products smart button 7. Set Archived filter 8. Observe that the archived product is not displayed. Expected Behavior: After applying the Archived
Original PR description
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2.…
**Issue** When displaying related products for a product attribute, only unarchived products are shown, even when the archived filter is applied. Steps to Reproduce: 1. Install the Sales app 2. Select or create a product 3. Select or create an attribute and values 4. Archive the product 5. Go to the attribute page 6. Click on related products smart button 7. Set Archived filter 8. Observe that the archived product is not displayed. Expected Behavior: After applying the Archived filter, related products, including archived ones, should be displayed. Actual Behavior: Archived related products are not shown, even when the Archived filter is applied. **Root Cause** When the related products smart button is clicked, the action_open_related_products method is triggered. In this method, when applying the domain for related products, an implicit active_test=True filter is applied by default. This filter excludes archived records, meaning only active (unarchived) products are displayed. **Fix** The issue was resolved by explicitly modifying the context to include archived products by setting active_test=False when querying the related products. This ensures that both active and archived related products are shown, even when the Archived filter is applied. opw-4565133 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201248 Forward-Port-Of: odoo/odoo#197513
Required for fixes in 18.0+ branches Forward-Port-Of: odoo/odoo#212403
Original PR description
Required for fixes in 18.0+ branches Forward-Port-Of: odoo/odoo#212403
Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate `Multi-Step Routes` from Settings. - Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`. - Delete the `Buy` route record. - Create a new product without adding vendors or defining routes. - Click on the `Replenish` button. - Observe the error. `AttributeError: '
Original PR description
Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate…
Currently, an error occurs when the replenish wizard is unable to find the default 'Buy' route, which the user may have deleted. Steps to produce: - Install the `purchase_stock` module. - Activate `Multi-Step Routes` from Settings. - Navigate to `Inventory > Configuration > Warehouse Management > Routes (list)`. - Delete the `Buy` route record. - Create a new product without adding vendors or defining routes. - Click on the `Replenish` button. - Observe the error. `AttributeError: 'NoneType' object has no attribute 'id'` The issue occurs when attempting to access the `id` of the 'Buy' route `purchase_stock.route_warehouse0_buy` - [1], without verifying if it exists. If this route is missing, `self.env.ref(...)` returns `None` which leads to an `AttributeError`. This commit resolves the issue by checking whether the `purchase_stock.route_warehouse0_buy` route exists before attempting to access its `id`. This prevents errors when the route is missing. [1] - https://github.com/odoo/odoo/blob/58f4b01dda6ba2e67c21663399aab1c189f4a312/addons/purchase_stock/wizard/product_replenish.py#L108 Sentry-6275025957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196959
Add the computed current year profit/loss to the balance sheet to have the full picture as expected Translation files were changed based on Odoo Export, so I guess the diff is ok as it will anyway appear with the next code change if created from the system. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#83875
Original PR description
Add the computed current year profit/loss to the balance sheet to have the full picture as expected Translation files were changed based on Odoo Export, so I guess the diff is ok as it will anyway appear with the next code change if created from the system. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#83875
Related to https://github.com/odoo/odoo/pull/211714 Forward-Port-Of: odoo/enterprise#86467 Forward-Port-Of: odoo/enterprise#86440
Original PR description
Related to https://github.com/odoo/odoo/pull/211714 Forward-Port-Of: odoo/enterprise#86467 Forward-Port-Of: odoo/enterprise#86440
Regarding Avatax, when the same tax appeared multiple times in the summary lines (e.g., with different tax types like Sales and Use), the computed amounts were not correctly summed in the result dictionary before. This fix ensures that duplicate tax entries are aggregated properly, avoiding incorrect totals. Steps to reproduce: - Difficult to reproduce without Avatax credentials. - Example: ``` { "country": "US", "region": "OH", "jurisType": "State", "jurisCode": "3
Original PR description
Regarding Avatax, when the same tax appeared multiple times in the summary lines (e.g., with different tax types like Sales and Use), the computed amounts were not correctly summed in the result…
Regarding Avatax, when the same tax appeared multiple times in the summary lines (e.g., with different tax types like Sales and Use), the computed amounts were not correctly summed in the result dictionary before.
This fix ensures that duplicate tax entries are aggregated properly, avoiding incorrect totals.
Steps to reproduce:
- Difficult to reproduce without Avatax credentials.
- Example:
```
{
"country": "US",
"region": "OH",
"jurisType": "State",
"jurisCode": "39",
"jurisName": "OHIO",
"taxAuthorityType": 45,
"stateAssignedNo": "",
"taxType": "Sales",
"taxSubType": "S",
"taxName": "OH STATE TAX",
"rateType": "General",
"taxable": -100.00,
"rate": 0.0575,
"tax": -5.75,
"taxCalculated": -5.75,
"nonTaxable": 0,
"exemption": 0
},
{
"country": "US",
"region": "OH",
"jurisType": "State",
"jurisCode": "39",
"jurisName": "OHIO",
"taxAuthorityType": 45,
"stateAssignedNo": "",
"taxType": "Use",
"taxSubType": "U",
"taxName": "OH STATE TAX",
"rateType": "General",
"taxable": -100,
"rate": 0.0575,
"tax": -5.75,
"taxCalculated": -5.75,
"nonTaxable": 0,
"exemption": 0
},
```
This fix simply ensures that the values of duplicate taxes are properly consolidated in the existing dictionary.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4801883)
opw-4801883
Forward-Port-Of: odoo/enterprise#86410Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration o
Original PR description
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed. Objective --------- Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level. Solution --------- Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default). task-4574971 Forward-Port-Of: odoo/enterprise#80116
This commit make the company field on the followup report invisible. opw-46693397 Forward-Port-Of: odoo/enterprise#86387
Original PR description
This commit make the company field on the followup report invisible. opw-46693397 Forward-Port-Of: odoo/enterprise#86387