Friday, May 9, 2025
98 changes · saas-18.3
Enhancements to existing features
The chatter component can now tell its parent screen to refresh when an activity is added, changed, or deleted. This helps areas such as bank reconciliation keep related record information up to date immediately after users manage activities.
Original PR description
The aim of this commit is adding a new props for the chatter component. By adding this props, the parent view will be reloaded when an activity is added, modified or deleted in the chatter. This change is necessary for the bank reconciliation widget where we want to update a specific record when a user adds a new activity in the chatter. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor now keeps a complete record of all editor versions, including versions introduced by related modules such as Knowledge. This helps keep content upgrades consistent regardless of which optional modules are installed.
Original PR description
Any modules (most notably Knowledge) can register new html_editor versions. To ensure the version consistency no matter if the Knowledge module is installed or not, every version should be registered in the `html_editor` manifest, even if they do not apply any change in the `html_editor` itself. task-4718129
The Live Chat channel rules list now shows the related chatbot, making chatbot setup easier to review and manage. This helps teams quickly see which chatbot is tied to each rule without opening individual records.
Original PR description
Add a new chatbot field in the rule's tree view to improve visibility and management of chatbot configurations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The bank reconciliation account search now filters by account type instead of a broader internal grouping. This prevents unrelated other income and other expense accounts from appearing, helping users choose the correct account more easily.
Original PR description
This commit will change the current filter to use account type instead of internal_group to avoid including "other income" and "other expense" task: 4749344
VoIP contact search now handles names containing joined letters such as IJ, œ, or æ when converting them for keypad dialing. This makes it easier for users to find and call contacts with international or special-character names.
Original PR description
Expand ligatures (IJ, œ, æ...) to their constituent letters, so that they can be converted to T9.
This update adds missing checks to make sure the return period filter behaves correctly in financial reports. It helps reduce the risk of reporting inconsistencies when the return period matches a standard date filter.
Original PR description
Added missing tests for the return period filter. Mainly testing the fallback to normal filter in case it is aligned to a normal date filter.
Resolved issues and error corrections
Time Off Responsible users can now access the overview consistently with the permissions they already have in the management menu. This prevents unnecessary access issues and helps responsible staff review time off information as expected.
Original PR description
- Align Time Off Responsible overview rights with his rights in the managment menu views Task: 4752362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo Client Error window appears **Cause of the issue:** Inside the counted quantity widget's useEffect, When adding the event listener "this.onInput.bind(this)" creates a new function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/s
Original PR description
**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo…
**Steps to reproduce:** - Create a new product storable product - Open Inventory/Operations/Physical Inventory - Add a new line - Choose your product - Click on History **Current behavior:** An Odoo Client Error window appears **Cause of the issue:** Inside the counted quantity widget's useEffect, When adding the event listener "this.onInput.bind(this)" creates a new function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L18 when removing the event listener "this.onInput.bind(this)" creates another function reference https://github.com/odoo/odoo/blob/4775c0ff640c4a092c7430a03f6324659b9bbca4/addons/stock/static/src/widgets/counted_quantity_widget.js#L22 As a consequence the event listener is not properly removed **Fix:** If the new function reference is created before in a variable the same function reference will be passed the two times and it will be properly removed opw-4711101 Forward-Port-Of: odoo/odoo#206478
This change updates internal stock tests so they correctly enable the setting needed for lots and serial numbers when demo data is not present. It helps keep automated quality checks reliable without changing day-to-day user workflows.
Original PR description
The tours test_generate_serial_1 and test_generate_serial_2 were broken because the demo data is no longer used in the tests. Using demo data, the option "Lots & Serial Numbers" is enabled by default. This option have to be enabled for the test. [Runbot error 160956](https://runbot.odoo.com/odoo/error/160956) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Call controls now show the existing mute and deafen keyboard shortcuts when users press Alt to view available shortcuts. This makes the shortcuts easier to discover during calls without changing the underlying call behavior.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/204663 PR above add the new feature to quickly mute and deafen through hotkey `shift+m` and `shift+d`. While this works, the discovery of feature is poor, due to ALT not promoting them. This commit fixes the issue by adding the `data-hotkey` on call actions that have these hotkeys, so that they are shown when pressing ALT to display all available hotkey.
This fix ensures that clicking a channel in the live chat reporting graph takes users to the main discuss channel list instead of the reporting list. It reduces navigation confusion and helps users reach the operational channel view they expect.
Original PR description
Clicking on the report channel graph view should redirect to the discuss channels list, not the report one. task-4775828 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Belgian localization updates the name of the bank fees reconciliation model by removing unnecessary parentheses. This makes the label cleaner and easier to read for users without changing functionality.
Original PR description
This commit will change the name of the Bank fees reco model to remove the parenthesis no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how the Peppol account integration handles single-record operations, reducing the chance of errors in electronic invoicing workflows. The change is internal and helps keep Peppol-related accounting processes stable without altering user-facing features.
Original PR description
task-no
This fix prevents Odoo from crashing when session token details cannot be computed for an invalid or non-existing user. Instead, the session is safely expired, improving reliability for edge cases without changing normal user behavior.
Original PR description
- In the case `_session_token_get_values` returns `False`, before this commit the code crashes as it wasn't expecting to handle something else than an iterable as `field_values`.
The bug was introduced by the commit 3fbd74b3bb7af2b9bc9c86fddc78771ec97ce740 Before this commit, falsy values where correctly handled. We introduce the same behavior to fix the issue.
- Added a test to check that computing session on non existing user do not crash and correctly expires the session.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a view configuration issue in the stock delivery area that could prevent the product form from loading correctly. It improves reliability for users managing delivery-related product settings without changing business workflows.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The review comment button now behaves consistently: clicking it a second time closes the comment box instead of replacing the review content. This prevents confusion for website visitors and makes course review interactions feel more predictable.
Original PR description
**Steps to Reproduce:** - Open website > course - Click on `Review` tab - Click on `Comment` button below any review - Again click on `Comment` button **Before PR:** - Upon clicking the `Comment` button a second time, the composer should close instead of replacing `Review`. **After PR:** - Composer is closed when the `Comment` button is clicked a second time. task-4715179 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The account selector now displays account names correctly after a formatting change from HTML line breaks to standard line breaks. This prevents confusing or poorly formatted account labels for users choosing accounts.
Original PR description
https://github.com/odoo/odoo/commit/29f7475437586363e473955315d74aef7d80028c changed the markdown syntax from `<br>` to `\n` Adapt the compute display name to the new format
Belgian accounting templates now assign purchase taxes as the default on the affected accounts instead of sales taxes. This helps ensure supplier-related transactions use the right tax setup by default, reducing manual corrections and reporting errors.
Original PR description
Fix the default taxes on accounts. They should be purchase taxes and not sales taxes. No task (verbal report)
This fixes an issue where clicking a comment button twice in portal course discussions could accidentally open the message editor instead of simply closing the comment box. It keeps the comment experience predictable for users reviewing or discussing eLearning content.
Original PR description
Since odoo/odoo#202366 the editing state of the message is no longer used and the edit mode relies on checking the availability of the message composer. Clicking on a comment button opens a composer on the message. When clicking again on this button if we don't remove that composer from the message, the message is assumed to be in edit mode. Steps to reproduce: - Install a module that uses the comment feature such as elearning - Go to the portal view of a course as admin - In the chatter click on a comment button below a message - Without saving or canceling the comment, click on the comment button again - The comment composer is closed but an edit composer in the message is opened
The chat and discussion welcome area now has better-proportioned avatars and spacing when a new channel or sub-thread is created. This creates a more consistent and polished experience across the messaging interface.
Original PR description
When creating a new channel or sub-thread, it decorates the conversation with a welcome text with avatar / icon of conversation. This commit make small tweaks to this part of UI: - discuss app avatars / icons were too big, now reduced slightly - chat window spacing with conversation name was too small, now made as big as in discuss app - avatar was not as rounded as other avatars in discuss
Opening the Activity Overview from Settings in debug mode no longer triggers an error. This improves reliability for administrators using technical activity management screens.
Original PR description
This fix addresses a traceback that occurred when accessing the Activity Overview from the Settings menu in debug mode. Steps to reproduce: 1.Enable debug mode. 2. Go to Settings > Technical > Activities > Activity Overview. 3. Click on the "Activity Overview" a traceback appears. The issue was caused by an empty js_class being passed in the mail_activity_view_tree. Task-4770921
This fixes outdated wording shown in validation checks for EC Sales List returns. The change helps users see the intended messages and avoids confusion caused by an earlier merge issue.
Original PR description
A bad conflict management in https://github.com/odoo/enterprise/commit/689bfdcb40c0d57a3d941f32322986a0a7e7d2f5 caused some old phrasing of the checks to be used instead of the one we wanted.
This fix keeps the number of bank reconciliation items per customer or vendor up to date, including when the last item for a partner is cleared. It helps accounting users see accurate reconciliation queues after deleting or completing reconciled lines.
Original PR description
The aim of this commit is making sure that we update the reconcileCountPerPartnerId properly. Before this commit, the code was only updating partner id who still have line to reconcile. It was wrong as we want to update a partner who doesn't have a line to reconcile anymore. In the meantime, we're now calling the function who reloads the count when we delete a reconciled line. task-4782264
This fixes an automated test in the barcode picking workflow so it waits for the final screen to finish loading before the browser closes. The change helps prevent false test failures, improving confidence in delivery checks without changing user-facing behavior.
Original PR description
In this commit we fix the tour test_open_picking_dont_override_assigned_user. At the end of tour, we don't wait until kanban is fully rendered. If the browser is closed before this view is rendered, the error onWillStart: "Component is destroyed" can occurs error-runbot-id~190611
The access rights label for the Referrals app has been corrected from “Recruitment” to “Referrals.” This makes user permissions clearer for administrators and avoids confusion when assigning access.
Original PR description
In the access rights section, referrals group was labelled "Recruitment". The security group has been renamed to "Referrals". Task: 4771561
Users can now enter chat commands such as "/who" in chats or channels without causing a crash. This keeps conversation tools reliable and prevents interruptions when using built-in command shortcuts.
Original PR description
**purpose of this PR:** Entering commands such as "/who" or similar in a chat or channel previously caused a crash. the issue has been resolved by updating the message posting flow to ensure that commands are processed correctly. community: https://github.com/odoo/odoo/pull/209064 task-[4759888](https://www.odoo.com/odoo/project/1519/tasks/4759888)
Small visual refinements were made to the manufacturing work order display, including clearer onboarding imagery, cleaner worksheet dialogs, and less confusing operator styling. These changes improve day-to-day usability for shop floor teams without changing core manufacturing workflows.
Original PR description
- review the onboarding image & annotations - review the start button to avoid double primary - worksheet instruction dialog uses default dialog header - removed the lock operator styling follow-up task-4346172
Knowledge articles can store embedded views and saved filters inside their content. This fix updates those stored settings during upgrades so shared favorite filters continue to work correctly after the underlying filter field changed.
Original PR description
[This commit] modified the `ir.filters` `user_id` field into `user_ids`. In Knowledge embedded views (and links), the `SearchModel` state and some custom favorite filters are stored inside a html attribute of the body of an article, therefore they are not properly upgraded with the standard python script. This commit introduces a JS upgrade script to modify these values. `user_id` is converted to `user_ids` with an empty array as a value (which means that the filters are always "shared with everyone"). The field has to be modified both in the custom favorites and in the stored `SearchModel` state. [This commit]: https://github.com/odoo/odoo/commit/414e55cf7c3971a7ba0a7c96855db4c23e77a5c4 task-4718129
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master.
Original PR description
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. opw-4629332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205501
Before this commit, when connecting to the IoT box access point on some devices (e.g. Android phone), there would be no popup to sign in to the network. Instead, the user would have to manually navigate to any URL, which would then load the IoT box homepage. After this commit, all HTTP requests on the access point will send a 301 redirect to the IoT box homepage. When Android sees that it gets redirected, it interprets this as a login page and triggers the 'sign-in' popup. In this commit w
Original PR description
Before this commit, when connecting to the IoT box access point on some devices (e.g. Android phone), there would be no popup to sign in to the network. Instead, the user would have to manually navigate to any URL, which would then load the IoT box homepage. After this commit, all HTTP requests on the access point will send a 301 redirect to the IoT box homepage. When Android sees that it gets redirected, it interprets this as a login page and triggers the 'sign-in' popup. In this commit we are also refactoring the structure of the nginx config files. Previously, we had configuration both in `/etc/nginx/nginx.conf` and `/etc/nginx/sites-enabled/default`. Now, we are using the modern structure of simply adding our config in the `/etc/nginx/conf.d/` folder. In addition, some redundant settings were removed to simplify the config. task-4724110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209104
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark > Choose Dark theme. <b>Issue:</b> Website Shop, when using a dark background, the text in write a message box and comment bubbles in reviews sections becomes white making it invisible. <b>Cause:</b> In light mode, the text appears black, making it easy to read. However, when switching to
Original PR description
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark >…
<b>Steps to reproduce:</b> 1. Website > shop > Open any product > Open Editor(Edit) 2. Customize → Navigate to Customer → Click on Rating. 3. Theme → Navigate to Colors → Navigate to Light & Dark > Choose Dark theme. <b>Issue:</b> Website Shop, when using a dark background, the text in write a message box and comment bubbles in reviews sections becomes white making it invisible. <b>Cause:</b> In light mode, the text appears black, making it easy to read. However, when switching to dark mode, the text changes to white, which makes it difficult to read against the light bubble background. <b>Solution:</b> This commit adds class text-black to the comment and description container to improve the visibility. <b>opw : 4724764</b> <b>BUG:</b>    <b>FIX:</b>    Forward-Port-Of: odoo/odoo#208473 Forward-Port-Of: odoo/odoo#206803
## Version: 18.0+ ## Issue: Total section on Purchase Order document is misaligned. ## Steps to reproduce: - Go to Purchase: - Open a purchase order record; - Click on Print > Purchase Order. ## Cause: Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 ## Fix: Full style reverting opw-4771854 Forward-Port-Of: odoo/odoo#209084
Original PR description
## Version: 18.0+ ## Issue: Total section on Purchase Order document is misaligned. ## Steps to reproduce: - Go to Purchase: - Open a purchase order record; - Click on Print > Purchase Order. ## Cause: Fix in Sale app changing report styles without considering Purchase app: https://github.com/odoo/odoo/commit/344007299c91d990c851ad9ed6f7fb5f8aa7a273 ## Fix: Full style reverting opw-4771854 Forward-Port-Of: odoo/odoo#209084
**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation. If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will
Original PR description
**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet…
**Problem:** The problem happens when a service is linked to a task but it's not billed on timesheet. If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation. If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will erase it and set the value back to the standard price of the product. Because the service is not billed on timesheet we don't want a modification of timesheet to affect the cost set on the quotation. **Steps to reproduce:** - In settings, activate the "margins" setting in Sales - Open Sales/products and create a new product - Set the product type as "Service" - Set the "create on order" field as Task - Set the "project" field to an existing project - Set a strictly positive value in the cost field - Set a name and save - Create a new quotation and add the product you just created - Confirm the quotation - In the order lines page, add the cost column - Change the value of the cost column - Click on the "Tasks" smart button - Add a new timesheet in the timesheet page and save - Come back to the sale order via the smart button **Current behavior:** The value of the cost column was reset the the cost of the product **Expected behavior:** Mofifying the timesheets shouldn't impact the cost of a service which is not invoiced on timesheets **Cause of the issue:** Because the sale_timesheet_margin module is installed the _compute_purchase_price method is overriden and depends on analytic_line_ids.amount https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L8 when this method is called in our flow, because sol.product_id.purchase_price is not null our sale order line will not get filtered out https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L11 and it will reach the original _compute_purchase_price method were the value of purchase_price will be reset to the value of self.product_id.standard_price https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_margin/models/sale_order_line.py#L30 **Fix:** We want to filter out the sale.order.lines for which the computation of purchase_price has been triggered via the analytic_line_ids.amount dependency and for which we don't want the computation to happen (when the service_policy is not "timesheet"). We need to do this without filtering out the sales.order.lines for which the computation of purchase_price has been triggered by a dependency from the original compute_purchase_price method https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_margin/models/sale_order_line.py#L20-L21 or another orverride of this method (for now there are two of those : one in sale_expense_margin https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_expense_margin/models/sale_order_line.py#L10-L11 and one in sale_stock_margin https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_stock_margin/models/sale_order_line.py#L10-L11 ) is_expense is defined in the sale module is_service is defined in the sale_service module service_policy is defined in the sale_project module all those field are available when sale_timesheet_margin is installed opw-4627037 Forward-Port-Of: odoo/odoo#208196 Forward-Port-Of: odoo/odoo#205415
'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity. # How to Reproduce - Create Subcontract BoM, with 1 cmp at $10 - Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10) - Scrap 1 unit of finished product => Journal ent
Original PR description
'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the…
'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity.
# How to Reproduce
- Create Subcontract BoM, with 1 cmp at $10
- Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10)
- Scrap 1 unit of finished product => Journal entry for scrapped layer contains 3 AML instead of 2 => The additional cost is incorrectly added to the Stock Valuation account, making the line balance at -$30, while the layer is still at -$20
OPW-4640650
---
Test result without fix:
```
2025-04-24 09:26:06,083 18424 ERROR oes_test_17 odoo.addons.mrp_subcontracting_account.tests.test_subcontracting_account: FAIL: TestAccountSubcontractingFlows.test_subcontracting_account_flow_1
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_subcontracting_account/tests/test_subcontracting_account.py", line 174, in test_subcontracting_account_flow_1
self.assertRecordValues(amls, [
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/tests/common.py", line 667, in assertRecordValues
self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
Wrong number of records to compare: 3 records versus 2 expected values.
==== Differences at index 0 ====
---
+++
@@ -1,3 +1,3 @@
-account_id:300
-debit:60.0
-credit:0.0
+account_id:301
+debit:0.0
+credit:60.0
==== Differences at index 1 ====
---
+++
@@ -1,2 +1,2 @@
-account_id:299
-debit:30.0
+account_id:300
+debit:60.0
==== Additional record ====
{'account_id': 301, 'credit': 90.0, 'debit': 0.0, 'product_id': 107}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207204Before this commit, the second and onwards view of the product screen will pull and sort products by the data stored in IndexedDB. The first load of the product screen sorts based on a SQL query, whose sorting may be lost on sequential loads of the product screen. This change maintains the sort sequence to 'product.template' when loading the product screen when IndexedDB exists in the browser. opw-4584724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su
Original PR description
Before this commit, the second and onwards view of the product screen will pull and sort products by the data stored in IndexedDB. The first load of the product screen sorts based on a SQL query, whose sorting may be lost on sequential loads of the product screen. This change maintains the sort sequence to 'product.template' when loading the product screen when IndexedDB exists in the browser. opw-4584724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205549 Forward-Port-Of: odoo/odoo#201640
Issue: On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings
Original PR description
Issue: On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these…
Issue:
On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings on the first page takes 8 to 10s.
One of the issues found when analyzing the issue is that the 3 SQL queries performed on stock_move in the beginning of _get_report_lines are slow:
```
past_outs = self.env['stock.move'].search(AND([out_domain, past_domain]), order='priority desc, date, id')
future_outs = self.env['stock.move'].search(AND([out_domain, future_domain]), order='reservation_date, priority desc, date, id')
outs = past_outs | future_outs
ins = self.env['stock.move'].search(in_domain, order='priority desc, date, id')
```
Further analysis and testing show that using a domain with a negative condition ('not in') on the `state` column of stock_move prevents PostgreSQL from using the existing index on that column. By changing the condition in the domain to use a positive condition on that column, the execution time of each of the three queries goes from 1000-1500ms to about 100ms, saving about 3s on the total loading time of the page, which is still slow but a bit less.
Without patch:
```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 3.907 4.824
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 3.998 5.284
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 4.246 5.725
```
With patch:
```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 0.619 4.639
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 0.643 5.143
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 0.862 5.618
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207022In the lead generation form view, the widget that allows the user to select a filter currently spans into the label column in the grid, causing it to appear squished. To ensure it occupies the entire row properly, we will add the colspan="2" attribute to the field definition. Task-4750253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207480
Original PR description
In the lead generation form view, the widget that allows the user to select a filter currently spans into the label column in the grid, causing it to appear squished. To ensure it occupies the entire row properly, we will add the colspan="2" attribute to the field definition. Task-4750253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207480
This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed. Forward-Port-Of: odoo/odoo#209004
Original PR description
This commit fixes the position and update the color being used in the both SVG and PNG versions of the icon. The main #714B67 color is now used and everything is centered. The shadow has been removed. Forward-Port-Of: odoo/odoo#209004
This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#207355 Forward-Port-Of: odoo/odoo#195958
Original PR description
This PR refactors `_create_backorder `for better extensibility. Related: https://github.com/OCA/manufacture/pull/1467 @qrtl QT5016 Forward-Port-Of: odoo/odoo#207355 Forward-Port-Of: odoo/odoo#195958
The electronic format field should not be displayed in the portal when no option is available for it. Steps to reproduce: ------------------- * (The reported flow was using PoS) * Install the l10n_mx_edi_pos module * Create a PoS and use the self invoicing feature * Make an order and pay for it * On the ticket scan the QR Code and access the invoice portal > Observation: The electronic format field is displayed in the portal but it is empty Why the fix: ------------ We hide the f
Original PR description
The electronic format field should not be displayed in the portal when no option is available for it. Steps to reproduce: ------------------- * (The reported flow was using PoS) * Install the l10n_mx_edi_pos module * Create a PoS and use the self invoicing feature * Make an order and pay for it * On the ticket scan the QR Code and access the invoice portal > Observation: The electronic format field is displayed in the portal but it is empty Why the fix: ------------ We hide the field when no value is available for it. opw-4628351 Forward-Port-Of: odoo/odoo#208904 Forward-Port-Of: odoo/odoo#208124
Steps to reproduce: 1) Publish one dm 2) Enable extra step 3) As a public user add a deliverable product and checkout 4) Fill in an address and submit it 5) It will skip delivery and proceed to payment 6) Try to pay Reason: address_submit redirects to extra_info instead of checkout skipping setting a dm Solution: Remove redirect to extra_step opw-4711750 Forward-Port-Of: odoo/odoo#208974
Original PR description
Steps to reproduce: 1) Publish one dm 2) Enable extra step 3) As a public user add a deliverable product and checkout 4) Fill in an address and submit it 5) It will skip delivery and proceed to payment 6) Try to pay Reason: address_submit redirects to extra_info instead of checkout skipping setting a dm Solution: Remove redirect to extra_step opw-4711750 Forward-Port-Of: odoo/odoo#208974
This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO. task-id: 4750146 Forward-Port-Of: odoo/odoo#208836 Forward-Port-Of: odoo/odoo#207270
Original PR description
This commit modifies the condition for the Peppol information footnote to be added to the mail to be only when the country of both the company and the partner is one of the following: BE/LU/NL/SE/NO. task-id: 4750146 Forward-Port-Of: odoo/odoo#208836 Forward-Port-Of: odoo/odoo#207270
When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing
Original PR description
When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing a unique constraint violation if the same name already exists. This PR removes `default_name` from the context. Task-3901336 Forward-Port-Of: odoo/odoo#208362
Description ----------- Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`. Benchmark: ---------- On odoo.com, unlinking an expense took: | Before | After | |--------|-------| | 10s | 58ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po
Original PR description
Description ----------- Deleting an expense is slow when the `account_move_line` table is large, as the `Many2one`/`fkey` `expense_id` needs to be set to `NULL` where necessary. If there is no index on the `fkey`, it's `Seq. Scan` on the table `account_move_line`. Benchmark: ---------- On odoo.com, unlinking an expense took: | Before | After | |--------|-------| | 10s | 58ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208875
When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error because the original invoice number, UUID, and amount are required. This commit restricts the users from sending independent credit notes to JoFotara. It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note. task-4756603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward
Original PR description
When an independent (not linked to an invoice) credit note is submitted to JoFotara, the portal would throw an error because the original invoice number, UUID, and amount are required. This commit restricts the users from sending independent credit notes to JoFotara. It also gives the users the flexibility (in debug mode) to link an invoice to an independent credit note. task-4756603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208276
Forward-Port-Of: odoo/odoo#207024
Original PR description
Forward-Port-Of: odoo/odoo#207024
Before this commit, we were using the local timezone for comparing orders in self order. This lead to issues because the server is in UTC and the client is in local timezone. This commit changes the behavior to use UTC for the comparison. This means that the orders will be compared in UTC, regardless of the local timezone of the client. Forward-Port-Of: odoo/odoo#208867
Original PR description
Before this commit, we were using the local timezone for comparing orders in self order. This lead to issues because the server is in UTC and the client is in local timezone. This commit changes the behavior to use UTC for the comparison. This means that the orders will be compared in UTC, regardless of the local timezone of the client. Forward-Port-Of: odoo/odoo#208867
Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`. opw: 4744418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw
Original PR description
Similar fix as what has already be done in this following commit: https://github.com/odoo/odoo/commit/483024d122565523a8f1788201ecce47c6d1dfd0 In multi-company setups, `product.template` records can be shared, but access to `res.company` may be restricted. To avoid access errors when computing `product.template.cost_currency_id`, use `sudo()` when reading `company_id.currency_id`. opw: 4744418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208752
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` cl
Original PR description
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used…
Before this commit odoo/odoo@5bb76504425082cfd654a2860350aa94d9782dbd, the update query for UUID deduplication used [cr.split_for_in_conditions()](https://github.com/odoo/odoo/blob/13133b40eb545c4d4f7427c2145b3d57074fa74b/odoo/sql_db.py#L402-L405) to chunk IDs properly for the `WHERE id IN (...)` clause. However, after the mentioned commit, all IDs are passed at once, especially when `fetchmany()` returns up to 1 lac records. This significantly slows down the update query due to large `IN` clauses and memory overhead. To address this, reduce the processing chunk from 1lac to 10k IDs. This reduces update time from over 2 hours to under 10 minutes in practice for recordset shown below: ```sql apan_2760231=> select count(*) from pos_order; count -------- 146885 (1 row) apan_2760231=> select count(*) from pos_order_line; count -------- 378860 (1 row) apan_2760231=> select count(*) from pos_payment; count -------- 184679 (1 row) ``` Logs: Before fix (Almost 3 hrs): ```py 2025-04-17 07:06:31,094 31 INFO db_2760231 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 10:08:39,397 31 INFO db_2760231 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` After fix (reduces to 10 mins): ```py 2025-04-17 11:29:44,294 23 INFO apan_2760231_18.0 odoo.modules.migration: module point_of_sale: Running migration [1.0.2>] post-deduplicate-uuids 2025-04-17 11:39:58,582 23 INFO apan_2760231_18.0 odoo.addons.base.models.ir_module: module point_of_sale: loading translation file /home/odoo/src/odoo/18.0/addons/point_of_sale/i18n/nl.po for language nl_NL ``` opw-4734894 upg-2760231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206558 Forward-Port-Of: odoo/odoo#206467
Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally
Original PR description
Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a…
Description of the issue this commit addresses: When creating the OSS fiscal positions, if the system creates a tax with a name already used by another tax, the entire mapping process stops due to a unique name constraint resulting in only the countries that have already been done to have the OSS fiscal positions. A solution would be to delete the tax but in the eventuality that it has already been used, it is impossible to delete it hence refreshing the oss fiscal positions becoming totally impossible. --- Steps to reproduce: 1. Install l10n_eu_oss and any oss member loca (be for example) 2. Use the company of the loca installed 3. Go to Accouting, Settings, click Refresh tax mapping. 4. Go to the fiscal positions and delete any oss fiscal position. 5. Go back to Accoutning, Settings, click Refresh tax mapping. 6. "Tax names must be unique!" error shows up. --- Desired behavior after this commit is merged: When creating the oss fiscal positions, a search is performed to gather the tax and its copies that use the desired name. The name of the new tax will be the name of the one with the most " (Copy)" in its name with one more " (Copy)". --- no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208985 Forward-Port-Of: odoo/odoo#208532
This measure prevents any accidental or unauthorized modifications to these critical fields after the transition has been done or authorized, thereby ensuring data accuracy and consistency. task - 4680092 you can check this for reference  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208301
Original PR description
This measure prevents any accidental or unauthorized modifications to these critical fields after the transition has been done or authorized, thereby ensuring data accuracy and consistency. task - 4680092 you can check this for reference  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208301
This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA. Forward-Port-Of: odoo/odoo#208969
Original PR description
This commit fixes the URL being used in the path argument given to the 'scoped_app' route. Since '/odoo' is already used by the main PWA, we must not use 'odoo' in the actual path of the PWA. Forward-Port-Of: odoo/odoo#208969
This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scroll
Original PR description
This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we…
This commit, fixes the scroll of the control panel when we opened the search bar. The bug happened because when we scroll we save the last scroll position into `oldScrollTop` variable. But when we "open" the search bar a "new line" (search input) is rendered so the height of the scrolling element is increase (by the height of the search input line). Also, a scroll is triggered so the view remains at the same position. But the `oldScrollTop` is not adapted to reflect the new height of the scrolling element. When the new delta was calculated (in the scroll handler) to set the top position of the control panel, a wrong value was set as there was an additional offset of the height of the "search input line". This commit adds an ResizeObserver to observe the scrolling element and so adapt the `oldScrollTop` variable to adapt the delta of its height. task-4466063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208955 Forward-Port-Of: odoo/odoo#208787
Button was mistakenly too big, due to typo with `.btn-s` instead of `.btn-sm`. Forward-Port-Of: odoo/odoo#208672
Original PR description
Button was mistakenly too big, due to typo with `.btn-s` instead of `.btn-sm`. Forward-Port-Of: odoo/odoo#208672
Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `g
Original PR description
Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `get_current_website` returns the intended website: https://github.com/odoo/odoo/blob/1ea4f285aba925d437a5129cd36143d9987c6e6a/addons/website/models/website.py#L1121 > [!Note] > Alternatively, we can check for `request.website` being set in `get_current_website`. No idea if there's a reason it doesn't already. runbot-111554 runbot-111555 Forward-Port-Of: odoo/odoo#208887 Forward-Port-Of: odoo/odoo#201433
Before this commit, message in card visual like in mailboxes had too much spacing. This commit reduces the spacing by half. Also the dark theme had too distracting borders, their opacity have been changed to 0. The border is kept for exact same spacing as in white theme. Forward-Port-Of: odoo/odoo#208659
Original PR description
Before this commit, message in card visual like in mailboxes had too much spacing. This commit reduces the spacing by half. Also the dark theme had too distracting borders, their opacity have been changed to 0. The border is kept for exact same spacing as in white theme. Forward-Port-Of: odoo/odoo#208659
Before this commit, the parentCategories field was read from the product variant, which could be missing in certain calls. For example, in getProductInfo, the getPrice method is called without a variant, leading to errors. opw-4772883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208979
Original PR description
Before this commit, the parentCategories field was read from the product variant, which could be missing in certain calls. For example, in getProductInfo, the getPrice method is called without a variant, leading to errors. opw-4772883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208979
Follow-up of https://github.com/odoo/odoo/pull/203142 PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it looks like an icon, now this outline and squared like other buttons. To have a similar size as the counter, it had the `.badge` classname. The `.badge` classname has to do some shenanigans to have constant width for 1-digit values, one of which is to set a minimum width of `2.7ch`. When the "m
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/203142 PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it…
Follow-up of https://github.com/odoo/odoo/pull/203142 PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it looks like an icon, now this outline and squared like other buttons. To have a similar size as the counter, it had the `.badge` classname. The `.badge` classname has to do some shenanigans to have constant width for 1-digit values, one of which is to set a minimum width of `2.7ch`. When the "mark as read" button was changed, this become a button but the `.badge` classname was mistakenly kept. As a result, it kept `min-width: 2.7ch`, which made the width too large on this button. `min-width: 2.7ch` should not be used on the same node as `.fa`, as the width of font-awesome glyph is bigger than badge numbers. This commit fixes by removing the `.badge` classname altogether, so the button is sized properly. Another fix could have been to put the `.fa.fa-check` in child-node, but that results in the same visual so removing `.badge` results in simpler template. As the "mark as read" is a button with outline, there's also no longer need to have exact width as a badge. Task-4770926 Before <img width="478" alt="Screenshot 2025-05-05 at 16 55 22" src="https://github.com/user-attachments/assets/dc5ca989-be1d-436e-84e4-57b450f66908" /> After <img width="476" alt="Screenshot 2025-05-05 at 16 54 32" src="https://github.com/user-attachments/assets/06f99cb0-4ab4-4090-80ea-48e71970e80a" /> Forward-Port-Of: odoo/odoo#208462
### Steps to reproduce: - Create an invoice - In the page "Electronic Invoicing" change the "Payment Method" to something different from "MP05" - Send to tax Agency - In the XML ModalitaPagamento is still "MP05" ### Cause: This [commit](https://github.com/odoo/odoo/commit/277e0895efa4b110128b1029a5fe76283a094cde) added the possibility to choose the payment method on invoice. When exporting the value was always "MP05", it did not read the value of `l10n_it_payment_method` because this fil
Original PR description
### Steps to reproduce: - Create an invoice - In the page "Electronic Invoicing" change the "Payment Method" to something different from "MP05" - Send to tax Agency - In the XML ModalitaPagamento is still "MP05" ### Cause: This [commit](https://github.com/odoo/odoo/commit/277e0895efa4b110128b1029a5fe76283a094cde) added the possibility to choose the payment method on invoice. When exporting the value was always "MP05", it did not read the value of `l10n_it_payment_method` because this filed was in another module: `l10n_it_edi_ndd`. This [commit](https://github.com/odoo/odoo/commit/dc0ab07465a3a9536bff1dc2a2f45814f69023fd) merged the two modules, but the exporting value is still always "MP05". ### Solution: Give the value of `l10n_it_payment_method`. opw-4724243 Forward-Port-Of: odoo/odoo#207199
This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions. ### Steps to reproduce: 1. Install both `stock`, `delivery` and `mrp` 2. Create a product with a kit BOM and weight - Set the kit UoM to Unit and the components to Kg - Add a weight to the components too 3. Create SO with the kit product 4. Add shipping (UPS) 5. Delivery product 6. `The unit of measure Unit defined on the order line doesn't bel
Original PR description
This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions. ### Steps to reproduce: 1. Install both `stock`, `delivery`…
This commit is a hack to work around the module loading order without creating a new bridge module, to fix the issue in stable versions. ### Steps to reproduce: 1. Install both `stock`, `delivery` and `mrp` 2. Create a product with a kit BOM and weight - Set the kit UoM to Unit and the components to Kg - Add a weight to the components too 3. Create SO with the kit product 4. Add shipping (UPS) 5. Delivery product 6. `The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure Kg` The sale price computed in `stock_delivery` does not take kits into account, which leads to conversion of UoM from different products (and therefore different UoM categories). However, `sale_mrp` already computes the right value for kits. It worked in earlier versions, thanks to the module loading order, but `_compute_sale_price` moved from the module `delivery` to `stock_delivery`. Here is the (simplified) module dependency graph: ``` Odoo 16.0: sale `-> sale_management `-> delivery `-> sale_stock `-> sale_mrp Odoo 17.0: sale `-> delivery `-> stock_delivery `-> sale_stock `-> sale_mrp ``` Odoo sorts modules by depth in the graph, and ordered alphabetically for modules with the same depth. So in Odoo 16.0, `delivery` was loaded before `sale_mrp`, but starting Odoo 17.0, `stock_delivery` is loaded after `sale_mrp` since they both have the same depth. opw-4385052 Forward-Port-Of: odoo/odoo#207963 Forward-Port-Of: odoo/odoo#190750
Steps to reproduce: - Go to any form view with a chatter - Make a change in the form view - Open the chatter composer - Click on the "Send" button => The parent record is reloaded, but the changes made in the form view are lost. This happens since 94088d18879a6a634077908e494483cbd0cc1a28, which introduced a `load` call in the `onCloseFullComposerCallback` method without taking into account the fact that the parent record might already be in a dirty state. This commit fixes the issue by
Original PR description
Steps to reproduce: - Go to any form view with a chatter - Make a change in the form view - Open the chatter composer - Click on the "Send" button => The parent record is reloaded, but the changes made in the form view are lost. This happens since 94088d18879a6a634077908e494483cbd0cc1a28, which introduced a `load` call in the `onCloseFullComposerCallback` method without taking into account the fact that the parent record might already be in a dirty state. This commit fixes the issue by saving the record before reloading it. OPW-4762965 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#208816
## Version: 18.0 > 18.1 (test to fw up to master) 18.2+ fixed by https://github.com/odoo/odoo/pull/186649 ## Issue: Changing the `Quotation Template` on a quotation after ## Steps to reproduce: *Ensure `PDF Quote builder` is checked in `Settings` app* - In `Sales / Configuration / Sales Orders:Headers/Footers`: - Ensure there are at least 2 documents *(add them if needed)*; - Set their `Document type` to `Header`; - Go to `Sales / Configuration / Sales Orders:Quotation Template
Original PR description
## Version: 18.0 > 18.1 (test to fw up to master) 18.2+ fixed by https://github.com/odoo/odoo/pull/186649 ## Issue: Changing the `Quotation Template` on a quotation after ## Steps to reproduce:…
## Version:
18.0 > 18.1 (test to fw up to master)
18.2+ fixed by https://github.com/odoo/odoo/pull/186649
## Issue:
Changing the `Quotation Template` on a quotation after
## Steps to reproduce:
*Ensure `PDF Quote builder` is checked in `Settings` app*
- In `Sales / Configuration / Sales Orders:Headers/Footers`:
- Ensure there are at least 2 documents *(add them if needed)*;
- Set their `Document type` to `Header`;
- Go to `Sales / Configuration / Sales Orders:Quotation Templates`:
- Create 2 new templates (e.g. "test1" and "test2"):
- In "test1", under the `Quote Builder`, add one of the documents;
- In "test2", under the `Quote Builder`, add the second document;
- Create a new quote for any customer:
- Select "test1" as `Quotation Template`;
- Under the `Quote Builder`, select the header document;
- Change the `Quotation Template` for "test2";
- Select the header document;
- Change back to "test1" and see the header document is still selected;
- Print the quote via the action button;
- The PDF contains both "test1" and "test2" document headers.
## Fix:
Partial backport of https://github.com/odoo/odoo/pull/186649
opw-4709144
Forward-Port-Of: odoo/odoo#208694
Forward-Port-Of: odoo/odoo#208384Discuss sidebar in compact mode has a specific positioning of the unread indicator, i.e. the dot next to avatar of conversation. The position was slightly off, especially on items that had an outline, i.e. with sub-threads or an ongoing call. This commit slightly moves the indicator to left, so this is placed right on the outline, rather than off-centered to right. Forward-Port-Of: odoo/odoo#208656
Original PR description
Discuss sidebar in compact mode has a specific positioning of the unread indicator, i.e. the dot next to avatar of conversation. The position was slightly off, especially on items that had an outline, i.e. with sub-threads or an ongoing call. This commit slightly moves the indicator to left, so this is placed right on the outline, rather than off-centered to right. Forward-Port-Of: odoo/odoo#208656
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the ‘Montserrat’ text font with ‘A4’ paper format in the ‘Configure Document Layout’ section of the general settings. The word "Páge" does not align correctly in a single line with "X/X" at the bottom right of the report. However, it prints correctly when using the other fonts. Solution: Applied
Original PR description
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the…
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the ‘Montserrat’ text font with ‘A4’ paper format in the ‘Configure Document Layout’ section of the general settings. The word "Páge" does not align correctly in a single line with "X/X" at the bottom right of the report. However, it prints correctly when using the other fonts. Solution: Applied Bootstrap's text-nowrap class to prevent pagination text from breaking onto separate lines when using the Montserrat font. This addresses the issue where "<span class="page"/>" and "<span class="topage"/>" components were displaying on different lines in PDF reports. opw-4654332 Before FIX:  After FIX:  Forward-Port-Of: odoo/odoo#205160
Steps to reproduce: 1. Settings > Navigate to Configure Document Layout 2. Under Layout Background, select Custom and upload an image. Issue: Background image was being cut off at the end. The image was not covering the entire div. Solution: Updated the `.o_report_layout_background` CSS to use `background-size: contain` and remove 300px from `background-position` to ensure the image scales proportionally and stays centered. opw : 4727408 Before FIX :  After FIX :  Forward-Port-Of: odoo/odoo#207029
Before this commit, position of message action position was sometimes in message header and sometimes next to message content. This happens because the condition was relying on `message.is_note` that works for logged notes but doesn't work with other non-bubble layout messages, such as tracked values. This commit fixes the issue by using `message.bubbleColor` instead of `message.is_note`, and the `bubbleColor` condition has been adjusted to not wrongly set a bubble color for notification m
Original PR description
Before this commit, position of message action position was sometimes in message header and sometimes next to message content. This happens because the condition was relying on `message.is_note` that works for logged notes but doesn't work with other non-bubble layout messages, such as tracked values. This commit fixes the issue by using `message.bubbleColor` instead of `message.is_note`, and the `bubbleColor` condition has been adjusted to not wrongly set a bubble color for notification messages. Forward-Port-Of: odoo/odoo#208626
Before this commit, the background color of discuss mobile mailbox selection was `.bg-view`. This is not a problem in white theme, but in dark theme this is too light, which makes it hard to see this is a button group. This commit fixes the issue by removing this `.bg-view`, thus relying on the discuss app background that is already white or dark depending on the chosen web client theme. Forward-Port-Of: odoo/odoo#208612
Original PR description
Before this commit, the background color of discuss mobile mailbox selection was `.bg-view`. This is not a problem in white theme, but in dark theme this is too light, which makes it hard to see this is a button group. This commit fixes the issue by removing this `.bg-view`, thus relying on the discuss app background that is already white or dark depending on the chosen web client theme. Forward-Port-Of: odoo/odoo#208612
Before this commit, images were hard to spot in discuss messages, especially for images that were made from discuss itself. This commit fixes the issue by having a slight border around the image, in addition to `.shadow-sm`. This gives a better visual clarity of the outline around the image. Forward-Port-Of: odoo/odoo#208662
Original PR description
Before this commit, images were hard to spot in discuss messages, especially for images that were made from discuss itself. This commit fixes the issue by having a slight border around the image, in addition to `.shadow-sm`. This gives a better visual clarity of the outline around the image. Forward-Port-Of: odoo/odoo#208662
Before this commit, chatter composer had too much left padding, which made it unaligned with message author avatars. This happens because the chatter top has some left padding when aside, so that the top buttons are aligned with message author avatars. This commit fixes the issue by having a negative left margin in composer of chatter to compensate. The computation relies on the chatter top and content left paddings, both of which differ when chatter is either aside or non-aside. Forward-
Original PR description
Before this commit, chatter composer had too much left padding, which made it unaligned with message author avatars. This happens because the chatter top has some left padding when aside, so that the top buttons are aligned with message author avatars. This commit fixes the issue by having a negative left margin in composer of chatter to compensate. The computation relies on the chatter top and content left paddings, both of which differ when chatter is either aside or non-aside. Forward-Port-Of: odoo/odoo#208600
Add the partner's `ref` field to the list of PartyIdentification>ID. task-4720252 Forward-Port-Of: odoo/odoo#206655
Original PR description
Add the partner's `ref` field to the list of PartyIdentification>ID. task-4720252 Forward-Port-Of: odoo/odoo#206655
How to reproduce: ================ Create a trial database on 'odoo.com', go to Contacts and click on new, then add a company name by clicking on one option from the autocompletion's selection.You get a Client Error (UncaughtPromiseError > TypeError). Reason: ====== The error is linked to the recent deletion of the 'mobile' field on the 'res_partner' model (see odoo/odoo#189739). It occurs on the trial database (and not on the runbot dbs) because it has free credits for testing the ap
Original PR description
How to reproduce: ================ Create a trial database on 'odoo.com', go to Contacts and click on new, then add a company name by clicking on one option from the autocompletion's selection.You get a Client Error (UncaughtPromiseError > TypeError). Reason: ====== The error is linked to the recent deletion of the 'mobile' field on the 'res_partner' model (see odoo/odoo#189739). It occurs on the trial database (and not on the runbot dbs) because it has free credits for testing the api, which returns all company information (including the mobile key,value/field). Solution: ======== As modifying the api would involve a new api version, we make it so the Client discards the 'mobile' key/value from the api (enrich_company) result, before the related record is updated. task-4620000 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200410
Before this commit, sometimes the action panel in chat window were taking part of the chat window available width. Steps to reproduce: - open a chat window of a discuss conversation - open Notification settings - reduce the width of browser window just before mobile threshold => the "Notification settings" panel takes part of the width of chat window This happens because some responsive code for max width of action panel from Discuss app was mistakenly involved in chat window. This c
Original PR description
Before this commit, sometimes the action panel in chat window were taking part of the chat window available width. Steps to reproduce: - open a chat window of a discuss conversation - open Notification settings - reduce the width of browser window just before mobile threshold => the "Notification settings" panel takes part of the width of chat window This happens because some responsive code for max width of action panel from Discuss app was mistakenly involved in chat window. This commit fixes the issue by ensuring this responsive behaviour of max width doesn't apply in chat window. Forward-Port-Of: odoo/odoo#208891
Before this commit, when posting a message with a single image in a chat window, the spacing between the image and message actions was too big. This happens because the attachment list container has a lot of margin/spacing for unknown reasons. This commit removes this arbitrary margin/padding, so that the spacing is reduced. A consequence of it is that big images take more space in chat windows. Note that when a message has more than 1 attachment, the message action is still far away fr
Original PR description
Before this commit, when posting a message with a single image in a chat window, the spacing between the image and message actions was too big. This happens because the attachment list container has a lot of margin/spacing for unknown reasons. This commit removes this arbitrary margin/padding, so that the spacing is reduced. A consequence of it is that big images take more space in chat windows. Note that when a message has more than 1 attachment, the message action is still far away from the attachments. This is unfortunately an issue with content wrapped in which container is not resized to match content width, which is a browser style limitation. This problem can only be tackled by adjusting in JS. Forward-Port-Of: odoo/odoo#208829
Steps to reproduce: - Connect IoT box with scale to DB - Configure PoS with the scale - Configure product to be available in PoS and has to be weighed - Make an order with the product - Scale window pops up for weighing - Close window directly - One unit of product is still added, we expect nothing to be added opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208571
Original PR description
Steps to reproduce: - Connect IoT box with scale to DB - Configure PoS with the scale - Configure product to be available in PoS and has to be weighed - Make an order with the product - Scale window pops up for weighing - Close window directly - One unit of product is still added, we expect nothing to be added opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208571
Steps to reproduce: - Create a product with two separate 'no-variant' attributes - Set that product as MTO / Manufacture - Create a BoM for that product, with a single component - Set that component as limited to the first 'no-variant' attribute - Create a Sale Order for that product, and select the second 'no-variant' attribute - Confirm the Sale Order Issue: A traceback will be raised, as the given attribute won't be found within the attributes set on the bom. When chekcing if we
Original PR description
Steps to reproduce: - Create a product with two separate 'no-variant' attributes - Set that product as MTO / Manufacture - Create a BoM for that product, with a single component - Set that component as limited to the first 'no-variant' attribute - Create a Sale Order for that product, and select the second 'no-variant' attribute - Confirm the Sale Order Issue: A traceback will be raised, as the given attribute won't be found within the attributes set on the bom. When chekcing if we should skip the bom line, there will be an issue if there's a miss-match between the attributes written on a line and the ones given to the MO. To avoid this, we now directly exclude a line when there's no common attribute between the two, then validate it once at least one match was found. opw-4758951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208623
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502 Magnesium Mg - UMT Aduana: kg - Make an Invoice as follows: - Customer: Deco Addict - Currency USD - Product: [TEST] - Price: 3,114.515000 - Qty UMT: 11 - Incoterm: EX WORKS - External Trade: Definitive - Confirm Invoice - Send CFDI Issue: Validation will fail with er
Original PR description
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502…
Steps to reproduce: - Raise Product Price Accuracy to 6 - Set Global Rounding - Fetch latest currency rate for USD from Bank of Mexico - Create a [TEST] Product with: - UNSPSC Category: 12141502 Magnesium Mg - UMT Aduana: kg - Make an Invoice as follows: - Customer: Deco Addict - Currency USD - Product: [TEST] - Price: 3,114.515000 - Qty UMT: 11 - Incoterm: EX WORKS - External Trade: Definitive - Confirm Invoice - Send CFDI Issue: Validation will fail with error """ Code : CCE122 Message : El atributo cce20:ComercioExterior:TotalUSD no coincide con la suma de ValorDolares de las mercancías. """ In the xml, the ValorDolares for the sold item will be 3114.5150 but the attribute TotalUSD will be 3114.52 This occurs because ValorDolares are emitted as unrounded amount, but TotalUSD is rounded to 2 decimals. When working with 3+ digits the amounts might not add up correctly. Note: Before version 18, ValorDolares (`product_values['total']`) amount was already rounded according to the currency decimals (2) and there was no issue opw-4662692 opw-4686226 Forward-Port-Of: odoo/enterprise#84027
In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness). It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government. Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included
Original PR description
In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness). It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government. Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included in the description, they don't trim the description they send to the government sufficiently. Perhaps they trim before the '\n' to ' | ' translation, or perhaps they have some other bug. We sidestep the issue by doing that same translation on our side and sending them that. It doesn't result in any change on the EDI PDF or XML, and this way we can avoid hardcoding these limits on our side. task-4726372 Forward-Port-Of: odoo/enterprise#84841 Forward-Port-Of: odoo/enterprise#84700
Issue: Syntax error is raised when applying period comparison on partner ledger report. Purpose of this PR: Group queries with the parentheses. Steps to Reproduce in Runbot: - install accounting - add period comparison to Partner Ledger Report - try to apply period comparison opw-4730435 Forward-Port-Of: odoo/enterprise#85074 Forward-Port-Of: odoo/enterprise#83652
Original PR description
Issue: Syntax error is raised when applying period comparison on partner ledger report. Purpose of this PR: Group queries with the parentheses. Steps to Reproduce in Runbot: - install accounting - add period comparison to Partner Ledger Report - try to apply period comparison opw-4730435 Forward-Port-Of: odoo/enterprise#85074 Forward-Port-Of: odoo/enterprise#83652
Before this commit, when rescheduling call activities, this could lead to the following crash: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This error state that the activity has no related persona in order to display its avatar in the popover. The persona data must be returned with activity data, and this is a required field therefore any activity should necessarily have a persona in their data. The reas
Original PR description
Before this commit, when rescheduling call activities, this could lead to the following crash: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This error state that the activity has no related persona in order to display its avatar in the popover. The persona data must be returned with activity data, and this is a required field therefore any activity should necessarily have a persona in their data. The reason of crash comes from voip method `_format_call_activities` that returns custom activity data that do not pass `persona`. This commit fixes the issue by passing `persona` data like in the usual `_to_store` of activity. The crash occurs since https://github.com/odoo/odoo/pull/190161 opw-4586756 Forward-Port-Of: odoo/enterprise#84970
### Description: By default, it is impossible to change the default limit of card displayed on shop floor. This PR aim to change that by adding a "limit" in the `context` field of the action. ### Reference: opw-4707551 Forward-Port-Of: odoo/enterprise#83296
Original PR description
### Description: By default, it is impossible to change the default limit of card displayed on shop floor. This PR aim to change that by adding a "limit" in the `context` field of the action. ### Reference: opw-4707551 Forward-Port-Of: odoo/enterprise#83296
**Problem:** When having multiple quants for a product with the same lot but different packages in the same location. Not all quants are visible in the barcode app inventory. **Steps to reproduce:** - In settings activate the following settings : Packages, Storage Locations, Count Entire Locations - Open Inventory/Products - Create a new product - Check the "track inventory" field and select "By Lot" - Go to Inventory/Operations/Physical Inventory and create a new line for your product
Original PR description
**Problem:** When having multiple quants for a product with the same lot but different packages in the same location. Not all quants are visible in the barcode app inventory. **Steps to reproduce:**…
**Problem:** When having multiple quants for a product with the same lot but different packages in the same location. Not all quants are visible in the barcode app inventory. **Steps to reproduce:** - In settings activate the following settings : Packages, Storage Locations, Count Entire Locations - Open Inventory/Products - Create a new product - Check the "track inventory" field and select "By Lot" - Go to Inventory/Operations/Physical Inventory and create a new line for your product - As Location put WH/Stock/Shelf 1 - Write Lot1 for the Lot and Pack1 for the Package - Set a quantity of 5 - Save and Apply - Do the same for another line put but Pack2 for the Package - Open the barcode app and select inventory adjustments - Click on the barcode icon on the top right of the screen - Write SHELF1 and click on apply **Current behavior:** Only 5 unit of your product are displayed (those for Pack1) **Expected behavior:** 10 units should be displayed. The 5 from Pack1 and the 5 from Pack2 **Cause of the issue:** When checking if the line already exists, the package is not taken into account https://github.com/odoo/enterprise/blob/7a132639d6c05ef96d43a48ea34ff11711539fc7/stock_barcode/static/src/models/barcode_quant_model.js#L563-L564 so if a line already exists for the same lot "!currentLine" will be false and the code inside the if statement will not be run https://github.com/odoo/enterprise/blob/7a132639d6c05ef96d43a48ea34ff11711539fc7/stock_barcode/static/src/models/barcode_quant_model.js#L565 resulting in the new line not being added in the barcode app opw-4640303 Forward-Port-Of: odoo/enterprise#84709 Forward-Port-Of: odoo/enterprise#83384
It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback. This commit aims to handle this case so the report can be open without issue. opw-4749480 Forward-Port-Of: odoo/enterprise#84812
Original PR description
It's possible to have a 0 purchase order line with a negative invoiced qty if there is only a credit note linked to the PO. When the budget report process this order line, it will trigger a traceback. This commit aims to handle this case so the report can be open without issue. opw-4749480 Forward-Port-Of: odoo/enterprise#84812
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to reproduce ================ 1. Create two products with a barcode; 2. Open the Barcode app and create an operation; 3. Scan a product then click on the edit button to open the form view; 4. Update the product quantity field; 5. While still in the form view, scan another barcode -> You can s
Original PR description
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to…
Issue ===== Scanning a product while beeing in the stock move line Barcode form view or in the quand Barcode form view can cause a traceback and the impossibility to exit a Barcode operation. How to reproduce ================ 1. Create two products with a barcode; 2. Open the Barcode app and create an operation; 3. Scan a product then click on the edit button to open the form view; 4. Update the product quantity field; 5. While still in the form view, scan another barcode -> You can see the quantity was reset; 6. Update again the quantity and save; 7. Try to exit the operation -> Bim badaboum, traceback 💥! Cause of the issue ================== When a barcode is scanned, the app doesn't check where is the current state and process the barcode anyway which lead to strange behavior and inconsistencies between the current lines and the lines to save. Solution ======== Disable the scan while somewhere else that in the barcode line view. Miscellaneous ============= Remove an old forgotten `console.warn` 😬 [OPW-4567723](https://www.odoo.com/odoo/project/49/tasks/4567723) Forward-Port-Of: odoo/enterprise#82484 Forward-Port-Of: odoo/enterprise#81512
Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost. The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values. opw-4686819 Forward-Port-Of: odoo/enterprise#83829
Original PR description
Before, the feature was not usable because HMRC would only accept whole pounds for the total payments made and the materials cost. The fix was to round the values on the report to whoule pounds for those two columns. This way, it would become valid for HMRC as the return is based on those report values. opw-4686819 Forward-Port-Of: odoo/enterprise#83829
**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report) - Select "Argentinean VAT Book (AR)" as report - A cog button should appear after the report name with "VAT Book (ZIP)" option - With browser debug feature, switch to a responsive display and reduce the width or - Repeate
Original PR description
**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to…
**Steps to reproduce:** - Install Accounting - Install a module that adds a button to tax report (e.g. l10n_ar) - Switch to an Argentinian company (e.g. (AR) Responsable Inscripto) - Go to "Accounting / Reporting / Statements Reports / Tax Return" (i.e. Tax Report) - Select "Argentinean VAT Book (AR)" as report - A cog button should appear after the report name with "VAT Book (ZIP)" option - With browser debug feature, switch to a responsive display and reduce the width or - Repeatedly increase the zoom to increase the size of the button **Issue:** For a certain range of width the cog button is not visible. **Cause:** ".o_control_panel_breadcrumbs" element that contains the buttons has a min-width of 200px, hiding all elements that are after these 200px when reducing the width. **Solution:** Increase the min-width to 350px. The value is arbitrary but it covers well this use case. With a lower value, the cog button could still be hidden in the case of the Argentinian Tax Report in Spanish language. opw-4747697 Forward-Port-Of: odoo/enterprise#84432
Forward-Port-Of: odoo/enterprise#83758 Forward-Port-Of: odoo/enterprise#83747
Original PR description
Forward-Port-Of: odoo/enterprise#83758 Forward-Port-Of: odoo/enterprise#83747
Commit baa934898f184b10ae4c5c51e26fabe4e0178a86 updated the body for ongoing process responses when checking the status of a report submitted through SBR. The variable `error_description` it tries to assign is not defined in that scope of the function, resulting in an error. This PR reverts the value assigned to be the status description, as it was prior to the above commit. opw-4775345 Forward-Port-Of: odoo/enterprise#84749
Original PR description
Commit baa934898f184b10ae4c5c51e26fabe4e0178a86 updated the body for ongoing process responses when checking the status of a report submitted through SBR. The variable `error_description` it tries to assign is not defined in that scope of the function, resulting in an error. This PR reverts the value assigned to be the status description, as it was prior to the above commit. opw-4775345 Forward-Port-Of: odoo/enterprise#84749
This is a useful option that is hard to know about unless you read the code or are told it exists. It should be visible in the report options. In the context of: task-4734528 Forward-Port-Of: odoo/enterprise#83556
Original PR description
This is a useful option that is hard to know about unless you read the code or are told it exists. It should be visible in the report options. In the context of: task-4734528 Forward-Port-Of: odoo/enterprise#83556
Forward-Port-Of: odoo/enterprise#83960 Forward-Port-Of: odoo/enterprise#81174
Original PR description
Forward-Port-Of: odoo/enterprise#83960 Forward-Port-Of: odoo/enterprise#81174
This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588
Original PR description
This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
Original PR description
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - F
Original PR description
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - From an EU company, create an invoice to a company in another EU country - Do not set an incoterm on the invoice - In settings, set a default incoterm on the company - Display the intrastat report for the time period of the invoice - Try to unfold the line corresponding to the invoice opw-4642781 Forward-Port-Of: odoo/enterprise#84734
Steps to reproduce the issue: - Create a quality check with any parameters - Add a future activity - Click on the activity icon in the top bar - The activity summary shows: - 0 Late, 0 Today, 1 Future - Click on "Late" Issue: No filter is applied and all quality checks are displayed. Solution: Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin. opw-4727840
Original PR description
Steps to reproduce the issue:
- Create a quality check with any parameters
- Add a future activity
- Click on the activity icon in the top bar
- The activity summary shows:
- 0 Late, 0 Today, 1 Future
- Click on "Late"
Issue:
No filter is applied and all quality checks are displayed.
Solution:
Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin.
opw-4727840
Forward-Port-Of: odoo/enterprise#84523In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
Original PR description
In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar
Original PR description
The system failed to retrieve `company.l10n_ar_afip_ws_key_id.pem_key` because of quick create. Steps to Reproduce: 1. Switch to `(AR) Exento Company`. 2. Navigate to `Settings `> `Invoicing`. 3. Search for `Argentinean Localization`. 4. In `Primary Key`, clear the field, enter any value, and click Create. 5. Click `Generate Renewal Request`. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'bool'` Solution: Add `no_quick_create : True` for l10n_ar_afip_ws_key_id field. Sentry - 5999498377 Forward-Port-Of: odoo/enterprise#83233
pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to
Original PR description
pos_self_* = pos_self_order_preparation_display Before this commit, orders made on the kiosk were no longer sent to the preparation display. This commit restores the expected behavior by ensuring that kiosk orders are correctly sent to the preparation display. Step to reproduce: - Install pos_restaurant. - Enable Kiosk as self-ordering mode - Configure a preparation display for the kiosk configuration. - Place an order and proceed to the confirmation page. - The order is not sent to the preparation display opw-4754522 Forward-Port-Of: odoo/enterprise#84870
Add the Invoice Sending Method field to the partner's list view to enable mass edit. task-no (feedback from WTA) Forward-Port-Of: odoo/odoo#209007
Original PR description
Add the Invoice Sending Method field to the partner's list view to enable mass edit. task-no (feedback from WTA) Forward-Port-Of: odoo/odoo#209007
## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guide
Original PR description
## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204296