Monday, July 7, 2025
14 changes · 18.0
Enhancements to existing features
Shared helper code for tax-related invoice tests was moved into a common testing area. This makes the accounting test suite easier to maintain and helps future tax changes be validated more consistently, without changing customer-facing behavior.
Original PR description
…tInvoicingCommon --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting journal dashboard has been adjusted so activity information can be customized more easily by related accounting features. This supports more dynamic styling and presentation of dashboard activities, helping future enhancements appear consistently for users.
Original PR description
This commit applies the necessary changes to make the json_activity_data field of account.journal extensible. The field computation needed to be extended in account_reports to make dashboard activities styling more dynamic. More details can be found in the enterprise PR: https://github.com/odoo/enterprise/pull/89331 backport of: https://github.com/odoo/odoo/commit/dce24cd242e16afde008ac907faa5f496725ae68 task-4370133 task-4458309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202249
Resolved issues and error corrections
This fix ensures that when a manufacturing bill of materials is copied, its by-product lines are linked to the copied operation instead of the original one. This prevents confusion and incorrect production setup references after duplicating bills of materials.
Original PR description
### Issue: Copying a bom with an operation will not reassign the copied operation to the by product lines. ### Steps to reproduce: - In the settings enable operations and by-products - Create a bom with an operation op1 and a by product produced in op1 - Copy the bom #### > The copied by product line refer to the operation of the original bom this can be checked by archiving the copied operation which should erase its link with the copied by product line but will not ### Cause of the issue: When a bom is copied, the new operation is reassigned to the new bom lines by these lines: https://github.com/odoo/odoo/blob/9cb4230a6b2252243a8e0546a1a8f5bc52e74009/addons/mrp/models/mrp_bom.py#L230-L247 However, nothing is made for the by product lines. opw-4788252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216609
Miscellaneous changes
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer.
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer. The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model. The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well. opw-4790299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215887
This fix ensures MyInvois point-of-sale documents correctly calculate and assign their linked orders for every relevant record. It prevents missing order links that could cause errors or incomplete document information in Malaysia e-invoicing flows.
Original PR description
Otherwise, it causes it fails to assign value to certain records, which is unadvised. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes duplicate test helper code in the Accounting module. It keeps the test setup cleaner and reduces maintenance risk, with no expected impact on everyday users or business workflows.
Original PR description
In 0f3a9dee5cf15 we added helpers to create test taxes in `AccountTestInvoicingCommon`, not realizing that they were already in `TestTaxCommon`. This commit removes them from `TestTaxCommon` to avoid the duplication. task-none
This update fixes an internal test setup for Malaysia POS e-invoicing so it no longer relies on an unavailable enterprise component. This helps community-only test runs complete reliably without affecting customer-facing features.
Original PR description
The test in this module imports a common setup from account_reports which is not a dependency, and is not auto installed when the test runs with community modules only. This fix replaces the setup by the community one AccountTestInvoicingCommon. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures text background styling is preserved when website text animations are applied. It helps keep animated website content visually consistent and prevents design details from disappearing or rendering incorrectly.
Original PR description
... task-4285621
This update fixes how the online shop verifies sale orders by reusing an existing system check instead of duplicating logic. This should make checkout-related behavior more consistent and reduce the risk of errors when validating website orders.
Original PR description
Use existing method to check 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
Fixed an issue where custom plan fields added to timesheet views could lose their selected value when a new timesheet was saved. This ensures user-entered planning information is preserved, improving reliability for teams using customized timesheet workflows.
Original PR description
### Steps to reproduce: - Navigate to a Project > View (Timesheets) - Open studio and add x_plan2_id for example to the view - Try creating a new timesheet and set a value for the field we added using studio - Save and notice the field doesn't keep its value ### Cause: This is mainly happening because when getting the plan_ids for the account we are gonna fill we just get the account in the distribution and ignore if the user is setting another value ### Fix: We check the create vals_list if a plan has value we set it before setting the account in the distribution opw-4716041
This update ensures the Indian GSTR-1 report export always includes the expected document issue field, even when there are no entries. It prevents automated validation failures and helps keep tax reporting exports consistent and reliable.
Original PR description
- Assigned doc_issue with empty list to comply with formatting of gstr1 json. - This prevents test failures caused by missing keys during JSON validation. runbot error: 229705
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Validate the Reception of the order -> Result: Odoo will prompt the customer to select a printer, however we are not able to choose a printer in tim
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Validate the Reception of the order -> Result: Odoo will prompt the customer to select a printer, however we are not able to choose a printer in time as the process continues without selecting one. This in return does not send the report to the printer via IoT. The root cause of this bug is that the IoT report handler JS function returns too early, it resolves once the printer selection popup has appeared, instead of resolving once the printer has actually been selected and is starting to print. Therefore the multi-report printing code assumes the print is done and triggers the next print, which causes the popup to close before the user can select a printer. To solve this bug, we listen for a 'printer-selected' event in the handler, and resolve only once we have received this event. This fixes the flow, allowing a printer to be selected for each report that is being printed in sequence. opw-4790299 Forward-Port-Of: odoo/enterprise#88538
Currently when /iot/setup method is called if the iot box record exists we always update the record with the received data, even if the data is the same as the record's data. This PR only updates it if the data changes Forward-Port-Of: odoo/enterprise#88043
Original PR description
Currently when /iot/setup method is called if the iot box record exists we always update the record with the received data, even if the data is the same as the record's data. This PR only updates it if the data changes Forward-Port-Of: odoo/enterprise#88043
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with - Date far in the past (ie 2024-01-01) - Account: "400000 Customers", Partner: "test partner", Debit: 500.0 - Account: "499000 Suspense Accounts", Credit: 500.0 - Post - In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified - Accou
Original PR description
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with -…
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with - Date far in the past (ie 2024-01-01) - Account: "400000 Customers", Partner: "test partner", Debit: 500.0 - Account: "499000 Suspense Accounts", Credit: 500.0 - Post - In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified - Accounting Dashboard > Bank > new with Amount: 500.0 - "Save & Close" then click on it - In the page "Manual Operations" change the partner to the one from the MISC entry - Change the Account to "400000 Customers" - Validate - The follow-up report is no longer "In need of action" - Create an invoice with a due date in the future - The follow-up report is back to "In need of action" with the amount of the invoice - When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€" ### Cause: The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€. The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`. ### Solution: So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`. opw-4784250 Forward-Port-Of: odoo/enterprise#87873