Friday, June 27, 2025
28 changes · saas-18.1
Resolved issues and error corrections
This fix makes automated checks for starred messages more reliable by exposing the message's starred status directly in the page structure. It reduces false test failures in the mail area without changing the user experience.
Original PR description
Before this commit, test "test_star_message" was failing frequently on runbot at step to check message was starred have click on "Mark as Todo". This happens because when click on mark as todo, the message is asynchronously starred. However, there's no visual indication other than the message action have yellow filled star icon. This requires hovering the message to see it, but we don't know when we should exactly hover the message to see it. This commit fixes the issue by adding a `data-starred` on the `o-mail-Message` root node of message template that tells whether the message is starred or not. This removes necessity to hover to check whether message is starred. Fixes runbot-227568
When a subthread is created from a message that has been deleted, it now receives a clear placeholder name instead of appearing blank. This prevents confusion in discussions and makes conversation navigation more reliable for users.
Original PR description
**Current behavior before PR:** Prior to this PR, when a subthread was created from a deleted message, the thread name appeared empty. **Desired behavior after PR is merged:** the issue is resolved by setting the thread name to "New Thread" when the original message is deleted. task-4665143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce the bug: - Create two purchase orders and add a note - Try to merge them Problem: A traceback is triggered: ``` ValueError: AttributeError("'int' object has no attribute 'total_seconds'") while evaluating 'if records:\n action = records.action_merge()' ``` opw-4890120 Forward-Port-Of: odoo/odoo#215958
Original PR description
Steps to reproduce the bug:
- Create two purchase orders and add a note
- Try to merge them
Problem:
A traceback is triggered:
```
ValueError: AttributeError("'int' object has no attribute
'total_seconds'") while evaluating 'if records:\n
action = records.action_merge()'
```
opw-4890120
Forward-Port-Of: odoo/odoo#215958Moved quantity update logic into `handleOrderLineQuantityChange`for better readability, reuse and overrides. task-id: 4771749 enterprise PR: https://github.com/odoo/enterprise/pull/85137 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215465 Forward-Port-Of: odoo/odoo#209282
Original PR description
Moved quantity update logic into `handleOrderLineQuantityChange`for better readability, reuse and overrides. task-id: 4771749 enterprise PR: https://github.com/odoo/enterprise/pull/85137 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215465 Forward-Port-Of: odoo/odoo#209282
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute function](https://github.com/odoo/enterprise/blob/18.0/l10n_ke_edi_oscu_stock/models/account_move.py#L166) to the `product_id` field on invoice lines. The ORM triggers computes for all items in the chain - irrespective of whether the value was changed or not. Therefore, when the Kenya modules are installed, the `_compute_product_uom_id` function is triggered - which changes
Original PR description
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute…
This solves a runbot error occuring on the single l10n trigger for Kenya. Cause: l10n_ke_edi_oscu_stock adds a [compute function](https://github.com/odoo/enterprise/blob/18.0/l10n_ke_edi_oscu_stock/models/account_move.py#L166) to the `product_id` field on invoice lines. The ORM triggers computes for all items in the chain - irrespective of whether the value was changed or not. Therefore, when the Kenya modules are installed, the `_compute_product_uom_id` function is triggered - which changes the unit of measure. Solution: Improve the account.move.line's `_compute_product_uom_id` to only change the UoM when necessary. Considered Alternatives: - Whilst the l10n_ke_edi compute functions are not ideal - it was done because there was no PO/Bill matching feature at the time. Ideally these computes should be removed - but that would impact the stable policy and may have knock on effects. - changing the tests would simply hide issues arising from uom's and discounts. runbot-75230 Forward-Port-Of: odoo/odoo#215891
In this PR: - When activating an Online Payment provider that creates a payment.method.line in a journal, automatically assign an Outstanding account to the payment method. - Uses the existing Outstanding Account resolution method from Invoicing module to ensure consistency across the system. - Applied to all Online Payment Providers that rely on provider integration, excluding manual payment providers without external integrations. task-4826385 Forward-Port-Of: odoo/odoo#213554
Original PR description
In this PR: - When activating an Online Payment provider that creates a payment.method.line in a journal, automatically assign an Outstanding account to the payment method. - Uses the existing Outstanding Account resolution method from Invoicing module to ensure consistency across the system. - Applied to all Online Payment Providers that rely on provider integration, excluding manual payment providers without external integrations. task-4826385 Forward-Port-Of: odoo/odoo#213554
This commit fixes the non-deterministic `connection considered as lost after failed reconnect attempt` test. The monitoring service does not show the connection as lost when the navigator online property is false which makes this test fail when network is not available. This check makes no sense, it doesn't matter if we lost the connection because of a server/client error or because the network is down. This commit removes this check on the "online" navigator property and fixes this test. fix
Original PR description
This commit fixes the non-deterministic `connection considered as lost after failed reconnect attempt` test. The monitoring service does not show the connection as lost when the navigator online property is false which makes this test fail when network is not available. This check makes no sense, it doesn't matter if we lost the connection because of a server/client error or because the network is down. This commit removes this check on the "online" navigator property and fixes this test. fixes runbot-226892 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#216085
When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#215992 Forward-Port-Of: odoo/odo
Original PR description
When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#215992 Forward-Port-Of: odoo/odoo#215411
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single
Original PR description
To Reproduce ------------ - Accounting > Payments (Vendor or Customer) - On the list view, select multiple payment records - Action > Send Receipts by Email Problem ------- The email is sent, but the printed document is not set as the main attachment on the payment, as is the case when Sending a Receipt by Email from the payment's form view. Reason ------ mail does not behave in exactly the same way when sending one PDF report vs when sending a batch of documents ie, The single record uses `message_post` which calls `_message_set_main_attachment_id`. While in the case of a batch, it is not. Solution -------- Explicitly link `mail.message` attachments to the original `account.payment` record. Similar to what is done for `account.move` attachments that are linked to the `account.move.send` records. OPW-4500389 Forward-Port-Of: odoo/odoo#215899 Forward-Port-Of: odoo/odoo#202345
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added style="max-width: 100vw;" to table-responsive wrapper to enable horizontal scrolling on smaller screens. Steps to Reproduce: 1. Install the Expenses and Accounting modules. 2. Go to Settings → Search for Analytic Accounting → Enable it. 3. Add multiple analytic plans with sufficient data to cause horizontal
Original PR description
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added…
The analytic distribution table is not scrollable on mobile devices, resulting in hidden content and an unusable layout when there is horizontal overflow due to many columns. We added style="max-width: 100vw;" to table-responsive wrapper to enable horizontal scrolling on smaller screens. Steps to Reproduce: 1. Install the Expenses and Accounting modules. 2. Go to Settings → Search for Analytic Accounting → Enable it. 3. Add multiple analytic plans with sufficient data to cause horizontal overflow. 4. Navigate to Expenses → Open any record. 5. Open Inspect in your browser → Switch to mobile view. 6. Click on Analytic Distribution. <details><summary>Images</summary> <p> before FIX:  after FIX:  </p> </details> Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4805590) opw-4805590 Forward-Port-Of: odoo/odoo#212731
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_
Original PR description
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has…
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_id set The POL has the qty set to the min_qty of the invalid supplierInfo and the vendor code of that supplier info is not displayed. And if you further remove the invalid supplier info from the product page, the vendor code will be read and the POL qty will be the min_qty of the valid supplier info. This is because on creating a POL, two functions are got called, the first one is `_suggest_quantity` which suggests the initial quantity to set on the POL when the PO is created. This one is based on the minimum min_qty of all the supplierInfos related to the same product we are purchasing regardless if they are completely valid or not. Hence it chose the invalid supplierInfo min_qty. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/purchase/models/purchase.py#L1386C9-L1388C45 After the qty of the POL is set based on the `_suggest_quantity`, the `_compute_price_unit_and_date_planned_and_name` is called because it depends on the product_qty which calls the `_select_seller` function on the product. The `_select_seller` filters all the supplierInfo keeping only the valid ones BASED on the qty we are asking (so it eliminated the one with the smallest min_qty because the date_end is < PO.date and also the second one because the min_qty of the second_supplierInfo is > qty we are asking) ending up with empty list of supplierInfo to apply on our POL. Then the POL is set to the standard price and no vendor code is attached and read into it. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L616-L617 https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L603-L612 opw-4640937 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#205915
This **PR** enhances the default values for Hungarian electronic invoicing (EDI) by ensuring the delivery date is copied from the original invoice to the corresponding credit or debit note. **task**-4818819 Forward-Port-Of: odoo/odoo#216158 Forward-Port-Of: odoo/odoo#211860
Original PR description
This **PR** enhances the default values for Hungarian electronic invoicing (EDI) by ensuring the delivery date is copied from the original invoice to the corresponding credit or debit note. **task**-4818819 Forward-Port-Of: odoo/odoo#216158 Forward-Port-Of: odoo/odoo#211860
Following the fix in d927a7b6, we broke the default behaviour of empty text/chart fields. While the server returns the value `false` when they're empty, we want to display an empty string in the `ODOO.LIST` formulas. Task-4897690 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#215831
Original PR description
Following the fix in d927a7b6, we broke the default behaviour of empty text/chart fields. While the server returns the value `false` when they're empty, we want to display an empty string in the `ODOO.LIST` formulas. Task-4897690 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#215831
Issue -> For databases with large `account_move_line` tables, running the `_existing_accounting` (when opening Settings) method to check if a company has accounting entries by searching for any `account_move_line` records belonging to the current company is slow. The default search order for this model is `date desc, move_name desc, id`. This causes an index scan on the table using `account_move_line_date_name_id_idx`. The combination of using `date` to order by and the query planner using an
Original PR description
Issue -> For databases with large `account_move_line` tables, running the `_existing_accounting` (when opening Settings) method to check if a company has accounting entries by searching for any `account_move_line` records belonging to the current company is slow. The default search order for this model is `date desc, move_name desc, id`. This causes an index scan on the table using `account_move_line_date_name_id_idx`. The combination of using `date` to order by and the query planner using an unrelated index for the search leads to a long running SELECT query. Solution --> We replace the `search` with a `search_count` where the ordering doesn't matter and the order by clause is skipped. Benchmark --> On customers' database with about 30M move lines and 1 `res.company` record, speedup on the SELECT query is as follows --> 62743.883 ms -> 0.392 ms Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4811622) opw-4811622 Forward-Port-Of: odoo/odoo#215727
reproduction: 18.0+18.1: 1. In Todo, insert an inline image, and create a link including the image and some text 2. click on the text part, click edit button, modify the label area and click apply 3. the image is removed Test case 2: 1. go to Recruitment, and open an application and click "Send interview" 2. click on the link inside the template, change the url 3. apply, format of the button breaks 18.2: same flow with test case 2, click apply causing a traceback 18.3: same flo
Original PR description
reproduction: 18.0+18.1: 1. In Todo, insert an inline image, and create a link including the image and some text 2. click on the text part, click edit button, modify the label area and click apply 3.…
reproduction: 18.0+18.1: 1. In Todo, insert an inline image, and create a link including the image and some text 2. click on the text part, click edit button, modify the label area and click apply 3. the image is removed Test case 2: 1. go to Recruitment, and open an application and click "Send interview" 2. click on the link inside the template, change the url 3. apply, format of the button breaks 18.2: same flow with test case 2, click apply causing a traceback 18.3: same flow with test case 2, click on the link, do nothing and click away, the popover not close Fix: a partial back port of https://github.com/odoo-dev/odoo/pull/4633 The idea is that when the link doesn't only contain text, we don't show the label input field nor apply the label to the link. Because the label field extracts/display the text content of the link element, the field doesn't support html fragment, applying the label on a link including another element inside will break it. task-4881878 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215023
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://g
Original PR description
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within…
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L18 During recursion in `_compute_average_price`, the company context incorrectly reverts to the global company instead of preserving the original company context from the initial call. Recursive call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L77 Since the product is a kit, its cost is derived from its components. However, due to the incorrect company context switch, the purchase price is incorrectly set to 0 (because the product does not exist in the global company). This distorts sales margins in ongoing sales orders. Root Cause: The stock_moves passed into the method have env.company set to Company 1. At https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L66 bom_lines are extracted, inheriting the environment from stock_moves. As a result, _compute_average_price is executed within the context of Company 1, which may lead to incorrect computations when the intended company context is different. Fix: Ensure that stock_moves is explicitly passed into the method with the correct company context. This guarantees that the company context remains consistent throughout the execution, preventing unintended company switching. opw-4222976 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#215785 Forward-Port-Of: odoo/odoo#192890
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime". The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]` I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forwar
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362
Forward-Port-Of: odoo/enterprise#88730## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch the `datas` field (binary file content). This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch t
Original PR description
## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch…
## Issue
When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`.
### Analysis
The `write` override could unnecessarily fetch the `datas` field (binary file content).
This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch the binary content even when it was not needed.
## Solution
We leverage Python's boolean short-circuiting to ensure that this behavior is avoided.
### Benchmarks
Profiling peak memory consumption when moving 8 documents (66 Mb each) to the trash:
| Before | After | % |
|------------|------------| --- |
| 1.3 GiB | 96 Mb | - ~93% |
Query count when unlinking account.move (using Runbot data):
| Before | After |
|------------|------------|
| 66 | 72 |
(we may avoid these additional queries by prefetching the fields beforehand, let me know your thoughts)
```
[0.564 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3398)
[0.713 ms] query: UPDATE "ir_attachment"
SET "res_id" = "__tmp"."res_id"::int4, "res_model" = "__tmp"."res_model"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (3398, 117, 'documents.document', '2025-06-17T15:24:12.867699'::timestamp, 22)) AS "__tmp"("id", "res_id", "res_model", "write_date", "write_uid")
WHERE "ir_attachment"."id" = "__tmp"."id"
[0.305 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."res_model", "ir_attachment"."res_id", "ir_attachment"."res_field", "ir_attachment"."public", "ir_attachment"."create_uid" FROM "ir_attachment" WHERE ("ir_attachment"."id" IN (3397))
[0.666 ms] query: SELECT "account_move"."id" FROM "account_move" WHERE ("account_move"."id" IN (255)) AND ("account_move"."company_id" IN (10)) ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
[0.436 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3397)
[0.436 ms] query: SELECT "documents_document"."id", "documents_document"."attachment_id", "documents_document"."active" FROM "documents_document" WHERE ("documents_document"."attachment_id" IN (3397)) ORDER BY "documents_document"."id" DESC
```
### References
opw-4552436
Memory flamegraphs available on the ticket
Forward-Port-Of: odoo/enterprise#85020Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88563 Forward-Port-Of: o
Original PR description
Prior to this commit, the `_sla_generate_status_values` method in the `helpdesk.ticket` model was using a shared list for storing SLAs per ticket. This could lead to unexpected behavior when multiple tickets are processed simultaneously, as they would share the same list instance. We then removed that logic and replaced it by directly excluding the SLAs of the ticket status having a reached deadline, preventing unnecessary recomputation. Forward-Port-Of: odoo/enterprise#88563 Forward-Port-Of: odoo/enterprise#88341
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Original PR description
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#87520
Original PR description
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#87520
Steps to reproduce: - Install Purchase, Stock and Barcode apps - Create a product tracked by serial number - Create a PO of this product and confirm it (demand 3) - Open Barcode application for the PO's receipt - Start entering serial numbers for the 3 products - For each line, use the decrement button and remove all 3 lines - Make sure the last removed line is not the first scanned serial - Re-enter the serial number of the last removed line Issue: The parent line of the 3 sublines
Original PR description
Steps to reproduce: - Install Purchase, Stock and Barcode apps - Create a product tracked by serial number - Create a PO of this product and confirm it (demand 3) - Open Barcode application for the PO's receipt - Start entering serial numbers for the 3 products - For each line, use the decrement button and remove all 3 lines - Make sure the last removed line is not the first scanned serial - Re-enter the serial number of the last removed line Issue: The parent line of the 3 sublines has the lot_name fixed on the first scanned serial_number. So when decrementing the last_line, it will always use the virtual_id of the first serial_number scanned, leading to decrementing the wrong serial number. It starts showing that the next scanned number is already used, because it wasn't properly removed in the first place. opw-4646765 Forward-Port-Of: odoo/enterprise#88130
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459 Forward-Port-Of: odoo/enterprise#88113
Original PR description
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459 Forward-Port-Of: odoo/enterprise#88113
Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88593 Forward-Port-Of: odoo/enterprise#88261
Original PR description
Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88593 Forward-Port-Of: odoo/enterprise#88261
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined in `l10n_co_dian` module, and the workflow in the module also depends[[1]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_invoice.py#L9)[[2]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co
Original PR description
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined…
The module `l10n_co_edi_mandate` [inherits](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_edi_xml_ubl_dian.py#L5) a model defined in `l10n_co_dian` module, and the workflow in the module also depends[[1]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/account_invoice.py#L9)[[2]](https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_co_edi_mandate/models/product_template.py#L8) on DIAN being installed. Both modules have the same dependency `l10n_co_edi` and are autoinstalled. This can easily break if the user chooses to uninstall the dian module. The module will fail to install if dian is not installed. The uninstall of the dian module will also cause an error if this module is installed. The upgrade will fail if the user has dian uninstalled (edi_mandate is a new module and will try to autoinstall) This fix makes the dependency explicit. Forward-Port-Of: odoo/enterprise#88607
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: -
Original PR description
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: - Use the correct default account codes directly (101403, 101404) - Avoid reassignment of codes that are now created by the CoA template task-4826385 Forward-Port-Of: odoo/enterprise#88068
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a closing entry for the tax report 3) Open the miscellaneous Operations from Accounting Dashboard 4) Open the above-created entry by removing the default filter 5) Post the closing entry, a wizard opens. 6) Validate the values. 7) A traceback appears **Error:** ``` account.journal' objec
Original PR description
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a…
Currently a traceback is occurring when the user tries to post a journal entry from journal dashborad. **Steps to reproduce:** 1) Install `l10n_it_xml_export` and switch to IT company 2) Create a closing entry for the tax report 3) Open the miscellaneous Operations from Accounting Dashboard 4) Open the above-created entry by removing the default filter 5) Post the closing entry, a wizard opens. 6) Validate the values. 7) A traceback appears **Error:** ``` account.journal' object has no attribute '_get_report_options_from_tax_closing_entry' ``` **Cause:** When the user tries to post the closing entry from the accounting dashboard, its active_model is `account.journal`, and the active_id should be the current id of the miscellaneous journal. This leads to the above traceback, as the method `_get_report_options_from_tax_closing_entry` is not available in account.journal. **Solution:** To resolve this issue, we can browse the current move from the `ctx['l10n_it_moves_to_post']`, since the value of the `l10n_it_moves_to_post` is also self.ids. Which is the current active id for that closing entry. https://github.com/odoo/enterprise/blob/3d89d9fe6be8e789278dee9bc706e091ee5a0ec5/l10n_it_xml_export/models/account_move.py#L19 opw-4783958 Forward-Port-Of: odoo/enterprise#87391 Forward-Port-Of: odoo/enterprise#86791
Steps to reproduce - install `industry_fsm_sale_subscription` - go to settings -> enable `recurring task` - create product with following configs : * enable `subscription` * product type : `service` * create on order `task` * project `Field service`  - create a SO with this product - go to `Tasks` smart button - select the task and mark it done - ope
Original PR description
Steps to reproduce
- install `industry_fsm_sale_subscription`
- go to settings -> enable `recurring task`
- create product with following configs :
* enable `subscription`
* product type : `service`
* create on order `task`
* project `Field service`
- create a SO with this product
- go to `Tasks` smart button
- select the task and mark it done
- open the second task, from "recurring tasks" smart button
Obervation: in newly created task `Sales Order Item` is not linked
Issue:
- after this commit odoo/enterprise@be201cd ,sale fields are not copied for fsm task. while this is true for simple tasks, we would require such fields to be copied for recurrence tasks
Fix:
- allow sale fields to be copied for recurring tasks
opw-4875830
Forward-Port-Of: odoo/enterprise#88108