Daily updates from Odoo
Navigate
Branch
Thursday, July 24, 2025
57 changes
22 changes
Enhancements to existing features
This update adjusts Odoo Studio tests and behavior to stay aligned with a related messaging system change. It helps ensure Studio form editing continues to work reliably after the underlying recipient field lookup was removed.
Original PR description
PR community: https://github.com/odoo/odoo/pull/208393 Task-4685400 Forward-Port-Of: odoo/enterprise#90375 Forward-Port-Of: odoo/enterprise#84661
Automatic bank reconciliation messages now show OdooBot as the author instead of the current user. This makes it clearer in the chatter when an accounting action was performed by the system rather than manually by a person.
Original PR description
- Before this pr: When bank statement lines were automatically reconciled, the system posted related messages in the chatter with the current user set as the author. - After this pr: Messages posted in the chatter as a result of automatic reconciliation now correctly use OdooBot as the author, reflecting that the operation was system-driven rather than manual. Task: 4852073
This update replaces the old internal Persona model with standard partner and guest records across messaging-related features. It helps align AI, VoIP, WhatsApp, and live chat behavior with the main Odoo contact model, reducing duplication and improving consistency for future maintenance.
Original PR description
This PR removes the model Persona and replaces it with res.partner and mail.guest models. Task-4675821 PR community: https://github.com/odoo/odoo/pull/212683
Opening a certified Belgian PoS no longer stops users with an error when required company details are missing. Instead, the company settings open directly in a modal so users can add the address and VAT number without leaving the PoS flow.
Original PR description
Instead of displaying an error when opening a certified PoS on a company missing its addresss and VAT number, we now display the company settings in a modal to allow updating without going back to the settings.
This update adjusts mail-related integrations for AI, VoIP, and WhatsApp after an internal contact/persona model was removed. It helps keep messaging, calling, and chat assistant features working consistently without changing the user-facing workflow.
Original PR description
Adapte code to the removing of persona model. task-4675821
This update removes reliance on an older anonymous visitor name field in helpdesk livechat flows. Because livechat now usually has a guest or user name available, this simplifies the system and prepares for future cleanup without changing the customer-facing chat experience.
Original PR description
Now that we have guests in livechat, we almost always have a guest or user name. Over time, those values have replaced the usage of the anonymous_name field. This change removes the use of this field from method params and demo files. If we address the channel naming in a few corner cases (e.g., using the name field for a deleted visitor or partner) in the next step, then we can remove the anonymous_name field from the discuss channel model. part of task-4675719 Related to : odoo/odoo#210785
The Point of Sale integration has been adjusted to stay compatible with recent product-related changes in Odoo. This helps ensure product attribute information continues to work correctly for businesses using the UrbanPiper POS enhancements.
Original PR description
task-4731792
Point of Sale and self-ordering flows using IoT devices no longer need an extra database check when listening for device updates. This helps shops continue operating more reliably when connectivity is limited or offline.
Original PR description
As it prevents the pos from working offline, we removed the call to the db to get a payload signature. Community PR: odoo/odoo#219865 Forward-Port-Of: odoo/enterprise#90688 Forward-Port-Of: odoo/enterprise#90624
The Knowledge app tour was updated to match recent user experience changes in the history dialog. This helps keep guided testing and demonstrations aligned with the latest interface, reducing confusion and maintenance issues.
Original PR description
* Adapt knowledge tour after UX changes task-3560677
The Belgian POS fiscal compliance screens now use clearer wording for the required INSZ field, describing it as the social security identification number. This helps employees and administrators understand what information is needed and reduces confusion during setup or validation.
Original PR description
INSZ number check wasn't explicit enough for users, so we improved helper messages to "Social security identification number" to ease the understanding of the requirement. Forward-Port-Of: odoo/enterprise#90754
The bank synchronization dashboard now uses a more efficient service to retrieve connected financial institutions. This should make the dashboard more responsive and improve the reliability of bank connection information without changing user workflows.
Original PR description
https://github.com/odoo/odoofin/pull/419 introduces a new more efficient endpoint to get dashboard institutions. This commit updates the `account_online_synchronization` module to use this new endpoint. Task ID: 4801302
Resolved issues and error corrections
A small internal fix makes the web editor available consistently across automated tours. This helps reduce test issues and supports more reliable validation of Studio-related behavior without changing day-to-day user workflows.
Original PR description
This commit moves the patch of editor into html_editor to expose the editor instance globally for all the tours. Community PR: https://github.com/odoo/odoo/pull/212032 Forward-Port-Of: odoo/enterprise#90764
The AI assistant no longer sends the latest user question twice when building conversation context. This helps produce cleaner, more accurate AI responses and avoids unnecessary processing.
Original PR description
Prior to this commit, we send messages to the llm like the following:
```
[
{'content': Markup('<p>first question</p>'), 'role': 'user'},
{'content': Markup("<p>Sure, I'm here to help. What's your first question?</p>"), 'role': 'assistant'},
{'content': Markup('<p>second question</p>'), 'role': 'user'},
{'role': 'system', 'content': "You are a RAG assistant.\n\nToday's date to be used: 2025-07-18"},
{'role': 'user', 'content': 'second question'}
]
```
We're actually duplicating the user's prompt and this is because of the retrieval of the chat history. Before calling generate_response, we post the user's message. Therefore, he's message is already recorded in the db. We should then skip the most recent message to assemble the chat history since its just the same to the prompt.
Forward-Port-Of: odoo/enterprise#90665
Forward-Port-Of: odoo/enterprise#90502The Czech VAT Control Statement export now uses the official date field name for B2 vendor bill entries. This prevents the Czech tax portal from leaving that date blank when businesses upload the XML file.
Original PR description
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and…
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill. 3. Go to Reporting → Tax Return → VAT Control Statement (CZ). 4. You will see the bill listed under section B2. Now export the XML. 5. In the exported XML, the field `dan_dppd` is present. **Observations**: When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`. According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized. **Issue**: The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section. **Solution**: The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation. opw-4868515 Forward-Port-Of: odoo/enterprise#90394
The automated Field Service stock test was adjusted to match the updated task list behavior. This keeps quality checks aligned with the product and helps prevent false test failures after related platform changes.
Original PR description
This commit adapts the `industry_fsm_stock_test_tour` tour according to the changes made in community. That is, now the main list view of tasks will now be readonly as before instead of editable with a open form view button. Forward-Port-Of: odoo/enterprise#89585
Fixes a crash that could happen when moving dependent project tasks in the Gantt view if related tasks were missing start or deadline dates. This helps project teams reschedule work more reliably without being blocked by an unexpected error.
Original PR description
Currently, an error occurs when rescheduling a task's date from the Gantt view. **Steps to Reproduce:** - Install the `project_enterprise` module. - Go to `Settings` and enable `Task Dependencies`. -…
Currently, an error occurs when rescheduling a task's date from the Gantt view. **Steps to Reproduce:** - Install the `project_enterprise` module. - Go to `Settings` and enable `Task Dependencies`. - Go to `Projects`, create a `project`, and add `two tasks` (Task 1 and Task 2) under that project. - Open `Task 2` > `Blocked By`, click `Add a line`, and select `Task 1`. - Return to the `project's tasks`, switch to `Gantt View`, and choose `Auto-Reschedule (Keep Buffer)` as the rescheduling method. - `Double-click` on any date in the unassigned block, select `Task 1`, and `drag it to next date`. `TypeError: '>' not supported between instances of 'bool' and 'datetime.datetime'` This error occurs when rescheduling a task to a forward date, and a dependent task has no start date. When the parent task is rescheduled, the system attempts to reschedule the dependent task as well, but since it has no start date, an error occurs [1] due to condition at [3]. The same error occurs when rescheduling a task to a backward date, and a depends on task has no deadline date. When the child task is rescheduled, the system attempts to reschedule the parent task as well, but since it has no deadline date, an error occurs [2] due to condition at [3]. **Steps to Reproduce for backward rescheduling:** - Follow the first 5 steps from the forward rescheduling steps. - Remove the Deadline from Task 1, if it has. - Double-click on any date in the unassigned block, select Task 2, and drag it to previous date. This commit ensures that the incorrect condition is removed from [3]. Now, it checks whether the record is a candidate for moving, and both forward and backward rescheduling are handled safely. [1]- https://github.com/odoo/enterprise/blob/aaad26c28fd4bc1e94e99717076ecbcf74f5f357/project_enterprise/models/project_task.py#L1209 [2]- https://github.com/odoo/enterprise/blob/8cc8443dc11c176b55f7eb3efa07db5edb7e6b0c/project_enterprise/models/project_task.py#L1221 [3]- https://github.com/odoo/enterprise/blob/302f1a5e82ffbf383d37f003820fe780654fae2f/project_enterprise/models/project_task.py#L1203 sentry-6738017612 Forward-Port-Of: odoo/enterprise#90025
Point of Sale now stops zero-amount customer deposits before they are processed and shows a warning instead. This prevents an unexpected error screen and helps cashiers continue their workflow smoothly.
Original PR description
Steps to reproduce: =================== - From the POS UI, select a customer - Select Deposit Money - Try to deposit `0` amount by clicking Validate button Issue: ====== A traceback is raised when attempting to validate a deposit with zero amount. Cause: ====== The system does not check for zero-amount orders when creating a deposit payment line. Fix: ==== Add a dialog warning when the deposit amount is zero to prevent further processing. Task: 4862811 Forward-Port-Of: odoo/enterprise#90739 Forward-Port-Of: odoo/enterprise#87709
Swedish SIE4 accounting file imports now use UTF-8 decoding so Swedish characters are read correctly. This reduces import errors and avoids garbled text for customers using Swedish accounting data.
Original PR description
The aim of this commit is using UTF8 instead of ISO-8859-1 for the file decoding. We received feedback from customers that the previous decoding wasn't handle correctly swedish characters. The documentation tends to say that we should follow CP437. As UTF8 is a superset of CP437, we are now using it. opw-4868415 Forward-Port-Of: odoo/enterprise#90498
Employees without expense management rights can now submit expenses created from OCR uploads without being blocked by an access rights error. This prevents a submission failure caused by updating OCR status after the expense was no longer editable for that user.
Original PR description
How to reproduce the issue: - Upload a pdf via the OCR with a user without expense right. On submitting the expense, an access rights error on the write is thrown. When the expense is created by OCR, on submit, we pass through the action_submit method in hr_expense_extract, which performs validate_ocr, and writes on the expense's extract_state field after the super().action_submit call, which changes the state of the expense from draft to submitted. However, the rule ir_rule_hr_expense_employee_not_draft forbids modifying the expense if it is not in draft state. opw-4855000 Forward-Port-Of: odoo/enterprise#90616
Batch payments now handle currency exchange differences correctly when linked to bank statement lines. This prevents accounting entries from incorrectly ending up in suspense with a zero foreign-currency amount, improving reconciliation accuracy. The update also adds a safeguard so batch payments only group payments with compatible payment methods.
Original PR description
This commit will add the possibility to have exchange diff on batch payment. That was a problem that cause the move of the bank statement line to have a suspense with an amount currency at zero. task-4921741 Forward-Port-Of: odoo/enterprise#89717
This fixes an access problem that blocked standard internal users from creating or editing Colombian contacts with a NIT tax ID. The system can now check the required DIAN certificate information without showing an “Access Denied” popup, reducing friction for day-to-day contact management.
Original PR description
When entering a Colombian Tax ID (NIT), the onchange checks `company.l10n_co_dian_certificate_ids`, which reads `certificate.certificate` records , resulting in an “Access Denied” popup. This changes Wrap the certificate lookup in `company.sudo()` so that the NIT VAT‐onchange can fetch the DIAN certificate records. Steps to Reproduce: 1. Install the l10n_co_dian module and switch to CO company 2. Create a user with only the “Internal User” (base.group_user) group—do not grant Administration/Settings. 3. Log in as that non-admin user. 4. Go to Contacts -> Create. 5. Set Country = Colombia and Identification Type = NIT. 6. Enter any VAT (NIT) number and leave the field. 7. “Access Denied” error for certificate.certificate. opw-4936604 Forward-Port-Of: odoo/enterprise#90176
Miscellaneous changes
Related to https://github.com/odoo/odoo/pull/220031 Forward-Port-Of: odoo/enterprise#90736
Original PR description
Related to https://github.com/odoo/odoo/pull/220031 Forward-Port-Of: odoo/enterprise#90736
35 changes
New functionality added to Odoo
This pull request adds community accounting and budget management components to Odoo 18, including setup files, permissions, translations, and supporting documentation. It also updates deployment configuration to improve Python compatibility, which can help installations run more reliably.
Original PR description
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
Enhancements to existing features
This update adds tax mapping between Switzerland and EU countries for the EU One Stop Shop module. It helps Swiss businesses selling goods directly to EU consumers configure OSS reporting more easily and reduce manual setup.
Original PR description
Make it easy for any Swiss company that wants to operate B2C sales of goods to customers located in the EU to take advantage of the EU One Stop Shop (OSS) Module, aka l10n_eu_oss_reports. We will ease the discoverability and the configuration Adding the Tax Mapping between Switzerland and the rest of the EU countries task-4943589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220084 Forward-Port-Of: odoo/odoo#219380
This update improves everyday reliability across Odoo by fixing access handling, notification data consistency, and point of sale troubleshooting. It also enhances the web editor with easier content movement and selection, and adds more flexible date filters for business records.
Online orders from UrbanPiper, Zomato, and Swiggy now calculate and display taxes more accurately based on location and fiscal settings. This helps merchants apply the right tax responsibilities, including special GST handling for India, reducing manual corrections and accounting discrepancies.
Original PR description
**: pos_urban_piper_zomato, pos_urban_piper_swiggy After this commit: --- - For orders outside India, price are received from UrbanPiper as tax-inclusive. Odoo now properly computes the unit price and applies taxes based on the fiscal position. - For India, special handling is implemented: - 5% GST is collected and paid by the aggregator, so only this tax is added via fiscal position mapping. - For other tax rates like 12% or 18%, the merchant is responsible, so these must be configured explicitly in the fiscal position. Note: --- - If a user does **not** want to receive a particular tax in the order, they must manually add a line for it in the fiscal position. Task: 4862417
Resolved issues and error corrections
The Calendar app now correctly filters events by the current user's attendance status, such as accepted or declined. This prevents users from seeing empty search results when matching events actually exist, making calendar management more reliable.
Original PR description
The filter on an event's "Attending?" status was not working correctly. When filtering, the search would always return an empty result set because the underlying search implementation was logically flawed. It incorrectly compared calendar.event IDs with calendar.attendee data, which could never match. This commit corrects the `_search_current_attendee` method to properly query the `calendar.attendee` model. It now finds the intersection of attendees that both belong to the current user and match the filter criteria (e.g., state is 'declined'). It then uses these results to return the correct parent calendar events. A unit test has been added to verify the filter now works as expected. opw-4892386
Italian electronic invoices now remove line breaks from product descriptions before sending them to the SDI tax agency portal. This prevents otherwise valid invoices from being rejected due to unsupported formatting in the description field.
Original PR description
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on…
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on send 5. Only enable Send to Tax Agency. 6. Click "Send" again. 7. Go to the Attach files and download the attachment. 8. Check the `<Descrizione>` (description) in the XML file. **Issue:** The `<Descrizione>` field in the `<DettaglioLinee>` tag includes newline characters, which are not accepted by SDI portal. **Causes:** The line description is using '\n'.join(...), which results in actual newline characters in the XML. https://github.com/odoo/odoo/blob/ca7de6b2fbe4626583b67a34d77bbb523d972f79/addons/account/models/account_move_line.py#L513 https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/l10n_it_edi/models/account_move.py#L316-L324 **Solution:** To fix this, replace newline characters in the description with spaces and Strip leading/trailing whitespace. This ensures SDI receives a single-line <Descrizione>value. **Before fix:**  **After fix:**  Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4808826) opw-4808826 co-authored by: Raj Bhuva (bhra@odoo.com)
The website editor toolbar has been adjusted so it does not leave unwanted blank space below the page footer when hidden. This keeps edited pages visually tidy and prevents confusing extra scrolling or empty space for users.
Original PR description
Description of the issue/feature this PR addresses: - Commit [189a7c96](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e#diff-de0d67e89972b45b101a9c4b04f316824314b0d69aba6208528586f1edb4f01cL25-L40) moved scrollbar from `#wrapwrap` element to `<body>`, caused the space below the footer visible for the floating toolbar. Current behavior before PR: - Space below the footer was always visible, even when the toolbar was hidden. Desired behavior after PR is merged: - `top: 0;` is applied on `.oe-toolbar` to ensure it stays out of the layout flow. - This prevents unnecessary layout space and ensures correct toolbar positioning. task-4652202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unreliable automated test for live chat session navigation by removing an unnecessary step that sometimes failed. The change helps keep quality checks stable without changing how users experience live chat.
Original PR description
The `test_session_history_navigation_back_and_forth` test sometimes fail. The test ensures we can navigate between the session list view and discuss using the browser history. To do so, the tour first accesses the list view using the command palette. However, command palette sometimes doesn't open. The command palette part of the tour is useless as the view can directly be accessed by passing the correct url to the `start_tour` function. This commit removes the command palette part of the tour thus fixing the issue. fixes runbot-108129 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 makes an internal website test more reliable by waiting for an image to finish loading before checking its size. This helps prevent occasional false test failures, supporting smoother maintenance and release validation without changing customer-facing behavior.
Original PR description
The goal of this commit is to avoid potential undeterminism that could occur in the `drop_404_ir_attachment_url` test (introduced by [this commit]). Before this commit, an error was thrown if the image was not loaded at the time the test checks the `naturalWidth` and `naturalHeight` property of the image. This could lead to undeterministic error as nothing ensures that the image is loaded at that time. To solve the problem this commit first waits for the image to be loaded before accessing the `naturalWidth` and `naturalHeight` property of the image. Side note: even if the source of the image is of type `data:` it is not directly loaded. [this commit]: https://github.com/odoo/odoo/commit/fbc6a697c1adf67ee8a90c49b0150d6ca170e081 task-4931144 Forward-Port-Of: odoo/odoo#217968
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
Original PR description
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
This fix prevents electronic invoices from including an item identification field when no product barcode exists. It helps avoid invalid or misleading invoice data and adds test coverage for direct invoice export scenarios.
Original PR description
In the refactored UBL (with `account_edi_ubl_cii.use_new_dict_to_xml_helpers`): Currently we may generate the `StandardItemIdentification` node even in case the `barcode` is not set on the product. The issue was introduced as a FW-port issue in commit f46c10f03e59e8aae98079fc57f5295a376f2761 (18.0). The problem is that the `schemeID` attribute is always set. task-None (original fix is task-4941855)
Fixed an issue in Point of Sale loyalty programs where customers with existing points could still claim a reward after the program's maximum usage limit had already been reached in the session. This helps ensure promotions are applied consistently and prevents unintended extra reward redemptions.
Original PR description
When an existing partner with points tries to claim a reward from a loyalty program that has reached its max usage in the current session, he was still able to claim the reward. Steps to reproduce: ------------------- * Create a loyalty program with max usage set to 1 * Create a partner and assign points to him * Open PoS and select any partner and make an order * Claim the reward from the loyalty program * Select the partner that already has points * Make an order and try to claim the reward again > Observation: The reward can be claimed, even though the max usage is already reached. Why the fix: ------------ When updating programs, we were not removing the couponPointChanges for programs that are not applicable anymore. We now make sure to delete them when the program is not applicable anymore. opw-4805704 Forward-Port-Of: odoo/odoo#218425
Companies in Greece and Ireland with valid VAT numbers will now correctly see the Intra-Community Valid checkbox for VIES verification. This fixes a country code mismatch so affected businesses can use VAT validation as expected.
Original PR description
Current behavior before PR: - Intra-Community Valid checkbox (for vies verification) was not showing for Greece and Ireland companies with valid VAT number. This was because Greece ISO is GR and Ireland ISO in IX, but their VAT start with EL and IE Desired behavior after PR is merged: - Checkbox is shown despite differences between ISO and beginning of VAT Link to task : - https://www.odoo.com/odoo/project/967/tasks/4575784 Forward-Port-Of: odoo/odoo#201630
This fixes an issue in the website editor where pressing backspace after selecting content across paragraphs could remove text beyond the intended selection. Users can now delete selected editor content without accidentally losing following content.
Original PR description
Problem: Given content like: ``` <p>keep<br>[delete</p> <p>delete<br>delete<br>]</p> <p>keep</p> ``` Pressing backspace removes the last "keep" as well, which is incorrect. Cause: The merge logic uses `range.endContainer` as `joinWith`, but does not account for `range.endOffset`. When `range.endContainer` is a `<p>` with a non-zero offset, the condition `next.previousSibling && next.previousSibling === joinWith` fails. During merging, `next` may go inside `joinWith`, making the logic invalid. Solution: Prevent merging when `next` is positioned exactly at `range.endOffset`, preserving the correct boundary. Steps to reproduce: - Add the sample HTML to the editor - Select from `[delete` to `delete]` - Press backspace -> The final `<p>keep</p>` is deleted incorrectly opw-4905047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219392
This fix ensures the image cropper closes when a user deletes the image being edited, preventing confusing leftover controls in the editor. It also makes the crop option reliably reopen after using or discarding image transformation tools, improving the image editing experience.
Original PR description
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper…
### Steps to reproduce: **Issue 1:** - Add an image in the editor. - Apply image transformation (e.g., shrink it). - Open the image cropper tools. - Press the Backspace key. - Observe that cropper still visible. **Issue 2:** - Go to To-Do and insert an image. - Click on Image Transform, then on Image Crop — observe that Image Crop opens correctly. - Click the Discard button in the Image Crop UI. - Again select the image, click Image Transform, then Image Crop. - Notice that Image Crop no longer opens. ### Description of the issue/feature this PR addresses: - Pressing Backspace removes the image from the editor. - However, the cropper remains open, and focus returns to editable area, allowing to type with the cropper still visible. - Clicking Image Crop while Image Transform was active could destroy both due to async loadBundle() timing. On subsequent attempts, ImageCrop was added before ImageTransform was removed, causing Owl to destroy both in the same frame. ### Desired behavior after PR is merged: - When the image is removed, the associated cropper is also closed. - Clicking Image Crop button while Image Transform is active now works. task-4859869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes activity deadline searches so activities already marked as done are no longer counted as overdue or due. It keeps activity lists and CRM follow-up views accurate when completed activities are retained for reporting.
Original PR description
The search for "my_activity_date_deadline" is used to find activities due before some set date. When keeping done activities for reporting purposes, we should never consider "done" activities for this search. Issue is introduced in CRM in [1] but it could happen anywhere task-4951716 [1]: https://github.com/odoo/odoo/commit/f9f0529c93614bb9f9deec1a5aaa1daccfe8b58c Forward-Port-Of: odoo/odoo#219426
This fix makes an automated sales project test wait for the expected screen behavior before continuing. It reduces false test failures during installation without changing how business users create or manage sales order lines.
Original PR description
Steps to reproduce the issue: 1- install sale_project without demo data 2- as the test is not deterministic, adding step_delay may help reproducing it The test was failing because the tour was not waiting for the modal to close before trying to click on the created sale order line. so accoding to this line https://github.com/odoo/odoo/blob/18.0/addons/sale_project/models/sale_order_line.py#L63-L63 the New Sale order line have in it a default product which doesnt open a modal build_error-163102
Country names entered during contact imports are now matched even when users type them in all caps or other capitalization styles. This prevents valid country values like "ARMENIA" from being rejected, reducing import errors and manual cleanup.
Original PR description
**Current behavior:** When importing a res.country record, if specifying a `name` then the search performed expects it to exactly match a first-letter-only capitalized pattern. **Expected behavior:** Let arbitrary capitalization be used on the input name string. **Steps to reproduce:** 1. Create a sheet to import to `Contacts` (res.partner) * `name`: anything * `country_id`: "ARMENIA" 2. Load the sheet for import -> test -> can't resolve country name **Cause of the issue:** The `res.country` records' names follow a first-letter-capitalized pattern and we do an exact search on the strings. **Fix:** Take the user input search strings and do additional searches on transformations of them that may match the sought after records. opw-4780334 Forward-Port-Of: odoo/odoo#216870
The shipping weight entered on a stock transfer now remains saved after refreshing or reopening the record. This prevents confusion and helps warehouse teams rely on the displayed shipment weight.
Original PR description
The Shipping Weight field was editable in the transfer, but upon refresh or reopening, it reverted to its previous value. This issue is now resolved by setting the field as store=True. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where a failed company image download could trigger an additional error while being logged. This helps ensure company creation through the mail plugin continues to report the original download problem cleanly instead of producing a confusing traceback.
Original PR description
When logging a failed image download for a new company,
A traceback will appear.
[1]- https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L360
https://github.com/odoo/odoo/blob/2317fec604907280aa89c52cfcaeb9adc30e5d04/addons/mail_plugin/controllers/mail_plugin.py#L342-L344
here, ``new_company_info`` is dictionary, but at [1] the code incorrectly accesses
``name`` as an attribute.
So, it will lead to the below traceback.
Traceback:
```
File "/home/odoo/src/odoo/addons/mail_plugin/controllers/mail_plugin.py", line 359, in _create_company_from_iap
_logger.warning('Download of image for new company %s failed, error %s', new_company_info.name, e)
AttributeError: 'dict' object has no attribute 'name'
```
sentry-6554480256
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206771Saving a blog post after removing all content now shows a proper validation message instead of causing a system error. This prevents confusing backend errors and gives users clearer feedback when empty HTML content cannot be saved.
Original PR description
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a…
Currently an error occurs when we try to save a blog post with no content. Steps to replicate: - Install the `website_blog` module. - Navigate to the website, go to the Blogs section, and create a new blog. - Click to open the newly created blog. - Remove any existing content (e.g., placeholder text like 'Start Typing...'). - Type `/column` and click on the 2-column option. - Click on the columns that appear — you’ll see a delete icon. - Delete all the columns, click Save and check the terminal. Error: `ParserError: Document is empty` The error occurs when all content in the blog is deleted, resulting in empty HTML content. During saving, `html.fromstring(lang_value)` [1] is called with `lang_value` being effectively empty, which leads to a `ParserError`. [1] - https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/web_editor/models/ir_ui_view.py#L126 This commit fixes the problem by catching the `ParserError` and raising a `ValidationError` when the HTML content is empty. sentry-5081806749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216790
Odoo now handles attendance records that cross midnight by splitting them into separate daily work entries. This prevents duplicate or conflicting work entries when an employee has an overnight shift followed by another attendance on the next day.
Original PR description
Steps to reproduce the issue: 0. Set work_entry_source to "attendance" on the running contract of the employee. 1. Create an attendance for yesterday 23:00:00 UTC to today 06:00:00 UTC. 2. Create an…
Steps to reproduce the issue: 0. Set work_entry_source to "attendance" on the running contract of the employee. 1. Create an attendance for yesterday 23:00:00 UTC to today 06:00:00 UTC. 2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC. Current behavior before PR: Odoo will create a conflicting work entry with the one created in step 1, because the logic recreates all work entries in a timeframe between the start date at 00:00:00 and end date at 23:59:59. The first entry started before this timeframe, so the recreated work entry does not align with the existing one, causing a conflict. Desired behavior after PR is merged: The work entries now span a single day at a time. If an attendance starts at night and ends the next morning, two entries will be created: one from the start time to end of day, and another from the start of the next day to the end time. opw-4869604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90588
The Indian GST reporting module now creates the GSTR1 report with the required permissions during automated testing. This prevents permission-related failures and helps keep GST report validation reliable.
Original PR description
steps to reproduce: 1. Install l10n_in_reports module. 2. Run the test `TestReports.test_hsn_schema_change_gstr1_json`. this is required to avoid permission issues when creating the GSTR1 report in the test. build_error-223245 Forward-Port-Of: odoo/enterprise#90221 Forward-Port-Of: odoo/enterprise#89116
This fix prevents an error when users refresh or duplicate a browser tab while working with a sent Sign request. It makes the Sign page load more reliably by handling missing page context safely.
Original PR description
**Steps to reproduce:** 1. Install sign 2. Create a sign request and send it to someone 3. Now, either refresh the page or duplicate the page **Issue:** - Traceback Error ```UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onMounted: "Cannot read properties of undefined (reading '4')" ``` **Cause:** - requestItemStates is not defined here, which is passed by context https://github.com/odoo/enterprise/blob/ceebc915607b471ffb8e3bbde055c6816cc06b43/sign/static/src/backend_components/sign_request/sign_request_control_panel.js#L34 **Solution:** - Add a safe fallback if requestItemStates is not present backport a5a6718c3a2fba226ecd7ed3efdb32d06777b6ae opw-4949153
Mexico payroll and salary offer calculations now handle employees who do not yet have an initial contract start date. This prevents invalid operation errors in the salary configurator and keeps payroll calculations stable by using safe default values.
Original PR description
Before this fix, various computations relying on `employee.first_contract_date` fails if the value was missing, notably: - `_compute_integration_factor` in payslips - Python expressions in MX salary rules (holiday bonus, ISR, etc.) Steps to reproduce: Install the following modules: - Recruitments, Payroll, Salary Configurator - Mexico - Payroll, Mexico - Payroll - Localisation, EDI for Mexico Go to Recruitment -> create or click on application in any offer -> click on generate offer(create a contract templates if needed) -> Click on Salary Configurator, notice the Invalid Operation Error After fix: - Default the integration factor to 1 and years worked to 0 when no start date exists - Safely guard salary rule conditions and computations with proper checks This ensures robust payroll calculation even for employees without an initial contract date. opw-4853613
This fixes occasional failures in automated Studio report tests caused by unreliable scrolling checks. The change makes the tests wait more reliably, helping reduce false alarms in quality checks without changing user-facing features.
Original PR description
Linked tests: - `test_add_field_blank_report` - `test_field_placeholder` These tests contained scroll-related indeterminacies that caused them to fail from time to time. This was due to the fact that we were modifying the scroll and we used this code to make sure it was done: ```js await new Promise(requestAnimationFrame); ``` However, sometimes this wasn't enough, so we now use `waitUntil`, which is more robust https://runbot.odoo.com/odoo/runbot.build.error/181989 runbot-181989
Fixed the website helpdesk contact form so the description label is translated correctly when users submit tickets in another language. The description field is also hidden when it is the only field, avoiding duplicate or confusing information on new tickets.
Original PR description
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ##…
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ## Reproduction Steps 1. Go to the general settings. Add a language where the term "description" differs from the english word (for example, Spanish). Do the same for the website settings. 2. Go to the website app. Scroll down and change the language. Then, click on the translated "contact us" tab. Fill the form and send the ticket. 3. Go to the helpdesk app and open the ticket you just created. ### Expected behavior The description field shouldn't show, as it appears in the description page. The field should only show if there are additional fields on the "contact us" page. ### Unexpected behavior The description field shows, untranslated. ## Origin of the issue In the ticket code, the field.name is used, instead of the field .field_description, which is translatable. Moreover, there isn't a condition checking if the field should appear or not. -- opw-4876726
This update adjusts automated checks for CRM activity handling after the activity action began loading in two steps. It also verifies that both active and inactive records are included where needed, helping keep CRM behavior reliable after related changes.
Original PR description
The crm activity action is now loaded in two steps Also check that the domain gets `active in [true, false]` added while we're here See linked community pull request task-4951716 Forward-Port-Of: odoo/enterprise#90762
Portal users can now see published Knowledge articles marked as visible to everyone from the website help page. This fixes an inconsistency where logged-in portal users were blocked from content that anonymous visitors could already view.
Original PR description
There is a bug, when portal user wants to access a article with visibility set to everyone through help page on the website, the portal user wouldn't be able to see anything by clicking on browse…
There is a bug, when portal user wants to access a article with visibility set to everyone through help page on the website, the portal user wouldn't be able to see anything by clicking on browse button, while if the portal users logs out and access the same page, they would be able to see the articles. The steps to reproduce: 1- Setup a database with helpdesk, website, and knowledge app installed. 2- On website app --> help --> Helpdesk Team, enable the knowledge checkbox. 3- Create an article and publish it on the website and set the visibility to everyone. 4- Login as an portal user. 5- Navigate to help page on the website. Click on Browse articles. 6- You can see the article is not shown here. 7- Logout from the portal user and repeat the step 5. You can now see the article. In the current version, if the user is not logged in, they will access the article with visibility set to everyone, which is expected. This is done by returning [] in the _search_is_article_visible. Elsewise, if the user is an internal user, the member_domain and is_article_visible_by_everyone are checked to see if either user has access on the article or the article is visible by everyone. If the user is not an internal user (portal user), the article will be only accessed if they are a member of the article, without checking article's visibility, which causes the bug. opw-4835998
Zero-cost Brazilian point-of-sale orders now include the required payment information when sent for electronic invoicing. This prevents Avalara submission errors and helps ensure free or fully discounted sales can still be invoiced correctly.
Original PR description
Right now, for 0 cost POS orders no `paymentMode` section is sent to Avalara, which leads to an error from them when trying to submit the invoice: Code 899: incorrectly entered payment method field The proper fix is to always send `paymentMode` with a value of 0.00 and mode of `Other`. (Note that there is a payment mode that corresponds to no payment, 90, but it only available for NF-e not NFC-e so we use 99) opw-4874094
The Swedish SIE4 import now reads files using UTF-8 so Swedish characters are handled correctly. This helps avoid import errors or incorrect text when customers upload accounting files containing local characters.
Original PR description
The aim of this commit is using UTF8 instead of ISO-8859-1 for the file decoding. We received feedback from customers that the previous decoding wasn't handle correctly swedish characters. The documentation tends to say that we should follow CP437. As UTF8 is a superset of CP437, we are now using it. opw-4868415 Forward-Port-Of: odoo/enterprise#90498
This fix ensures invoice policy calculations only consider consumable products, preventing incorrect results when other product types are present. It helps avoid test failures and supports more reliable sales and invoicing behavior in affected localizations.
Original PR description
steps to reproduce: 1- install l10n_ke_edi_oscu_mrp 2- run test test_discount_and_untaxed_subtotal The compute_invoice_policy method was not correctly filtering products by their type. This fix ensures that only consumable products are considered when computing the invoice policy. build_error-70728 Forward-Port-Of: odoo/enterprise#90252
The Czech VAT Control Statement XML export now uses the official date field name for B2 vendor bill entries. This prevents the Czech tax portal from treating the field as blank, reducing filing errors for affected companies.
Original PR description
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and…
**Steps to reproduce**: 1. Install `l10n_cz` and `l10n_cz_reports_2025`. 2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill. 3. Go to Reporting → Tax Return → VAT Control Statement (CZ). 4. You will see the bill listed under section B2. Now export the XML. 5. In the exported XML, the field `dan_dppd` is present. **Observations**: When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`. According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized. **Issue**: The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section. **Solution**: The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation. opw-4868515 Forward-Port-Of: odoo/enterprise#90394
Miscellaneous changes
Related to https://github.com/odoo/enterprise/pull/90736 Forward-Port-Of: odoo/odoo#220031
Original PR description
Related to https://github.com/odoo/enterprise/pull/90736 Forward-Port-Of: odoo/odoo#220031
Related to https://github.com/odoo/odoo/pull/220031 Forward-Port-Of: odoo/enterprise#90736
Original PR description
Related to https://github.com/odoo/odoo/pull/220031 Forward-Port-Of: odoo/enterprise#90736