Monday, March 3, 2025
60 changes · saas-18.2
Enhancements to existing features
Point of Sale screens have been visually refined so icons, numpad special characters, and navigation buttons are easier to read, especially in dark mode. These small interface adjustments improve usability and consistency for staff using POS and restaurant appointment flows.
Original PR description
*: pos_restaurant_appointment This commit improves the icon filter to ensure better compatibility with dark mode and removes an unused target that was never triggered. Additionally, it refines the numpad "special characters" for improved visibility in dark mode and adjusts the navbar buttons by removing unnecessary bold styling. - requires https://github.com/odoo/odoo/pull/196224 task-4547675
Resolved issues and error corrections
The restaurant floor plan now hides unnecessary trailing zeros in table change amounts. This makes displayed amounts easier to read for staff without changing the underlying values or workflow.
Original PR description
- Hide trailing zeros of table changes on floorplan. previous realted PR: https://github.com/odoo/odoo/pull/198188/files --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Before this PR:** - Users could not drag and drop the call participant card in the chat window due to incorrect position computations. - Participant card was positioned at bottom right, causing the "End Call" button to be hidden behind it. **This PR:** - Fixes the drag-and-drop issue by correcting the position calculations. - Adds 5vh bottom offset for card so it doesn't overlap "End Call" button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
**Before this PR:** - Users could not drag and drop the call participant card in the chat window due to incorrect position computations. - Participant card was positioned at bottom right, causing the "End Call" button to be hidden behind it. **This PR:** - Fixes the drag-and-drop issue by correcting the position calculations. - Adds 5vh bottom offset for card so it doesn't overlap "End Call" button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199703 Forward-Port-Of: odoo/odoo#190309
This fix prevents occasional false test failures in the gamification module caused by tiny timestamp precision differences. It helps keep automated validation stable without changing user-facing functionality.
Original PR description
Before this commit, the test `test_20_update_all_goals_filter` would fail occasionally due to the users supposed to have recent activity being considered inactive. This happens because the method `_update_all`, in charge of updating goals for active users, would compare the goal `write_date` stored with full timestamp precision including microseconds with the users `last_presence` which is effectively stored at second-level precision. When the two values are close, the microsecond difference can cause `write_date` to appear greater than `last_presence`, preventing goal updates. This commit fixes the issue by artificially adding one second to the `last_presence` of the users in order to guarantee it to be greater then `write_date` and thus preventing test failures due to microsecond mismatches. backport of https://github.com/odoo/odoo/pull/197987
Task Adhoc side: 44224 Update l10n_ar_withholding translations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197361
Original PR description
Task Adhoc side: 44224 Update l10n_ar_withholding translations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197361
Before this commit: This test was ignored by the runbot platform as the test was consistently failing. Starting version 18, the flow of the "Buy Now" button did change to redirect to the card after being pressed rather than the payment page as intended in the PR: https://github.com/odoo/odoo/pull/149020 After this commit: Remove irelevant part of the test to make it successful rb-56459 Forward-Port-Of: odoo/odoo#199706 Forward-Port-Of: odoo/odoo#199616
Original PR description
Before this commit: This test was ignored by the runbot platform as the test was consistently failing. Starting version 18, the flow of the "Buy Now" button did change to redirect to the card after being pressed rather than the payment page as intended in the PR: https://github.com/odoo/odoo/pull/149020 After this commit: Remove irelevant part of the test to make it successful rb-56459 Forward-Port-Of: odoo/odoo#199706 Forward-Port-Of: odoo/odoo#199616
Before this commit, the sample payload displayed next to server actions of type 'webhook' didn't respect the format of the actual payload sent by `_run_action_webhook`. This commit fixes that by adjusting the `_compute_webhook_sample_payload` method so it includes the exact same keys and values that will be sent by the server action when ran. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199018
Original PR description
Before this commit, the sample payload displayed next to server actions of type 'webhook' didn't respect the format of the actual payload sent by `_run_action_webhook`. This commit fixes that by adjusting the `_compute_webhook_sample_payload` method so it includes the exact same keys and values that will be sent by the server action when ran. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199018
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR
Original PR description
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199592 Forward-Port-Of: odoo/odoo#196912
Currently in the italian e-invoice system it is not allowed to report negative lines so when the system needs to encode an invoice with negative lines it will dispatch them over the other lines with same tax, keeping the negative amount as discount. However when the discounted line amount is 0 this line is not reported in the e-invoice anymore Steps to reproduce: - With IT Company setup - Create an invoice for IT customer, with lines: 1. Quantity 1 | Price 0.0 | Tax 22% 2. Qua
Original PR description
Currently in the italian e-invoice system it is not allowed to report negative lines so when the system needs to encode an invoice with negative lines it will dispatch them over the other lines with same tax, keeping the negative amount as discount. However when the discounted line amount is 0 this line is not reported in the e-invoice anymore Steps to reproduce: - With IT Company setup - Create an invoice for IT customer, with lines: 1. Quantity 1 | Price 0.0 | Tax 22% 2. Quantity 1 | Price 150.0 | Tax 22% 3. Quantity 1 | Price 100.0 | Tax 22% 4. Quantity 1 | Price -200.0 | Tax 22% - Confirm & send - Check generated e-invoice xml Issue: Line 3 is missing This occurs because after dispatching negative lines on suitable candidates we ignore nulled lines opw-4501951 Forward-Port-Of: odoo/odoo#198497
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Original PR description
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Handling of notification data crashes when fetching a dict key: ```python payment_data = notification_data['payment'] ``` Cause ----- Commit c3c9c12d790e forwards rejected payments to handle the reason they were rejected. The issue is that notification data from rejected payments doesn't have an immediate `payment` key
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Handling of notification data crashes when fetching a dict key: ```python payment_data = notification_data['payment'] ``` Cause ----- Commit c3c9c12d790e forwards rejected payments to handle the reason they were rejected. The issue is that notification data from rejected payments doesn't have an immediate `payment` key. Instead, it contains the following keys: - `errorId` - `errors` - `paymentResult` The `payment` key we need is located in the `paymentResult` value. Solution -------- Use a new variable `payment_result`, and set it to the `paymentResult` value if it exists, otherwise to `notification_data`. We can ignore the `errors` value as it is identical to the one in the `statusOutput` value of `paymentResult`. opw-4481602 Forward-Port-Of: odoo/odoo#199211
check commit message for description Forward-Port-Of: odoo/odoo#198897 Forward-Port-Of: odoo/odoo#198372
Original PR description
check commit message for description Forward-Port-Of: odoo/odoo#198897 Forward-Port-Of: odoo/odoo#198372
Currently, An error occurs when trying to change(update) all interviewers at once from the (hr)'Applications' list view. Step to produce: - Install the `hr_recruitment` module. - Open Recruitment / Applications / All Applications and add the Interviewers field in the list view, Select all records, and try to change or add interviewers to any of them. `ValueError: Expected singleton: hr.applicant(800, 799, 798, 797, 819)` The error occurs because the system attempts to access a singl
Original PR description
Currently, An error occurs when trying to change(update) all interviewers at once from the (hr)'Applications' list view. Step to produce: - Install the `hr_recruitment` module. - Open Recruitment / Applications / All Applications and add the Interviewers field in the list view, Select all records, and try to change or add interviewers to any of them. `ValueError: Expected singleton: hr.applicant(800, 799, 798, 797, 819)` The error occurs because the system attempts to access a single value from multiple records at [1]. Link [1]: https://github.com/odoo/odoo/blob/f1637a10db2f34ca3a272792079115e0192489f8/addons/hr_recruitment/models/hr_applicant.py#L384-L385 To resolve this issue, Use an iteration(for loop) to process each record one by one. Sentry-6229305438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194328
Currently, an exception is raised when a user attempts to archive a new employee before saving. Steps to Reproduce: 1. Install the HR module. 2. Navigate to the Employee Module. 3. Try to archive a new employee before saving. 4. An error occurs. Error: `ValueError Expected singleton: hr.employee() ` This issue occurs when a user tries to archive a new employee before saving because the system expects a default departure date for the employee, which can't be set properly without
Original PR description
Currently, an exception is raised when a user attempts to archive a new employee before saving. Steps to Reproduce: 1. Install the HR module. 2. Navigate to the Employee Module. 3. Try to archive a new employee before saving. 4. An error occurs. Error: `ValueError Expected singleton: hr.employee() ` This issue occurs when a user tries to archive a new employee before saving because the system expects a default departure date for the employee, which can't be set properly without saving the employee record first. [1] - https://github.com/odoo/odoo/blob/4f58eb9db55c102786010efe3c1fb74edefaf8f3/addons/hr/wizard/hr_departure_wizard.py#L13 This fix resolves the issue by first checking if the employee exists, and then proceeding to find the departure date. sentry-6301787988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198088
Enterprise PR: https://github.com/odoo/enterprise/pull/79432 As part of adding the Tyro payment method, new functionality was required in order to not automatically send payments to the terminal upon adding a payment line. This gives a chance to input a different payment amount, for example when splitting the payment between multiple cards. By default the behaviour is the same as before, but if a payment method overrides `fast_payments` to false, then payments will not be sent auto
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/79432 As part of adding the Tyro payment method, new functionality was required in order to not automatically send payments to the terminal upon adding a payment line. This gives a chance to input a different payment amount, for example when splitting the payment between multiple cards. By default the behaviour is the same as before, but if a payment method overrides `fast_payments` to false, then payments will not be sent automatically (the same behaviour as pre v18). task-4086116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199704 Forward-Port-Of: odoo/odoo#187536
### Steps to reproduce: - Install sale, project, and accountant. - Allow Analytic Accounting from settings. - Open project application. - Create a project with a billable feature. - Add invoices in the topbar. - Select invoices and create a new invoice. - Add a product to the invoice (you will see analytic is added). Go to the journal items tab. ### Issue: When the user opens the Analytical Account, the gross margin is shown incorrectly. ### Cause: When a bill or i
Original PR description
### Steps to reproduce: - Install sale, project, and accountant. - Allow Analytic Accounting from settings. - Open project application. - Create a project with a billable feature. - Add invoices in the topbar. - Select invoices and create a new invoice. - Add a product to the invoice (you will see analytic is added). Go to the journal items tab. ### Issue: When the user opens the Analytical Account, the gross margin is shown incorrectly. ### Cause: When a bill or invoice is created from the project topbar, the analytical distribution is set in the payable/receivable journal items, causing the gross margin to show as 0. ### Fix: In this commit, we remove the setting of the analytical distribution in the payable/receivable journal items. As a result, no journal items related to payable/receivable will be added to the Analytic Line. task-4377544 Forward-Port-Of: odoo/odoo#190675
Versions -------- - saas-17.4+ Steps ----- 1. Create a new product with a lot of variants; 2. publish it to the website; 3. edit the website home page to add a product carousel; 4. set it to display newest products & hide variants. Issue ----- Fewer than 16 products are displayed in the carousel. Cause ----- Unlike the other product filters handled in https://github.com/odoo/odoo/pull/189040, the "Newest Products" filter is defined in `data/data.xml`, and stored as a record.
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Create a new product with a lot of variants; 2. publish it to the website; 3. edit the website home page to add a product carousel; 4. set it to display…
Versions -------- - saas-17.4+ Steps ----- 1. Create a new product with a lot of variants; 2. publish it to the website; 3. edit the website home page to add a product carousel; 4. set it to display newest products & hide variants. Issue ----- Fewer than 16 products are displayed in the carousel. Cause ----- Unlike the other product filters handled in https://github.com/odoo/odoo/pull/189040, the "Newest Products" filter is defined in `data/data.xml`, and stored as a record. This means it doesn't use the `_get_products` method to perform the search, instead using the `_prepare_values` method from the `website` module. For obvious reasons, the method defined in `website` doesn't take the `hide_variants` parameter into account to get the correct amount of search results: https://github.com/odoo/odoo/blob/0f64298c871ffea088a4fe6255d19852c8348159/addons/website/models/website_snippet_filter.py#L102-L108 Instead it passes 16 `product.product` records to the `_filter_records_to_values` override in `website_sale`, where duplicate templates are filtered out, resulting in fewer than 16 product templates: https://github.com/odoo/odoo/blob/0f64298c871ffea088a4fe6255d19852c8348159/addons/website_sale/models/website_snippet_filter.py#L73-L76 Solution -------- When calling `super()._prepare_values` for stored `product.product` filters, temporarily square the usual limit for the search, and filter reduce to size later. This may still be inadequate when working with products with dozens of variants, but should cover most normal use cases without requiring drastic changes to filter templates or search domain in stable. On master, we could add a new filter specifically for `product.template`. opw-4302856 Forward-Port-Of: odoo/odoo#195857
### Steps to reproduce: - Install l10_din5008 and select the DIN5008 layout in the settings - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have several styles missing: - Section lines have no background color - There are no line separations - Column titles are not bold ### Cause: The style that was applied to all reports was removed during a refactoring in 18.0. https://github.com/odoo/odoo/pull/169512 ### Solution: Change t
Original PR description
### Steps to reproduce:
- Install l10_din5008 and select the DIN5008 layout in the settings
- Go to Sale, create a quotation with section lines
- Confirm and send
- The generated PDF have several styles missing:
- Section lines have no background color
- There are no line separations
- Column titles are not bold
### Cause:
The style that was applied to all reports was removed during a refactoring in 18.0.
https://github.com/odoo/odoo/pull/169512
### Solution:
Change the CSS of the DIN5008 report to make it look like in 17.0.
In 17.0
In 18.0
After this commit
opw-4572732
Forward-Port-Of: odoo/odoo#199213Before this commit: === - Preset data was not updated for self order (without demo data) After this commit: === - Preset data updated in pos self order (without demo data) - If there are no presets found, set 'use_presets' as False - if there is any manually created preset, add it to the default preset Related PR: odoo/odoo#194777 Related PR: odoo/odoo#199161 Task: 4501570, 4612542 Forward-Port-Of: odoo/odoo#199600
Original PR description
Before this commit: === - Preset data was not updated for self order (without demo data) After this commit: === - Preset data updated in pos self order (without demo data) - If there are no presets found, set 'use_presets' as False - if there is any manually created preset, add it to the default preset Related PR: odoo/odoo#194777 Related PR: odoo/odoo#199161 Task: 4501570, 4612542 Forward-Port-Of: odoo/odoo#199600
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to th
Original PR description
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now…
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company. We received a lot of feedback from people wanting to avoir the 1 to 1 mapping, and needing to configure such customized groupby on the report. The add of a related fields is a bit too technical to be explained in any kind of functional documentation; therefore we make the choice to add them in the standard code. They are non-stored, and will have no impact on any other flow. Note that this groupby customization only works on standard engines at the moment. Custom engines still need to be adapted, but this will come in a future PR. Forward-Port-Of: odoo/odoo#199550
In Knowledge, non-editable buttons in embedded views (cog menu, ...) use a text cursor, which is incorrect as they are not editable buttons. This is because the CSS rule that resets pointer cursors in the editor within non-editable elements only applies to .btn.btn-link elements. This commit makes it so that this rule applies for all .btn elements within non-editable elements. task-4558391 Forward-Port-Of: odoo/odoo#197468
Original PR description
In Knowledge, non-editable buttons in embedded views (cog menu, ...) use a text cursor, which is incorrect as they are not editable buttons. This is because the CSS rule that resets pointer cursors in the editor within non-editable elements only applies to .btn.btn-link elements. This commit makes it so that this rule applies for all .btn elements within non-editable elements. task-4558391 Forward-Port-Of: odoo/odoo#197468
**Issue:** When the website is configured to display prices VAT included, combo products incorrectly show their prices VAT excluded. **Steps to Reproduce:** - in website setting check tax included of `Display Product Prices` - Sales > Products > Products - Create a new product of type "Combo" and set a price - click on go to website The price displayed on the website is VAT excluded, even though VAT inclusion is configured. To address this issue, a disclaimer has been adde
Original PR description
**Issue:** When the website is configured to display prices VAT included, combo products incorrectly show their prices VAT excluded. **Steps to Reproduce:** - in website setting check tax included of `Display Product Prices` - Sales > Products > Products - Create a new product of type "Combo" and set a price - click on go to website The price displayed on the website is VAT excluded, even though VAT inclusion is configured. To address this issue, a disclaimer has been added to inform users that while taxes are not displayed for combo products, they will be properly calculated during checkout. opw-4454112 Forward-Port-Of: odoo/odoo#199132 Forward-Port-Of: odoo/odoo#194835
Before, when invoices were created from a sales order and one of the lines is a combo product, it would create a regular invoice line for that with the combo product, but the price would be zero and no taxes. The problem with that when sending electronic invoicing documents, is that it will treat that as a zero line. (and some EDIs might e.g. complain there is no tax on there) So, that way when creating the invoice line, we define it as a subsection with the product name as description but
Original PR description
Before, when invoices were created from a sales order and one of the lines is a combo product, it would create a regular invoice line for that with the combo product, but the price would be zero and no taxes. The problem with that when sending electronic invoicing documents, is that it will treat that as a zero line. (and some EDIs might e.g. complain there is no tax on there) So, that way when creating the invoice line, we define it as a subsection with the product name as description but without product. opw-4410461 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#199708 Forward-Port-Of: odoo/odoo#192568
Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#191669 Forward-Port-Of: odoo/odoo#174750
Original PR description
Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#191669 Forward-Port-Of: odoo/odoo#174750
This error occurs when a user sends a file without a message, and `Create Thread`. Step to Reproduce : - Install and open module `Discuss`. - Open Channel and send any file from `Attach files` without a message. - Hover over the sent file, click on `Expand`, and then click `Create Thread` AttributeError: 'str' object has no attribute 'striptags' This issue occurs when data is `str` instead of an HTML object. This commit fixes the error by ensuring .striptags() is only used when
Original PR description
This error occurs when a user sends a file without a message, and `Create Thread`. Step to Reproduce : - Install and open module `Discuss`. - Open Channel and send any file from `Attach files` without a message. - Hover over the sent file, click on `Expand`, and then click `Create Thread` AttributeError: 'str' object has no attribute 'striptags' This issue occurs when data is `str` instead of an HTML object. This commit fixes the error by ensuring .striptags() is only used when the data is in the correct format. sentry - 6304779383 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198534 Forward-Port-Of: odoo/odoo#197896
A traceback error occurs when creating an employee without working hours, setting up an accrual allocation for that employee, and choosing a start date before yesterday. **Steps to reproduce the issue:** 1- Create a new employee in the Employees module with an empty "Working Hours" field. 2- Create an accrual plan: - Go to Time Off > Configurations > Accrual Plans > New. - Create a new milestone for X amount of days hourly, source: Calendar. 3- Create an accrual allocation for t
Original PR description
A traceback error occurs when creating an employee without working hours, setting up an accrual allocation for that employee, and choosing a start date before yesterday. **Steps to reproduce the…
A traceback error occurs when creating an employee without working hours, setting up an accrual allocation for that employee, and choosing a start date before yesterday. **Steps to reproduce the issue:** 1- Create a new employee in the Employees module with an empty "Working Hours" field. 2- Create an accrual plan: - Go to Time Off > Configurations > Accrual Plans > New. - Create a new milestone for X amount of days hourly, source: Calendar. 3- Create an accrual allocation for that employee: - Go to Time Off > Management > Allocations > New. - Select the accrual plan created earlier. If you choose any start date before yesterday, a traceback error occurs (see screenshots attached) <img src="https://github.com/user-attachments/assets/03198eb8-5e9a-4633-a87f-b0c07aec600d" alt="traceback_error" width="400"/> The PO (GMF) confirmed that there should always be a fallback for "Working Hours" in this order: Working hours from Contract > Working Hours from Employee > Working Hours from company opw-4281311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197505 Forward-Port-Of: odoo/odoo#185428
Forward-Port-Of: odoo/odoo#198651 Forward-Port-Of: odoo/odoo#198352
Original PR description
Forward-Port-Of: odoo/odoo#198651 Forward-Port-Of: odoo/odoo#198352
- Open a posted invoice - Reset to draft - Action > Switch into invoice/credit note Validation Error will raise `You cannot switch the type of a posted document.` However the message is misleading, because we check that the document has not been posted at all opw-4509455 Forward-Port-Of: odoo/odoo#199494 Forward-Port-Of: odoo/odoo#198592
Original PR description
- Open a posted invoice - Reset to draft - Action > Switch into invoice/credit note Validation Error will raise `You cannot switch the type of a posted document.` However the message is misleading, because we check that the document has not been posted at all opw-4509455 Forward-Port-Of: odoo/odoo#199494 Forward-Port-Of: odoo/odoo#198592
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because we render the header and footer in their own viewport. In the report editor however, the viewport is unique and the svg was then fixed to the top of the page. After this commit, the report layouts continue to work in wkhtmltopdf, but we removed the top = 0 attribute. Following https://stackove
Original PR description
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because…
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because we render the header and footer in their own viewport. In the report editor however, the viewport is unique and the svg was then fixed to the top of the page. After this commit, the report layouts continue to work in wkhtmltopdf, but we removed the top = 0 attribute. Following https://stackoverflow.com/a/12282107 it should work in the contexts: (TLDR: in position fixed, if top and bottom are not specified, the default position is the one the block should have taken if it were staticly positioned) - wkhtmltopdf: the footer is rendered in its own viewport and consequently the top of the viewport is also the top of the footer and thus the original static position - action report of type HTML: no worries here, this fix doesn't apply because of ifs in the qweb expressions - report editor in edition mode: The SVG is inisible anyway because it needs a fill value which is not present in that context. The svg is located outside of the iframe's port in practice with the fix. - report editor in preview mode: works because the iframe cannot be interacted with and that the default static position is within the footer opw-4508900 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#196468
With this commit, the line `Extra Hours Available` is no longer wrapped. task-4526451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196270
Original PR description
With this commit, the line `Extra Hours Available` is no longer wrapped. task-4526451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196270
Steps to reproduce: 1) Configure pick up in store dm and publish it 2) Go to product page of a customizable desk 3) Choose the impossible combination (Aluminium and black) 4) Observe traceback Reason: Necessary fields are absent in combination info when the combination is not possible. Solution: Do not render the widget when a combination is not possible. Forward-Port-Of: odoo/odoo#199632
Original PR description
Steps to reproduce: 1) Configure pick up in store dm and publish it 2) Go to product page of a customizable desk 3) Choose the impossible combination (Aluminium and black) 4) Observe traceback Reason: Necessary fields are absent in combination info when the combination is not possible. Solution: Do not render the widget when a combination is not possible. Forward-Port-Of: odoo/odoo#199632
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were deleted before duplication. ## Steps to reproduce: - disable Analytic Accounting. - Create a service product that create a test, keep project empty. - create a project. - create a sale order with the service product and the project. - confirm the sale order. - remove the task that was created by
Original PR description
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were…
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were deleted before duplication. ## Steps to reproduce: - disable Analytic Accounting. - Create a service product that create a test, keep project empty. - create a project. - create a sale order with the service product and the project. - confirm the sale order. - remove the task that was created by the service product and delete the project. - duplicate the sale order. - confirm the duplicate sale order. - open the task created by the sale order. - try adding a timesheet to the task. - an error is raised saying that the analytic account doesn't exist. ## Root cause: - When we delete a project, it's linked analytic account is removed automatically by the `project_project` override of the `unlink` method, but it might be still referred in the analytic distribution of sale order line, so when we try fetching it in `_timesheet_preprocess_get_accounts` it gives the "Missing Record" error. ## Fix: - make sure the analytic account exists when browsing to them in `_timesheet_preprocess_get_accounts`. - fallback to super when there are no analytic accounts OPW-4474903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197061
When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199543
Original PR description
When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199543
When calling `account_move_line._compute_account_id` (via `action_update_fpos_values` for example), we wrongly delete a line after after assigning a new account here https://github.com/odoo/odoo/blob/22bdaf64ff3f2ee37cd51f0938d1bdd80f9e5ee8/addons/account/models/account_move_line.py#L599-L602 This is because we set a default value for `analytic_distribution` in `_prepare_base_line_tax_repartition_grouping_key`, therefore we enter in the wrong condition here https://github.com/odoo/odoo/blob/6ff
Original PR description
When calling `account_move_line._compute_account_id` (via `action_update_fpos_values` for example), we wrongly delete a line after after assigning a new account here…
When calling `account_move_line._compute_account_id` (via
`action_update_fpos_values` for example), we wrongly delete a line after
after assigning a new account here https://github.com/odoo/odoo/blob/22bdaf64ff3f2ee37cd51f0938d1bdd80f9e5ee8/addons/account/models/account_move_line.py#L599-L602
This is because we set a default value for `analytic_distribution` in
`_prepare_base_line_tax_repartition_grouping_key`, therefore we enter
in the wrong condition here https://github.com/odoo/odoo/blob/6ff943b30561f2d7415fdbdfc2246716428779be/addons/account/models/account_tax.py#L2407
because in `grouping_key`, we have `{'analytic_distribution': {}}` and in `tax_lines_mapping` we have`{'analytic_distribution': False}`
Steps:
- Have a fiscal position that map the default revenue account to another
- Create an invoice with the fiscal position created previously, add a
product line
- Unset fiscal position, and click on 'Update Taxes and Accounts' button
-> Error: "Record does not exist or has been deleted."
opw-4512877
Forward-Port-Of: odoo/odoo#198086Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199712 Forward-Port-Of: odoo/odoo#190704
Once an operator has been found, the chat bot should not do anything else. However, it can happen that a step trigger is requested by the client. While this should and will be prevented in another PR, the "/chatbot/trigger" route is perfectly aware of the state of the chat and should not do anything in this case. This PR fixes this issue. task-4607689 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I c
Original PR description
Once an operator has been found, the chat bot should not do anything else. However, it can happen that a step trigger is requested by the client. While this should and will be prevented in another PR, the "/chatbot/trigger" route is perfectly aware of the state of the chat and should not do anything in this case. This PR fixes this issue. task-4607689 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#199742
Some tests end with the selection in a link, leading the link popover to open, which blurs the editable element. To prevent that, we would focus the editable by force, then wait a tick. But when the CPU is slow, sometimes the focus into the link popover happens too late to redirect it. This waits for the popover to open before focusing the editable. runbot-112609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197201
Original PR description
Some tests end with the selection in a link, leading the link popover to open, which blurs the editable element. To prevent that, we would focus the editable by force, then wait a tick. But when the CPU is slow, sometimes the focus into the link popover happens too late to redirect it. This waits for the popover to open before focusing the editable. runbot-112609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197201
We add the variable msg_id and references to the test mail template MAIL_EML_ATTACHMENT to allow to use it as a response to another mail. We also add "subject" to allow to use test-related subject. Task-3707821 Forward-Port-Of: odoo/odoo#197641 Forward-Port-Of: odoo/odoo#154332
Original PR description
We add the variable msg_id and references to the test mail template MAIL_EML_ATTACHMENT to allow to use it as a response to another mail. We also add "subject" to allow to use test-related subject. Task-3707821 Forward-Port-Of: odoo/odoo#197641 Forward-Port-Of: odoo/odoo#154332
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions. Forward-Port-Of: odoo/odoo#199692 Forward-Port-Of: odoo/odoo#199599
Original PR description
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions. Forward-Port-Of: odoo/odoo#199692 Forward-Port-Of: odoo/odoo#199599
## Versions: 17.0+ ## Issue: Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view. ## Steps to reproduce: 1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`; 2. Add 1 attribute value; 3. Go to any product available on the shop (e.g. Acoustic Bloc Screens); 4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value; 5. Go to the shop
Original PR description
## Versions:
17.0+
## Issue:
Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view.
## Steps to reproduce:
1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`;
2. Add 1 attribute value;
3. Go to any product available on the shop (e.g. Acoustic Bloc Screens);
4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value;
5. Go to the shop via the `Website` app;
- *In normal web view, the filter is available on the left*
6. Change view to mobile mode and open the filters;
7. Open the "Extra filter and see no filter under it.
## Cause:
Mobile displayed filters are restricted to avoid color attributes but didn't expand to allow multi-checkboxes.
opw-4383970
Forward-Port-Of: odoo/odoo#198087Traceback when state (which is a non required field) is empty. Fix the express checkout flow. Bug introduced in 80507191 opw-4577470 Forward-Port-Of: odoo/odoo#199594
Original PR description
Traceback when state (which is a non required field) is empty. Fix the express checkout flow. Bug introduced in 80507191 opw-4577470 Forward-Port-Of: odoo/odoo#199594
Before this commit: ========== - We are not allowing multiple payment lines to be refunded or partial refunds. - We were showing `Waiting for card` for the terminal payment's refund process as payment status. After this commit: ========== - Refunds for multiple payment lines and partial refunds will be allowed. - We will show `Refund in process` for the terminal payment's refund process as payment status. task-4512844 Forward-Port-Of: odoo/odoo#195017
Original PR description
Before this commit: ========== - We are not allowing multiple payment lines to be refunded or partial refunds. - We were showing `Waiting for card` for the terminal payment's refund process as payment status. After this commit: ========== - Refunds for multiple payment lines and partial refunds will be allowed. - We will show `Refund in process` for the terminal payment's refund process as payment status. task-4512844 Forward-Port-Of: odoo/odoo#195017
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improv
Original PR description
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that…
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improve the styling rules to always disable bold on the deepest line level. That way we can never have a XLSX file with all lines in bold, and it is much easier to read the file. Meanwhile, the style management was refactored a bit to make it simpler. [opw-4501822](https://www.odoo.com/odoo/project.task/4501822) [opw-4458752](https://www.odoo.com/odoo/project.task/4458752) [indentation fix]: https://github.com/odoo/enterprise/commit/9246a864f91e7facd06fa630fa0d23a0323ce497 Forward-Port-Of: odoo/enterprise#79855 Forward-Port-Of: odoo/enterprise#77510
Update l10n_ar_reports and l10n_uy_edi translations. Task Adhoc side: 44224 Forward-Port-Of: odoo/enterprise#79104
Original PR description
Update l10n_ar_reports and l10n_uy_edi translations. Task Adhoc side: 44224 Forward-Port-Of: odoo/enterprise#79104
This commit is a patch to the following PR: https://github.com/odoo/enterprise/pull/76478#discussion_r1946575309 Steps to reproduce the bug: - Create two storable products “P1” and “P2”: - Tracked by Serial Number - Create a quality control point: - Operation: Receipt - Control per: Quantity - Create a receipt: - 10 units of P1 - 10 units of P2 - Mark it as "To Do." - Open the detailed operation of P1: - Assign two SNs: - SN1 - SN2 - Save. - The “Quantity” f
Original PR description
This commit is a patch to the following PR: https://github.com/odoo/enterprise/pull/76478#discussion_r1946575309 Steps to reproduce the bug:
- Create two storable products “P1” and “P2”:
- Tracked by Serial Number
- Create a quality control point:
- Operation: Receipt
- Control per: Quantity
- Create a receipt:
- 10 units of P1
- 10 units of P2
- Mark it as "To Do."
- Open the detailed operation of P1:
- Assign two SNs: - SN1 - SN2 - Save.
- The “Quantity” field of the P1 move is updated to 2.
- Mark the move of P1 as "Picked."
- Validate the receipt.
- The backorder wizard is triggered → Validate it.
Problem:
A wizard to process the quality check is triggered, but 12 quality checks (2 for P1 and 10 for P2) are loaded instead of only 2 for P1.
Expected Behavior:
Quality checks should only be triggered for picked moves
opw-4442564
Forward-Port-Of: odoo/enterprise#80467Community PR: https://github.com/odoo/odoo/pull/187536 Add support for the Tyro payment terminal (AU/NZ). The integration uses their iClient JS library, and all communication is done via their API and not with the terminal locally. Some behaviour is modified when using the Tyro payment method in order to comply with their certification: - Orders cannot be cancelled if they are partially paid - You cannot navigate away from the payment screen while a Tyro payment is in progress - Spe
Original PR description
Community PR: https://github.com/odoo/odoo/pull/187536 Add support for the Tyro payment terminal (AU/NZ). The integration uses their iClient JS library, and all communication is done via their API and not with the terminal locally. Some behaviour is modified when using the Tyro payment method in order to comply with their certification: - Orders cannot be cancelled if they are partially paid - You cannot navigate away from the payment screen while a Tyro payment is in progress - Specific payment lines can be chosen when refunding an order task-4086116 Forward-Port-Of: odoo/enterprise#80429 Forward-Port-Of: odoo/enterprise#79432
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#78982 Forward-Port-Of: odoo/enterprise#52832
Original PR description
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#78982 Forward-Port-Of: odoo/enterprise#52832
Seems like the tour takes steps while there may have been a delay in the web_save... seeming like there is an open form view in edition mode. runbot-111772 Forward-Port-Of: odoo/enterprise#79473
Original PR description
Seems like the tour takes steps while there may have been a delay in the web_save... seeming like there is an open form view in edition mode. runbot-111772 Forward-Port-Of: odoo/enterprise#79473
Followup report title and columns were not added to `.pot` file for translation Forward-Port-Of: odoo/enterprise#80210 Forward-Port-Of: odoo/enterprise#80131
Original PR description
Followup report title and columns were not added to `.pot` file for translation Forward-Port-Of: odoo/enterprise#80210 Forward-Port-Of: odoo/enterprise#80131
In Knowledge, on chromium-based browsers, zooming at certain levels will cause the comment icon to flail around the editor and lock in unwanted places. (This behavior was not reproductible in Firefox.) To circumvent this, the margin calculations for the purposes of calculating the comment icon horizontal location are now done manually. task-4558391 Forward-Port-Of: odoo/enterprise#79165
Original PR description
In Knowledge, on chromium-based browsers, zooming at certain levels will cause the comment icon to flail around the editor and lock in unwanted places. (This behavior was not reproductible in Firefox.) To circumvent this, the margin calculations for the purposes of calculating the comment icon horizontal location are now done manually. task-4558391 Forward-Port-Of: odoo/enterprise#79165
…onus Forward-Port-Of: odoo/enterprise#80376
Original PR description
…onus Forward-Port-Of: odoo/enterprise#80376
Steps to reproduce: 1. Add a embedded view in Knowledge, like a kanban view. 2. Add a new favorite filter. 3. The shared checkbox is shown. To address this issue, we need to use the `.context` since in owl the `._context` is giving inconsistent results, this due to how the rendering is being done, we sometimes will try to access the context before it is actually set, and we'll get a null value. With the `.context` we are sure that the context is set and we can access the `knowledgeEmb
Original PR description
Steps to reproduce: 1. Add a embedded view in Knowledge, like a kanban view. 2. Add a new favorite filter. 3. The shared checkbox is shown. To address this issue, we need to use the `.context` since in owl the `._context` is giving inconsistent results, this due to how the rendering is being done, we sometimes will try to access the context before it is actually set, and we'll get a null value. With the `.context` we are sure that the context is set and we can access the `knowledgeEmbeddedViewId` properly. opw Forward-Port-Of: odoo/enterprise#80287
This commit will do a backport of: https://github.com/odoo/enterprise/commit/eaf8361f44208346c20e4c50c2d9914ab2d4f3f5 and also remove some margin to have a more compacted view and will put most of the information in one div. task:4542756 Forward-Port-Of: odoo/enterprise#80282 Forward-Port-Of: odoo/enterprise#79233
Original PR description
This commit will do a backport of: https://github.com/odoo/enterprise/commit/eaf8361f44208346c20e4c50c2d9914ab2d4f3f5 and also remove some margin to have a more compacted view and will put most of the information in one div. task:4542756 Forward-Port-Of: odoo/enterprise#80282 Forward-Port-Of: odoo/enterprise#79233
Before this commit, in the wave and bubble layouts, the SVG acting as an overlay background of the footer was displayed on top of the report when entering the XML Editor of the reportEditor. This is due to multiple factors, all of which linked to how wkhtmltopdf works: - header and footers seem to be rendered in their own viewport, the top parameter is the start of the footer itself, not that of the page. - absolute positioning wrecks havoc in z-index with SVG's ..... Even though the HTM
Original PR description
Before this commit, in the wave and bubble layouts, the SVG acting as an overlay background of the footer was displayed on top of the report when entering the XML Editor of the reportEditor. This is due to multiple factors, all of which linked to how wkhtmltopdf works: - header and footers seem to be rendered in their own viewport, the top parameter is the start of the footer itself, not that of the page. - absolute positioning wrecks havoc in z-index with SVG's ..... Even though the HTML of the waves' and bubbles' layouts doesn't seem very well written, it does work in the current state of the art of Odoo's PDF rendering. This commit adapts the JS code in the XML editor of the reportEditor to account for it. opw-4508900 Forward-Port-Of: odoo/enterprise#77863
Have a field in a view like this ```<field name="" options="{ some_boolean: 1 }" />``` And have the corresponding supportedOption (defined on the field widget): ```{ somme_boolean: { type: "boolean" } }``` Open studio and click on that field, in debug mode. Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean. Forw
Original PR description
Have a field in a view like this
```<field name="" options="{ some_boolean: 1 }" />```
And have the corresponding supportedOption (defined on the field widget):
```{
somme_boolean: {
type: "boolean"
}
}```
Open studio and click on that field, in debug mode.
Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean.
Forward-Port-Of: odoo/enterprise#80014Test changed in d5da2b62263f85fbce0f2548085c066cbbf10371 needs to be changed back because of https://github.com/odoo/odoo/pull/198086 opw-4512877 Forward-Port-Of: odoo/enterprise#79576
Original PR description
Test changed in d5da2b62263f85fbce0f2548085c066cbbf10371 needs to be changed back because of https://github.com/odoo/odoo/pull/198086 opw-4512877 Forward-Port-Of: odoo/enterprise#79576
Remove the restrictions of the make_scss_customizations from the website generator and instead let the website scraper have full control. Forward-Port-Of: odoo/enterprise#80266
Original PR description
Remove the restrictions of the make_scss_customizations from the website generator and instead let the website scraper have full control. Forward-Port-Of: odoo/enterprise#80266
__Steps to reproduce:__ 1. Create a project (billable). 2. Give the user access to Company A + B, while the default is A 3. Add a task with a customer belonging to company B 4. Create a task and add products to it. __Description of the issue:__ - The **"Decrease"** button is disabled, with raised error message that the amount is delivered. - This happens because the domain fetching `stock.move` uses user’s default company instead of SO’s company which leads to the wrong default WH _
Original PR description
__Steps to reproduce:__ 1. Create a project (billable). 2. Give the user access to Company A + B, while the default is A 3. Add a task with a customer belonging to company B 4. Create a task and add products to it. __Description of the issue:__ - The **"Decrease"** button is disabled, with raised error message that the amount is delivered. - This happens because the domain fetching `stock.move` uses user’s default company instead of SO’s company which leads to the wrong default WH __Description of the solution:__ - Update warehouse logic to fetch the default warehouse using the SO’s company context, ensuring `stock.move` domain aligns with the sale order’s company - opw-4471366 Forward-Port-Of: odoo/enterprise#80007
[FIX] documents: fix documents creation on documents 1. Fix reply with an attachment on message from existing document How to reproduce: - Go to the chatter of a document - Add yourself as a follower - Send a message from the chatter: you should receive an email - Reply to this email with an attachment You receive a delivery error message ("Address not found") and your reply doesn't appear in the chatter, nor your attachment. With this fix, the message with its attachment appears
Original PR description
[FIX] documents: fix documents creation on documents 1. Fix reply with an attachment on message from existing document How to reproduce: - Go to the chatter of a document - Add yourself as a follower…
[FIX] documents: fix documents creation on documents
1. Fix reply with an attachment on message from existing document
How to reproduce:
- Go to the chatter of a document
- Add yourself as a follower
- Send a message from the chatter: you should receive an email
- Reply to this email with an attachment
You receive a delivery error message ("Address not found") and your reply doesn't appear in the chatter, nor your attachment.
With this fix, the message with its attachment appears in the chatter and there is no delivery error message.
2. Fix sending a message with an attachment on a request
How to reproduce:
- Go to the chatter of a request
- Send a message with an attachment from its chatter
You get the error "The operation cannot be completed: This attachment is already a document." while the message with its attachment should be added in the chatter.
With this fix, the message with its attachment appears in the chatter and the request remains to be fulfilled.
3. Error while uploading a requested document through activity popover
How to reproduce:
- As user A, create a requested document for User B
- As user B, click on the activity of that request and upload a document
You get the error "The operation cannot be completed: This attachment is already a document." while the uploaded file should be linked to the request.
With this fix, the request is fulfilled, and you get no error.
We solve those problems by not creating document by default when messages with attachments are posted on a document and delegate the creation of the documents to the _message_post_after_hook method for the case of a post on a folder alias. We have chosen that default behavior as in all uses case except the alias, we expect the attachment to be added to the chatter and not as a new document.
TestMailGateway already tests that incoming mail with attachment on an alias create the related documents, and we introduce a test for each case described above in other commits.
[IMP] documents: add a test on replying with an attachment on a document post
We add a test that check that when answering a mail posted on a document with an attachment, that the attachment is added to the document and the message is posted on the document.
We also modify slightly an existing test because a parameter given to _message_post_after_hook was incorrect.
[IMP] documents: add a test on document type change when sending a message
We add a test that check that when sending a message on a URL or a request document, it is not turned into a binary document.
[IMP] documents: add a test that upload a document in the activity popover
We add a test that upload requested document through activity popover.
Task-3707821
Forward-Port-Of: odoo/enterprise#80037
Forward-Port-Of: odoo/enterprise#56779- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
Original PR description
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016