Daily updates from Odoo
Tuesday, July 8, 2025
85 changes
29 changes
Resolved issues and error corrections
This fixes an issue where text entered in the website builder, such as “<br>”, could be incorrectly changed when saving translations, blog titles, or reusable blocks. Users can now save literal text with special characters without it turning into the wrong display or HTML behavior.
Original PR description
> 65. Special character written in translation are being converted into HTML Entity name like `<br> => <br>`
Copying a manufacturing bill of materials now correctly links by-products to the copied operation instead of the original one. This prevents confusion or incorrect production setup when teams duplicate manufacturing recipes that include operations and by-products.
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#217319 Forward-Port-Of: odoo/odoo#216609
This update applies follow-up corrections requested after an earlier merge, focused on demo data used in accounting and Belgian localization. It helps keep sample setups accurate and consistent for testing, demonstrations, and onboarding scenarios.
Original PR description
After [this PR](https://github.com/odoo/odoo/pull/209628) was merged, a few last comments were made, this commit includes the changes suggested in those comments. --- task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216815
This fix prevents a website image hover effect from being destroyed more than once. It helps avoid unnecessary errors during page interactions, improving reliability for visitors and editors.
Original PR description
In case the interaction is destroyed, we should not try to destroy it again. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an Inventory issue where reception reports and labels were downloaded as PDFs instead of being sent to the assigned IoT printer. The system now retrieves the proper report setup from the server, so warehouse teams can print reception documents through their configured devices as expected.
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#217693 Forward-Port-Of: odoo/odoo#215887
The settings help text for intercompany rules was corrected to say that vendor bills are created, not invoices. This avoids misleading users when configuring intercompany transactions.
Original PR description
This commit: https://github.com/odoo/odoo/commit/e2a0c6edb8c9c1fd0aba2f92f9187678e68971a9 change a help in the intercompany rules. The help sentence is wrong since we don't create invoice but bills. task-4907810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217275
Point of Sale receipts now show the cashier who is active when the order is paid, rather than the cashier first assigned to the order. This prevents incorrect staff attribution on receipts when the cashier is changed during payment.
Original PR description
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038 Forward-Port-Of: odoo/odoo#216339 Forward-Port-Of: odoo/odoo#215543
This fixes an upgrade issue where empty text filter defaults in spreadsheets were treated as actual filter values. After the change, empty defaults are correctly recognized as no default value, preventing unintended filters after upgrading.
Original PR description
The upgrade script from saas-18.3 to saas-18.4 converting the default value of text filter is wrong. It didn't account for the empty string which should be considered as "no default value" `defaultValue: "hello"` --> `defaultValue: ["hello"]` correct `defaultValue: ""` --> `defaultValue: [""]` not correct Task: 4926326 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated test for website color customization so it waits correctly for background updates to finish. It helps keep website editing quality checks stable and reduces false failures during release validation.
Original PR description
Waiting an animationFrame after each click (fix done in [1]) was not sufficient, we actually need to wait for 2 or 3 separate ticks depending on the case, because `customizeWebsiteColors` calls between 2 and 3 debounced functions (`debouncedSCSSColorsCusto`, possibly `debouncedSCSSVariablesCusto`, and finally `reloadBundles`) with a 0-ms delay. [1]: https://github.com/odoo/odoo/commit/cbcd1b142e2a1c6a245fa8a993ecc8ebd72eece4 runbot-229604 runbot-229686
Fixed a Point of Sale loyalty issue where refunding an order paid with reward points could deduct those points a second time. Refund transactions now avoid recharging loyalty points, preventing customers from unfairly losing rewards.
Original PR description
**Problem:** When refunding an order that has been paid using a reward system, the points are deducted again as if the client made another purchase using those points. This means that in the case of a refund, the client would not only lose those points but have to spend them again. **Steps to reproduce:** - Make a purchase in POS using a reward such as $1 for every point - Refund this purchase - The points are deducted again **Why the fix:** The points do not need to be refunded after a refund, but they don't have to be paid again. The total point for this refund order is now set to zero in case of a refund. This means the transaction will not be visible on the Coupon Card in the Loyalty Program. opw-4771724 Forward-Port-Of: odoo/odoo#217010 Forward-Port-Of: odoo/odoo#212922
The IoT Wi-Fi status check now avoids triggering slow network scans when loading homepage data. This prevents occasional 5-15 second delays and gives users a faster, more consistent homepage experience.
Original PR description
Before this commit, the `get_current()` method in the wifi helper would occasionally run very slowly, taking 5-15 seconds. This is because the `nmcli` command it was calling would periodically re-scan the network so the information it returned was up-to-date. Because the homepage data controller used this method, it would also sometimes take 5-15 seconds to load, leading to a bad experience for the user. After this commit, the `get_current()` method uses a different `nmcli` command that only shows the status of the currently connected network, avoiding a re-scan and therefore always running quickly. task-4922640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217682
A typo in the IoT driver update process caused a configuration update to fail, which could block git checkout during updates. This fix corrects the issue so the update process can complete normally.
Original PR description
Introduced in odoo/odoo#213177. A simple typo meant the `update_conf` method was being called with a set instead of a dict, leading to an error being thrown and preventing the git checkout. This commit fixes the typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215397 Forward-Port-Of: odoo/odoo#215230
This fixes an automated website donation test so it handles the payment confirmation redirect as a single step. The change helps prevent false test failures and keeps the donation payment flow validation stable.
Original PR description
In this commit, we fix the donation_snippet_use tour. At the end of the tour, when you click on submit donation, you are redirected to a page "Your payment has been processed." From this page, you are then redirected to a page with "Thank you". This intermediate redirection page can be a problem if there are several steps that concern it because we do not know when the redirection will be triggered (in the first or the second step?) Therefore, it is essential to have only one step for intermediate redirections. 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#217448 Forward-Port-Of: odoo/odoo#216558
This update fixes an error that occurred when using the website editor to toggle Suggested Accessories. It updates the affected website sales views to match the newer template structure, so editors can manage these options without interruptions.
Original PR description
Description of the issue/feature this PR addresses: This issue has happened because of the standard change in the module. Current behavior before PR: Traceback click on Suggested Accessories, the…
Description of the issue/feature this PR addresses: This issue has happened because of the standard change in the module. Current behavior before PR: Traceback click on Suggested Accessories, the toggle button through the website editor. in v18.2 the module [website_event_sale](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_event_sale/views/website_sale_templates.xml#L24) and [website_sale_loyalty](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale_loyalty/views/website_sale_templates.xml#L128) is inherit the cart_line and target the [node](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/views/templates.xml#L2087) is available in the view. But in version 18.3 this node is move to other [template](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/views/templates.xml#L2341) that's why the node is not find. Desired behavior after PR is merged: After the change i target the new [template](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/views/templates.xml#L2435) so the node is now find. Issued PR-190720 [OPW- 4864959](https://www.odoo.com/odoo/project/70/tasks/4864959?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215180
This fixes an issue in the website editor where the overlay used to adjust a background image could appear at the wrong size in some page sections. The change makes the editing controls display correctly, helping users position background images without broken overlays or misplaced tooltips.
Original PR description
Before this commit in some snippets background overlay wouldn't have proper height because of the parent elements' height. This commit overrides it with `!important`. To reproduce the issue: - open website and start editing - drop columns snippet, add background image to one of the columns, click on it - Click on the background position option to change it(the one with a crosshair icon) - the overlay isn't shown properly, which also breaks the tooltip position Commit follows [the html_builder refactoring]. Copy of https://github.com/odoo/odoo/pull/215377 [the html_builder refactoring]: odoo/odoo@9fe45e2b7ddb Related to task-4367641
Users creating a time off allocation can now remove the validity period without immediately triggering a system error. The form will instead show the normal required-field warning when saved, making the process clearer and preventing an unnecessary crash.
Original PR description
An error occurs if the Validity Period is removed while creating a new allocation. Steps to reproduce: --- - Install the `hr_holidays` module - Time Off > My Time > My Allocation - Open New and remove the `Validity Period` Traceback: --- `AttributeError: 'bool' object has no attribute 'strftime'` This commit ensures that changing the date won't cause an error, but instead will display a warning upon saving the form, as it is a required field. sentry-6709097746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216015
Sale orders created from CRM no longer carry the CRM lead's default salesperson into related records during confirmation. This prevents quality checks from being assigned to the wrong user, improving accuracy for teams using sales, CRM, and quality workflows.
Original PR description
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 Forward-Port-Of: odoo/odoo#215499
This fix makes automated checks for live chat chatbot step ordering more reliable under heavy system load. It ensures the step text is fully saved before continuing, reducing false test failures without changing business functionality.
Original PR description
This commit fixes the `test_chatbot_steps_sequence_ui` and the `test_chatbot_steps_sequence_with_move_ui` tours. Those tours create chat bot steps to check their order. To do so, they edit the textarea and click on the save button. However, under high load, the button can be clicked before the textarea is updated. When this occurs, the validation fails and the step is not created. This commit fixes the issue by waiting for the textarea content to update before clicking on the save button. fixes runbot-228498 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts an internal performance test so it matches the current expected behavior in the Discuss test suite. It helps keep automated checks accurate and reduces false alarms for developers, with no direct impact on end users.
Original PR description
Changing the `channel _to_store_defaults` query count to the correct value. This increase is related to #216031.
When creating a refund, users will no longer see unrelated receipt or move types in the selector. This keeps the refund process clearer and helps prevent accidental selection of an incorrect document type.
Original PR description
Currently, when creating a refund, the move type selector shows all possible move_type out there. We obviously don't want that... Solution: show only the current move type for refunds. task-4926014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents translation-related errors that could occur when sharing referral links or working with loan records. It changes how translated text is prepared so the system can reliably access the information it needs, improving stability for affected workflows.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198 Forward-Port-Of: odoo/enterprise#88632
This fixes Planning so copied shifts calculate open shift hours correctly when an employee is on leave. It prevents lunch breaks from being counted as extra working time, improving schedule accuracy and avoiding overstated allocated hours.
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#89502
Forward-Port-Of: odoo/enterprise#73478The intercompany rules settings label for creating invoices was renamed to make its purpose easier to understand. This reduces confusion for users configuring automated transactions between companies.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/4b57698670a7762bb206ccb24417d63c8edc1a46 change the ux of the intercompany rules, but the naming is confusing for users. task-4907810 Forward-Port-Of: odoo/enterprise#89368
This fixes a validation error when using Sendcloud batch shipping for deliveries split into packages with average weights that are not whole numbers. The system now sends weights in the integer format required by Sendcloud, allowing affected deliveries to be validated successfully.
Original PR description
### Steps to reproduce: - Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method. - Create a…
### Steps to reproduce:
- Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method.
- Create a storable product with a weight of 1 kg and a positive volume.
- Create and confirm sale order for 4 units
- Add shipping -> chose sendcloud
- Separate the delivery of 4 kg in 3 packs:
- set quantity to 1 -> put in pack
- set quantity to 2 -> put in pack
- set the quantity to 4 -> put in pack
- Try to validate the delivery
#### > invalid operation: weight: "A valid integer is required."
### Cause of the issue:
Sendcloud's api only accept integer values for the weight:
However, to evaluate the price of the parcel accurately for a batch shipping we need to compute the average weigth to provide to sendcloud. Converted to grams we tehrefore provide a value of 1333.333333 to sendcloud which raises an invalid operation:
https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L378-L379 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L205-L207 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L44
opw-4874063
Forward-Port-Of: odoo/enterprise#89495This fix ensures Odoo waits for the user to choose a printer before continuing with queued reception reports and labels. It prevents the printer selection window from closing too soon, so documents are correctly sent to the IoT-connected printer during inventory reception workflows.
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#89617 Forward-Port-Of: odoo/enterprise#88538
Studio now closes the New Model dialog immediately after a user confirms it, instead of leaving it visible while waiting for the server. This removes a brief flicker and makes creating models feel smoother and more responsive.
Original PR description
This commit fixes a minor UX issue where the "New Model" dialog in Studio would remain visible briefly after confirmation, causing a flicker while waiting for the server response. The dialog now closes immediately upon confirmation, providing a smoother user experience. task-4809049 Forward-Port-Of: odoo/enterprise#88964
Installing Field Service with Sales no longer fails if the default Services product category was previously deleted. The setup now skips the missing category instead of stopping with an error, helping users complete installation without manual repair.
Original PR description
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `industry_fsm_sale` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError
while parsing /home/odoo/src/enterprise/saas-18.3/industry_fsm_sale/data/industry_fsm_data.xml:5, somewhere inside <record id="field_service_product" model="product.product">
<field name="name">Field Service</field>
<field name="project_id" search="[('id', '=?', ref('industry_fsm.fsm_project', raise_if_not_found=False)), ('is_fsm', '=', True)]"/>
<field name="service_tracking">task_global_project</field>
<field name="type">service</field>
<field name="categ_id" ref="product.product_category_services"/>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6377659355
Forward-Port-Of: odoo/enterprise#89510UPS deliveries to customers in Mexico can now be processed successfully because each package includes the required merchandise description. This prevents shipment validation failures caused by missing package-level information in the UPS REST connector.
Original PR description
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a…
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a Merchandise Description.` **Expected behavior:** Can process shipment. **Steps to reproduce:** 1. Create a UPS rest delivery option 2. Create an SO for some product to a Mexico-based client, add the UPS delivery, confirm, try to validate the delivery -> 400 **Cause of the issue:** For non-return shipments, the description in the Package object is `None`, but when the receiver is based in Mexico, this field is required. **Fix:** Create a package level description based on the one added here: https://github.com/odoo/enterprise/commit/a7b8673364e0ac626bcc8ded72501c4f2866564c To the UPS API spec here: https://developer.ups.com/tag/Shipping?loc=en_PE&tag=Rating#operation/Shipment!path=ShipmentRequest/Shipment/Package/Description&t=request opw-4508139 Forward-Port-Of: odoo/enterprise#86411
Credit notes in the Kenya eTIMS integration can now only be submitted when the related invoice has already been successfully submitted. This helps prevent rejected or invalid tax submissions and keeps credit notes properly tied to compliant invoice records.
Original PR description
To ensure credit notes are only submitted for invoices that have been submitted to eTIMS, we now restrict credit note submission to cases where the related invoice has already been successfully submitted. Forward-Port-Of: odoo/enterprise#89464 Forward-Port-Of: odoo/enterprise#89385
14 changes
Resolved issues and error corrections
This fix ensures the refund reason popup appears correctly when Spanish TicketBAI POS compliance and Peruvian POS electronic invoicing are both installed. It prevents refund workflows from skipping required information, helping businesses stay compliant and avoid cashier confusion.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/enterprise#89423 Forward-Port-Of: odoo/enterprise#88813
The map view now opens Google Maps using the contact's full address instead of relying on stored coordinates that may be imprecise. This helps users get the correct destination when choosing "View in Google Maps" from a contact marker.
Original PR description
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be…
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be slightly different from given one (when using OpenStreeMap) - Click on the position marker > `Navigate To` the address is recomputed correctly - Click on `View in Google Maps` the address given is often wrong **Issue:** Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results. As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results. **Fix:** Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps. opw-4649910 Forward-Port-Of: odoo/enterprise#87430
Removing a field matching from a spreadsheet global filter is now saved correctly. This prevents deleted filter links from reappearing after users save their changes, making spreadsheet filter editing more reliable.
Original PR description
Steps to reproduce: 1. Open a spreadsheet with global filters. 2. Open the global filter editor. 3. Open a global filter. 4. Delete the field matching (and nothing else). 5. Save the global filter. => The field matching is not saved. This was due to the fact that the removal of the field matching makes an early return in the `updateFieldMatching` method, which had for last instruction to set the `draft` property to mark the filter as dirty. This commit fixes the issue by ensuring that the `draft` property is set even when the field matching is removed. Task: 4882261
This change updates the manufacturing work order test setup to use a dedicated test order numbering pattern. It helps avoid conflicts with sample data, making automated checks more stable without affecting normal users.
Original PR description
This commit modifies the MO sequence as defined in the test's setup from "WH/MO/" to "WH/TEST/MO", this way, there won't be any name's conflict with MO created by demo data. Runbot build error: [223328](https://runbot.odoo.com/odoo/error/223328)
Customer follow-up reports no longer treat accounting entries without a due date or payment term as overdue. This prevents customers from being incorrectly flagged for collection action or receiving statements that show inconsistent outstanding balances.
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: The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due. 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#89627 Forward-Port-Of: odoo/enterprise#87873
Users with view-only access no longer see the option to split PDF documents. This prevents a confusing error and keeps document actions aligned with each user's permission level.
Original PR description
When a user with only view permissions attempts to split a PDF, an error occurs: Unexpected token '<', "<!doctype "... is not valid JSON **Steps to Reproduce:** - Go to Documents. - Choose a PDF file. - Click on Share and select Internal Users with Viewer permission. - Copy the generated link. - Open the link in another window as a non-manager user. - Click on split PDF then split The fix consists in hiding the pdf split functionality for users without edit permission. opw-4354451 Forward-Port-Of: odoo/enterprise#89328 Forward-Port-Of: odoo/enterprise#75803
This update fixes an issue that could cause errors when translated text was generated in employee referrals and loan workflows. The change improves reliability for users working in translated environments without changing business functionality.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198 Forward-Port-Of: odoo/enterprise#88632
Sendcloud batch shipping could fail when average parcel weights produced decimal gram values, because Sendcloud requires whole-number weights. This fix ensures parcel weights are sent in an accepted format, allowing users to validate deliveries split into multiple packs without errors.
Original PR description
### Steps to reproduce: - Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method. - Create a…
### Steps to reproduce:
- Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method.
- Create a storable product with a weight of 1 kg and a positive volume.
- Create and confirm sale order for 4 units
- Add shipping -> chose sendcloud
- Separate the delivery of 4 kg in 3 packs:
- set quantity to 1 -> put in pack
- set quantity to 2 -> put in pack
- set the quantity to 4 -> put in pack
- Try to validate the delivery
#### > invalid operation: weight: "A valid integer is required."
### Cause of the issue:
Sendcloud's api only accept integer values for the weight:
However, to evaluate the price of the parcel accurately for a batch shipping we need to compute the average weigth to provide to sendcloud. Converted to grams we tehrefore provide a value of 1333.333333 to sendcloud which raises an invalid operation:
https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L378-L379 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L205-L207 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L44
opw-4874063
Forward-Port-Of: odoo/enterprise#89495This fix prevents upgrade failures when the Belgian disallowed expenses setup references accounts that are not present in older databases. It only updates accounts that already exist, making upgrades more reliable without changing day-to-day functionality.
Original PR description
The accounts being updated are [added](https://github.com/odoo/odoo/commit/fe8570caf8eb8067fba800cf0d76de78d9cf8585) in saas-18.3. When upgrading from earlier versions the [init hook](https://github.com/odoo/enterprise/blob/0250ade8e90b4590318c152864c42d5fc5a62338/l10n_be_disallowed_expenses/models/account_chart_template.py#L11) will load the module's csv and fail because the accounts do not exist. This fix adds a filter on existing accounts. runbot error https://runbot.odoo.com/odoo/runbot.build.error/224150
UPS deliveries to customers in Mexico previously failed because a required merchandise description was missing from package data. This fix adds the needed package-level description so those shipments can be processed successfully.
Original PR description
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a…
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a Merchandise Description.` **Expected behavior:** Can process shipment. **Steps to reproduce:** 1. Create a UPS rest delivery option 2. Create an SO for some product to a Mexico-based client, add the UPS delivery, confirm, try to validate the delivery -> 400 **Cause of the issue:** For non-return shipments, the description in the Package object is `None`, but when the receiver is based in Mexico, this field is required. **Fix:** Create a package level description based on the one added here: https://github.com/odoo/enterprise/commit/a7b8673364e0ac626bcc8ded72501c4f2866564c To the UPS API spec here: https://developer.ups.com/tag/Shipping?loc=en_PE&tag=Rating#operation/Shipment!path=ShipmentRequest/Shipment/Package/Description&t=request opw-4508139 Forward-Port-Of: odoo/enterprise#86411
This fixes an internal testing issue that could miss required database indexes during development but catch them later in nightly runs. The change makes validation more consistent and adds the missing indexes, reducing late CI failures and helping keep performance safeguards reliable.
Original PR description
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria…
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria used to ignore the field for indexing was if it belongs to a `test` model in some test module. The best-effort heuristic used for this is to see if there is some `ir.model. data` associated with the model in question and if all module's names associated with these data entries have `test`, then we can ignore the field for indexing. But due to the semantics of `all` for empty collections: ```py assert all([]) is True ``` models that had *no* `ir.model.data` associated at all, e.g. install `--without-demo` and no master data, the field would be ignored for indexing, leading to a passing test. But on nightly, where the CI is run with demo data also, the field isn't ignored anymore and is caught by the test's assertion for indexing suggestion as expected. This leads to errors that are never addressed by the developer that added the fields in question. This commits corrects the test and add the missing indexes that were raised from the CI's false-positive that were missed. Reference --------- runbot-227546
This fixes an issue where Odoo could move on before a user had time to choose a printer for reception reports and labels. Printer selection now waits for the user’s choice, helping ensure each document is sent correctly through the IoT-connected 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. 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#89617 Forward-Port-Of: odoo/enterprise#88538
Installing Field Service Sales no longer fails if the default Services product category was previously deleted. The setup now continues by leaving that category unset, helping customers avoid a blocking installation error.
Original PR description
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `industry_fsm_sale` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError
while parsing /home/odoo/src/enterprise/saas-18.3/industry_fsm_sale/data/industry_fsm_data.xml:5, somewhere inside <record id="field_service_product" model="product.product">
<field name="name">Field Service</field>
<field name="project_id" search="[('id', '=?', ref('industry_fsm.fsm_project', raise_if_not_found=False)), ('is_fsm', '=', True)]"/>
<field name="service_tracking">task_global_project</field>
<field name="type">service</field>
<field name="categ_id" ref="product.product_category_services"/>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6377659355
Forward-Port-Of: odoo/enterprise#89510This update prevents an error during Point of Sale IoT setup when assigning a barcode scanner. It helps businesses configure scanner devices reliably and avoid setup interruptions.
Original PR description
The error occurs because `append()` is used on the Many2many field `iface_scanner_ids` in `pos_config`, which is not allowed. Traceback: `AttributeError: 'iot.device' object has no attribute 'append'` Many2many fields should be updated using `|=` to add records, as the Python list method `append` is not supported for relational fields. [1]- https://github.com/odoo/enterprise/blob/5bff585cfa24940626b14cdeaeae07b50a931e94/pos_iot/wizard/auto_config_pos_iot.py#L55 sentry-6719710908
13 changes
Resolved issues and error corrections
Customer statement emails now use the sender or reply-to address configured on the email template. This ensures businesses can control which address customers see and reply to, instead of unintentionally using the current user's email address.
Original PR description
Steps to reproduce:
Go to Settings> Email templates
Open the template Customer statements
Change the value in email from or reply to
Go to Accounting > Customers > Customers
Open a customer
Send a customer statement
Issue:
The address in use is not the same as we specified in the customer template
Cause:
if no email_from is provided, we will use the current partner's use's email address https://github.com/odoo/odoo/blob/cc0aaff5f93d5332c60d5bd8097173326a0a12b3/addons/mail/models/mail_thread.py#L2863-L2864
We don't check if the template has any email_from address defined
Note:
As from this fix, if no address is defined, by default it will be the `{{ object._get_followup_responsible().email_formatted }}`
opw-4864155
Forward-Port-Of: odoo/enterprise#88262Users can now open Studio from the Documents app even when a document shortcut is selected. This prevents an error that interrupted customization workflows in Documents.
Original PR description
Steps: - Install `documents` and `studio` - Open documents, go to list view - Select a random file and 'Create a shortcut' via the actions - Try to open studio - traceback opw-4900667 Forward-Port-Of: odoo/enterprise#89508
This fix ensures field service tasks opened from the calendar use the intended form layout. It keeps the scheduling workflow consistent after a related platform change, reducing the chance of users seeing the wrong task screen.
Original PR description
This commit is the counter part of odoo/odoo#216631 which removes a parameter to the editRecord function. Task-4910395 Forward-Port-Of: odoo/enterprise#88987
Marketing automation campaign tests can once again include tracked link clicks, restoring coverage for click-based journeys. The update also prevents overlapping tests for the same campaign and target from interfering with each other, making results more reliable while still allowing separate tests to run in parallel.
Original PR description
Previously, marketing campaign testing (through debug) could cause an issue where tracked links could cause a traceback if a marketing activity was edited after a test was attempted. To work around…
Previously, marketing campaign testing (through debug) could cause an issue where tracked links could cause a traceback if a marketing activity was edited after a test was attempted. To work around this, #13665 deactivated link tracking in marketing campaign tests. However, this meant that flows including click actions could no longer be tested. As this issue has been resolved in odoo/odoo#48845, this commit reverts https://github.com/odoo/enterprise/pull/13665 to once again permit marketing automation testing. -- Additional changes are needed to fix other issues: Tests using one's own coordinates are prone to breaking due to newer mailing traces attaching themselves to the oldest marketing trace. This commit makes it so that marketing campaign tests for the same marketing campaign and coordinates cannot run concurrently, by cancelling older test campaigns upon starting a new one. Different tests can still run concurrently on distinct partners/leads/ etc. Additionally: - Running tests are now visible on campaigns in the "New" state; - Activities don't mark themselves as needing sync unless their campaign is in the "Running" state. task-4557855 Forward-Port-Of: odoo/enterprise#89473 Forward-Port-Of: odoo/enterprise#78793
Odoo Studio now uses the platform’s official field settings to decide when fields can be grouped, sorted, or aggregated in views. This reduces incorrect options in Studio and makes list, kanban, graph, pivot, search, and gantt configuration more consistent for users.
Original PR description
Before this commit we used some heuristics in studio to determine whther some field had some ability (groupable, sortable, aggregator) After this commit, we use the not so new tools given by https://github.com/odoo/odoo/commit/b177b058be1531c3d2af2b591c22591c19240d33 Note that we still rely on the field type, because even if possible, groupong by some fields doesn't make much sense (eg.: float) task-4879382 Forward-Port-Of: odoo/enterprise#89446 Forward-Port-Of: odoo/enterprise#88522
The barcode backorder dialog now avoids overlapping column headers on very small screens, especially in languages with longer labels such as French. This makes partial receipt processing easier to read and use on mobile or low-resolution devices.
Original PR description
Issue ----- When processing partial receipts on small resolution screens, the incomplete transfer window has an overlap of its headers for translations with long terms. Steps to reproduce ----- - Set…
Issue ----- When processing partial receipts on small resolution screens, the incomplete transfer window has an overlap of its headers for translations with long terms. Steps to reproduce ----- - Set DB language to French - On Inventory>Configuration>Operation Types, configure the operation type "receipts" to create backorders on "Ask" - Create an incoming transfer - Open barcode on a low resolution screen (eg 340x400px) - Open the transfer in barcode - Process part of the quantity - Validate the partial transfer --> The "Terminé /" & "A faire" column headers overlap Cause ----- The resolution is not wide enough to fit the headers without word break. However breaking words isn't a suitable solution either as it makes headers unreadable. For example, "Terminé /" & "A faire" would read as "Term A " " iné fair" " / e " Given that the 2 columns are semantically related, we can merge their headers together without losing readability. Visual comparison ----- Low resolution before (left) & after the fix (right).  Desktop display is a bit affected but still readable.  ----- Ticket: opw-4715939 Forward-Port-Of: odoo/enterprise#89391 Forward-Port-Of: odoo/enterprise#87177
Partner Ledger XLSX exports now correctly include entries without an assigned partner when users search for “Unknown Partner.” This ensures downloaded reports match what users see on screen and prevents missing ledger lines in exported files.
Original PR description
### Issue: When searching for "Unknown Partner" in the Partner Ledger to get the lines with no partner, nothing shows on the downloaded XLSX. ### Steps to reproduce: - Have a partner Ledger with -…
### Issue:
When searching for "Unknown Partner" in the Partner Ledger to get the lines with no partner, nothing shows on the downloaded XLSX.
### Steps to reproduce:
- Have a partner Ledger with
- Search for "unknown Partner" in the search bar, only the lines grouped under "Unknown Partner" are shown.
- Click on the button "XLSX"
- The downloaded document does not include "Unknown Partner"
### Cause:
When `filter_search_bar` has a value, the domain used to query the partners/lines will check if the names of the partner match the search text. The resulting SQL query excludes the lines where `partner_id` is `NULL`.
### Solution:
Add a new condition in the domain: `('partner_id', '=', False)` This way the lines with no partner are returned by the query
When searching another existing partner these lines are excluded by an [already existing filter](https://github.com/odoo/enterprise/blob/8eff9194618a1d181c57820829e53aa23c7759d5/account_reports/models/account_partner_ledger.py#L55-L58). It excludes the lines if the search test does not match "Unknown Partner".
opw-4772529
Forward-Port-Of: odoo/enterprise#88139This change makes automated checks for the Brazilian POS electronic invoicing flow wait for product searches in a more reliable way. It reduces false test failures in build environments, helping teams keep releases moving without changing customer-facing behavior.
Original PR description
The tours regularly fail in single app builds because the "No other products found" notification is not found. Waiting on that notification is necessary because the product search happens asynchronously. I was not able to reproduce the test failure locally. But in an attempt to improve the situation this changes the approach to use the little "loading" spinner to wait on the search to finish by using Chrome.isSynced(). This method is used elsewhere in POS tests and should hopefully be less flaky. builx_error-224202 Forward-Port-Of: odoo/enterprise#88300
Deliveries using Sendcloud batch shipping could fail when parcel weights averaged to a decimal value. The fix ensures weights are accepted by Sendcloud, allowing affected shipments to be validated successfully.
Original PR description
### Steps to reproduce: - Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method. - Create a…
### Steps to reproduce:
- Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method.
- Create a storable product with a weight of 1 kg and a positive volume.
- Create and confirm sale order for 4 units
- Add shipping -> chose sendcloud
- Separate the delivery of 4 kg in 3 packs:
- set quantity to 1 -> put in pack
- set quantity to 2 -> put in pack
- set the quantity to 4 -> put in pack
- Try to validate the delivery
#### > invalid operation: weight: "A valid integer is required."
### Cause of the issue:
Sendcloud's api only accept integer values for the weight:
However, to evaluate the price of the parcel accurately for a batch shipping we need to compute the average weigth to provide to sendcloud. Converted to grams we tehrefore provide a value of 1333.333333 to sendcloud which raises an invalid operation:
https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L378-L379 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L205-L207 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L44
opw-4874063
Forward-Port-Of: odoo/enterprise#89495UPS shipments sent to customers in Mexico now include the required merchandise description at package level. This prevents shipment validation from failing due to missing package information, helping businesses process these deliveries successfully.
Original PR description
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a…
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a Merchandise Description.` **Expected behavior:** Can process shipment. **Steps to reproduce:** 1. Create a UPS rest delivery option 2. Create an SO for some product to a Mexico-based client, add the UPS delivery, confirm, try to validate the delivery -> 400 **Cause of the issue:** For non-return shipments, the description in the Package object is `None`, but when the receiver is based in Mexico, this field is required. **Fix:** Create a package level description based on the one added here: https://github.com/odoo/enterprise/commit/a7b8673364e0ac626bcc8ded72501c4f2866564c To the UPS API spec here: https://developer.ups.com/tag/Shipping?loc=en_PE&tag=Rating#operation/Shipment!path=ShipmentRequest/Shipment/Package/Description&t=request opw-4508139 Forward-Port-Of: odoo/enterprise#86411
This change removes an unnecessary journal field from UK Bacs direct debit mandates because journal handling is already managed on the related payments. This reduces duplicate setup information and helps avoid confusion when managing direct debit mandates.
Original PR description
There's no reason that we have this Journal field on the mandate as all related journal logic in the payments themself. task-4630586
Installing Field Service Sales no longer fails if the default Services product category was previously deleted. This prevents an installation blocker and lets businesses enable the module without restoring that category manually.
Original PR description
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `industry_fsm_sale` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError
while parsing /home/odoo/src/enterprise/saas-18.3/industry_fsm_sale/data/industry_fsm_data.xml:5, somewhere inside <record id="field_service_product" model="product.product">
<field name="name">Field Service</field>
<field name="project_id" search="[('id', '=?', ref('industry_fsm.fsm_project', raise_if_not_found=False)), ('is_fsm', '=', True)]"/>
<field name="service_tracking">task_global_project</field>
<field name="type">service</field>
<field name="categ_id" ref="product.product_category_services"/>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6377659355
Forward-Port-Of: odoo/enterprise#89510The Studio "New Model" dialog now closes as soon as users confirm their action, instead of lingering briefly while the system responds. This removes a small visual flicker and makes the model creation flow feel smoother and more responsive.
Original PR description
This commit fixes a minor UX issue where the "New Model" dialog in Studio would remain visible briefly after confirmation, causing a flicker while waiting for the server response. The dialog now closes immediately upon confirmation, providing a smoother user experience. task-4809049 Forward-Port-Of: odoo/enterprise#88964
29 changes
Resolved issues and error corrections
Updates to analytic items now automatically keep the related journal item’s analytic distribution in sync. This prevents invoices and accounting entries from showing outdated analytic allocation information after edits or deletions.
Original PR description
overrode the write and unlink functions related to the analytic_line so that it synchronize the analytic distribution in the move_line every time a change happen before this commit whenever an analytic line is edited it is not reflected to its linked journal line's analytic distribution. so an update function is created so that the analytic distribution is updated whenever an analytic line is edited or deleted. task-4378407 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
Changing a company's country VAT label now reliably updates the label shown on contact forms. This prevents users from seeing outdated field names after their configuration changes, reducing confusion and ensuring the interface matches the saved settings.
Original PR description
**PROBLEM** When changing the vat label associated to the country of the user's company, it should change the label of the `vat` field. The cached partners views are not invalidated as they should…
**PROBLEM** When changing the vat label associated to the country of the user's company, it should change the label of the `vat` field. The cached partners views are not invalidated as they should and the old views with the old label are presented to the user instead of the new ones. This can be confusing to the user, because while their change had an effect on the database, it doesn't reflect on the views showed to them. **STEP TO REPRODUCE** 1. On a fresh database, install the contact app. 2. From the contact app, Configuration->Countries, select United States which should be the country of the demo company. 3. Change the Vat Label field value. 4. Go on any contact form view, and notice the label of the `vat` field wasn't updated. 5. You can refresh the pages, and sometimes the new value will be there, sometimes not. **CAUSE** https://github.com/odoo/odoo/blob/ac106704f3c2d3e3fa94415134b9d5522b325378/odoo/addons/base/models/res_partner.py#L41C1-L55C1 In the mixin `FormatVATLabelMixin` we modify the form view, changing the label of the vat field accordingly. However, the `_get_view_cache_key` override that would add the field used to make the change (`self.env.company.country_id.vat_label`) to the cache key is missing. Which means the cache isn't invalidated when it should. **FIX** Invalidating cache when writing on `vat_label` opw-4825749
This fix adjusts automated login flow checks so the two-step authentication step is only monitored when it is actually active. It helps prevent false test failures around sign-in and improves confidence in the authentication process.
Original PR description
In this commit, we change the login page step by a step with isActive property. So this step is only active when the input#login is not on the page and then expectUnloadPage will be only listen when this step is active. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the background-position editing overlay fills the full area of affected website snippets. It helps editors accurately adjust background images and keeps related tooltips positioned correctly.
Original PR description
Before this commit in some snippets background overlay wouldn't have
proper height and/or width because of the snippets `h-{}, w-{}` classes.
This commit overrides it with `!important`.
To reproduce the issue:
- open website and start editing
- drop columns snippet, add background image to one of the cards, click
on it
- Click on the background position option to change it(the one with
a crosshair icon)
- the overlay isn't shown properly, which also breaks the tooltip
position
This should be forward-ported up to 18.3 inclusive, and from 18.4 on, `background_position_overlay.js L135` should be changed because of the [html_builder refactoring].
task-4930050
[html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbThis fix corrects mismatched formulas in the POS HR spreadsheet dashboard. Business users should see more reliable dashboard figures when reviewing point-of-sale and employee-related reporting.
Original PR description
Task: 4930419 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
Long spreadsheet dashboard names in the search panel now show in full when users hover over them. This makes it easier to identify dashboards without changing the panel layout or requiring extra clicks.
Original PR description
Before this pr: - Long dashboard names were truncated in the search panel. - There was no way for the user to see the full name. After this pr: - A tooltip has been added to display the full dashboard name on hover. Task: [4903713](https://www.odoo.com/odoo/2328/tasks/4903713) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216578
This change prevents key activity types such as calls, meetings, todos, leave reminders, fleet contracts, and finance-related activities from being deleted or tied to the wrong business area. It reduces crashes and broken automated workflows when shared activity settings are missing or changed unexpectedly.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/odoo#156731Creating a new replenishment rule in Inventory no longer triggers an error when no product has been selected yet. This prevents an interruption in the replenishment setup flow and lets users continue entering the required details normally.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/213154/commits/ea480703b64d88ac572c3e37da3d9fb3327b4445 Steps to reproduce the bug: - Go to "Inventory" → "Operations" menu → "Replenishment" - Click "New" to create a new replenishment rule Problem: Traceback is triggered: ``` in _float_check_precision assert precision_rounding > 0,\ ^^^^^^^^^^^^^^^^^^^^^^ AssertionError: precision_rounding must be positive, got 0.0 ``` As the product is not set, the `product_uom` is not set either, which leads to a `product_uom.rounding` of 0.0. Opw-4925719 Opw-4928957 Opw-4926504 Opw-4925919 Opw-4928684 Opw-4925080 Opw-4928788 Opw-4926719 Opw-4927440 opw-4928540
Stock report PDFs now show table headers in bold as expected, matching the formatting users see in the report template. This improves readability and keeps printed inventory documents visually consistent.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380 enterprise PR: https://github.com/odoo/enterprise/pull/87852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Rotating large images in the HTML editor now keeps the rotation controls active even when the editing area becomes scrollable. This prevents interruptions during image adjustments and makes content editing smoother for users.
Original PR description
Problem: When a user rotates an image, certain image sizes can cause the editable area to become scrollable. This triggers `resetHandlers` from `usePositionHook`, resulting in loss of focus on the rotate controller. Solution: Add a flag to detect when the user is actively transforming (`mousedown`). Delay the reset until interaction ends (`mouseup`), preventing premature handler reset. Steps to reproduce: - Add a long image - Transform > Rotate until a scrollbar appears - You lose focus on the rotate controller opw-4890029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing payment details such as the amount no longer clears the existing journal entry name. This prevents unnecessary new numbering when payments are reposted, reducing confusion and avoiding unexpected gaps in accounting sequences.
Original PR description
Since PR #204507, the move name is reset whenever a payment with a `move_id` is modified, which was intended to allow changing the journal. However, this also resets the journal entry name unnecessarily when unrelated fields (e.g. amount) are updated. This causes confusion for users, especially when the payment is re-posted and a new sequence is generated, leading to gaps in the journal entry numbering without any apparent reason. This fix ensures the journal entry name is only reset when the `journal_id` field is updated. Steps to reproduce: 1. Create a payment and post it 2. Reset it to draft 3. Change the amount 4. Check the journal entry name → it is reset to '/' 4. Repost the payment, and a new sequence is generated Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4886466) opw-4886466
Sales order lines linked to a newly created project now automatically include the project's analytic account when no project account is already present. This restores expected cost tracking on invoices so project-related revenue and costs are reported against the correct project as well as any existing distribution model.
Original PR description
Steps to reproduce: ------------------- 1. Create a product of type service which creates on order project & task 2. Create a distribution model for that product with an analytic account "Operating…
Steps to reproduce:
-------------------
1. Create a product of type service which creates on order project & task
2. Create a distribution model for that product with an analytic account "Operating costs" set on the plan "Internal"
3. Create a new sales order and add the product to a SOL (the line will have the "Operating costs" analytic account thanks to the distribution model)
4. Confirm the SO (it automatically creates a project and the analytic account of the project)
5. Now create an invoice from that SO and look at the analytic distribution on the line:
- In v17.4, we had both analytic accounts (the one from the line & the one from the project)
- In v18, we only have one analytic account (only "Operating costs" but not the one from the project)
Fix:
-------------------
When adding a new SOL or adding a project to the SO:
=> We will now add to the SOL distribution a new line set at 100% containing the analytic account from the main plan (e.g. "Project") of the SO project if:
- No account is already set in the main plan (e.g. "Project") in any line of the SOL distribution
task-4630617
version-18.0Pasted multi-line content from apps like Discord is now cleaned more reliably in the Odoo editor. Invisible empty blocks are removed and valid content blocks are kept, preventing broken placeholder behavior and unwanted spacing.
Original PR description
Steps to Reproduce : - Open the Discord app - Copy the text written in multiple lines - Paste it in the Odoo Editor - Click below any line or empty space - You will notice that the placeholder "Type…
Steps to Reproduce : - Open the Discord app - Copy the text written in multiple lines - Paste it in the Odoo Editor - Click below any line or empty space - You will notice that the placeholder "Type '/' for commands" is getting destroyed. Description of the issue this PR addresses: - The issue was caused by visually empty `<div>` elements included in pasted content and not converted into baseContainer. - This regression was introduced in commit [#196481](https://github.com/odoo/odoo/pull/196481/files?diff=split&w=0#diff-1b8ed5b7d66a870806b1e7400a0d6cb9ba8810327824244eca868be9583b7fd9L467-L477), which stopped replacing blacklisted tags like `<div>` with `<p>`. - As a result, cleanForPaste no longer strips inline styles from `<div>` elements. Current behavior before PR: - Pasted content includes non-visible `<div>` elements. - These empty blocks occupy space without contributing visual content. - Inline styles from copied content remain intact. - `<div>` elements are not replaced with valid block tags. - Placeholder rendering is broken in these ghost spaces. Desired behavior after PR is merged: - Non-empty `<div>` elements are replaced with a baseContainer element. - Empty `<div>` elements are automatically removed from pasted content. - This restores the expected cleaning behavior, removes unwanted styles, and preserves line breaks. task-4805536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from seeing an access error when creating a bank account number that already exists in another company they cannot access. The duplicate check now respects company boundaries, so multi-company accounting users can continue their work without being blocked by records from other companies.
Original PR description
Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only…
Step to reproduce 1. Createdb with account and contact module install in 18.0 version. 2. create 2 company A and B 3. create partner with both company A and B seperate 4. create a user that have only rights of company B and rights of Accounting/setting groups 5. create a Bank account(Contact->Configuration->Bank Account) with partner A in company A 6. Now login with user B and create a bank account number with same account number. Access error will come. For resolve the access error fetching the correct result according to company so it won't fetch other company result the changes merged last week https://github.com/odoo/odoo/commit/ad6c9001b447f5ffebafe1581512f48708c7d746#diff-22e97cf61c6826e67cd9a3276bdb292e997cb1117ca44c1749c69d5d01931787R69 ``` Access Error Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Test B (id=7) doesn't have 'read' access to: - Contact, A (res.partner: 8) Blame the following rules: - res.partner company If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. This seems to be a multi-company issue, but you do not have access to the proper company to access the record anyhow. ``` upg-2986193 opw-4876839 tbg-2093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents electronic invoice generation from failing when an invoice line contains a tax detail without a grouping key. The system now skips those incomplete tax details when building export tax categories, improving reliability for UBL/CII invoice exports.
Original PR description
Before this commit: If a tax detail of an invoice line has the None tax grouping key, there is a traceback when generating the UBL InvoiceLine/ClassifiedTaxCategory After this commit: We exclude tax details that have the None grouping key when generating the InvoiceLine/ClassifiedTaxCategory. task-none
This fixes an issue where adding a company-paid expense to an empty expense report did not set the correct payment journal. As a result, users can continue processing the report without encountering a payment method error.
Original PR description
Current behavior before PR: 1. Create an expense paid by company 2. Create an empty expense report (not through the expense form view) 3. Add the expense to the report (Updates the payment_method and payment_method_line_id but not the journal_id) 4. Try to move forward to create the move 5. Error (The selected payment method is not available for this payment, please select the payment method again.) Desired behavior after PR is merged: The right journal_id is set when adding an expense to an empty expense report. task-4804970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211190
Sale orders created from CRM no longer carry over the CRM lead's assigned salesperson when confirming related records. This prevents quality checks and other linked records from being assigned to the wrong user, improving operational accuracy.
Original PR description
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 Forward-Port-Of: odoo/odoo#215499
To reproduce: ============= - Go to email templates Problem: ======== - Missing translation value in the hebrew Language Solution: ========== - Add the missing values opw-4714799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
To reproduce: ============= - Go to email templates Problem: ======== - Missing translation value in the hebrew Language Solution: ========== - Add the missing values opw-4714799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The UAE Corporate Tax Report now prevents taxable and tax amounts from appearing as negative when profits are below the exemption threshold. This avoids confusing report results and ensures businesses see zero tax due instead of an incorrect pay-back amount.
Original PR description
The Corporate Tax Report was incorrectly showing a negative"Corporate TAX Amount" when the taxable profit fell below the exemption threshold (e.g 375,000 AED). This issue happened because the formula used to compute the Corporate TAX Amount was: `AE_CORP_TAXABLE.balance * (AE_CORP_TAX_PERC.balance / 100)` This formula applies the tax rate even when `AE_CORP_TAXABLE.balance` is negative, which results in an incorrect negative tax amount in the report. Since the report engine doesn't support conditional logic like `max(...)` or `> 0` in XML formulas, we couldn't fix this in the formula definition directly. To solve the issue, we added a check in the Python report handler `_custom_line_postprocessor` to override the value of the Corporate TAX Amount and cap it at zero when it would otherwise be negative. Steps to reproduce: In run bot or any db go to Corporate tax report OPW-4739052
Mexican electronic payment documents now calculate VAT bases consistently when invoices are paid in a foreign currency. This prevents valid USD payments from being rejected due to small exchange-rate rounding differences, helping businesses send compliant payment CFDIs successfully.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
- line 1: price_unit 93.76, quantity 172, tax 16%
- line 2: price_unit 74.18, quantity 161, tax 16%
- line 3: price_unit 74.18, quantity 162, tax 16%
- line 4: price_unit 93.76, quantity 384, tax 16%
- line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI
Issue: Payment validation will fail with error
> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".
opw-4750981
Forward-Port-Of: odoo/enterprise#88952This change prevents important activity types such as calls, meetings, approvals, tax tasks, payroll leave tasks, and bank synchronization from being accidentally deleted or reassigned. This helps avoid workflow failures across several apps that rely on these predefined activities, while also improving stability when activity data is missing or changed.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#58164PDF reports now show table headers in bold as intended, matching the formatting users see in the report template. This makes printed inventory reports clearer and more consistent for users who rely on PDF outputs.
Original PR description
Problem: When printing the stock report, table headers are not bold in the generated PDF despite being styled that way in the HTML template. Cause: The bold styling is applied via CSS on the `thead` element, which doesn't render properly in the PDF output. Solution: Use `<strong>` tags inside table headers to apply bold formatting, as done in version 17.0. Also remove `font-weight` rules from CSS for `thead` to avoid conflicts and ensure consistent output. Steps to reproduce: 1. Go to Inventory > Inventory Overview. 2. Select any inventory record. 3. Print the report. → Table headers are not bold as expected, despite formatting. opw-4840380
Fixed an issue in the Barcode app where scanning a destination package after picking products could incorrectly overwrite earlier products' source locations. This helps keep delivery records accurate when warehouse staff pick items from multiple locations into the same package.
Original PR description
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to…
Issue ===== When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed. How to reproduce ================ - Enable multi-locations and package; - Create an empty package, two locations and two products; - Create a delivery in the Barcode app; - Scan the first location then the first product; - Scan the second location then the second product; - Scan the empty package -> The package is rightly assigned as the result package for both lines, but the source location of the first product was update for the last scanned source location. Cause of the issue ================== When a source location was previously scanned, when a line is updated (`updateLine`), we update the line's source location. Usually, that's the wanted behavior but in this case, we don't want to the source location of already processed lines when we scan a destination package. Solution ======== When calling `updateLine` from `_assignEmptyPackage`, give a key in the parameters to not update the source location. [opw-4859851](https://www.odoo.com/odoo/project.task/4859851) Forward-Port-Of: odoo/enterprise#89142
The German Intrastat XML report now includes all required fields and formatting needed by the German Federal Statistical Office. This prevents report rejections caused by missing XML details, region codes, test indicators, or interchange agreement information.
Original PR description
In the German Intrastat-Report some elements are missing when downloding the xml report First, the XML version and character encoding must be included in the XML prolog Second, the element testIndicator is missing when its false Third, the element interchangeAgreementId under Party Fourth, the element regionCode under Declaration > Item `interchangeAgreementId` field is entirely form Odoo, and absence of one of these elemetns prevents the report from being accepted by German Federal Statistical Office via INSTAT/XML. To solve this we need to add a new field for interchangeAgreementId in the res_company opw-4752415
This fix prevents Uruguay electronic invoicing from failing when a user clears a journal item description. It ensures invoices can still generate the required tax authority XML without an unexpected error.
Original PR description
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description automatically populates with the product name upon line creation. However, users can intentionally clear this field. If the description field becomes empty, its value is interpreted as `False`. This leads to an `AttributeError: 'bool' object has no attribute 'replace'` traceback when the `_l10n_uy_edi_get_line_nom_and_desc` method attempts to process this boolean value, as it expects a string. This issue specifically affects the generation of the "DscItem" tag in the XML file sent to DGI. ### Solution: To prevent this error, an additional validation has been implemented for the line description. This validation ensures that if the field's value is `False`, it is not processed by the `_l10n_uy_edi_get_line_nom_and_desc` method, thus avoiding the traceback.
This update adds validation for a specific return scenario involving intercompany dropship orders. It helps ensure these returns continue to work correctly and reduces the risk of regressions in multi-company sales and purchasing flows.
Original PR description
Adds test coverage for return of an intercompany dropship use-case (see corresponding community PR). opw-4526750
Employee document counts now include files stored in any folder under the Human Resources document area, not just files in the top-level HR folder. This prevents uploaded employee documents from appearing missing and ensures the employee record shows the correct document count.
Original PR description
Issue: currently, only the direct descendant of `hr_folder` are considered for counting employee documents. step to reproduce: - install documents_hr - from settings -> documents -> enable "Human Resources" (default folder is HR) - open a record from employees app - click on "documents" smart button - create a new folder inside HR folder and go inside it - upload a document **observation 1** : - uploaded document vanishes - return to employee record **observation 2** : - document count is still 0 Fix: change the responsible domain to consider all the documents inside hr_folder opw-4913495
Budget reports now avoid creating an extra duplicate line when a purchase order includes a negative discount line. This keeps budget figures accurate and prevents overstating discounted amounts in purchase-related budget views.
Original PR description
Steps to reproduce: - Create a new Budget with budget line having Project [TEST] - Create a purchase order with 2 lines: 1. Product A, analytic [TEST], price unit 100, qty 1 2. Product B, analytic [TEST], price unit -10, qty 1 - Confirm the PO, mark products as received - Create the bill and confirm - Go back in PO, click on Budget smart button, open list view Issue: The budget report will correctly show a line for each invoiced line, but an extra line with double discount amount is present Occurs because we use a SQL code to replicate the qty_invoiced field of a purchase order line, but we adjust the sign based on the aml balance instead of taking into account the move type opw-4775631
Customers with overdue invoices can now have follow-up letters printed without triggering an error. This helps accounting teams continue collection workflows smoothly even when report settings are incomplete.
Original PR description
**Issue** Printing a follow-up letter for an invoice with a past due date sometimes causes a traceback error. **Steps to Reproduce** 1. Install the Accounting module 2. Enable developer mode 3. Go to…
**Issue** Printing a follow-up letter for an invoice with a past due date sometimes causes a traceback error. **Steps to Reproduce** 1. Install the Accounting module 2. Enable developer mode 3. Go to Settings > Technical > Actions > Reports 4. Enable the Follow-Up letter print action 5. Navigate to Accounting > Customers > Invoices 6. Create an invoice with a past due date 7. Open the related customer’s contact form 8. Use the gear icon to print the follow-up letter 9. Observe the traceback error **Root Cause** The `_get_invoices_to_print` method expects the `options` dictionary to contain the key `'followup_line'`, but when `options` is empty or missing this key, the method tries to access `options['followup_line']` without verifying its presence. This results in a `KeyError` or attribute access on `None` **Fix** Added proper safety checks to verify the presence of `followup_line` in `options` before accessing its attributes. Also ensured `join_invoices` defaults safely to `False` if missing. This prevents the traceback and allows the method to handle empty or incomplete `options` gracefully Opw-4804896