Daily updates from Odoo
Tuesday, September 23, 2025
300 changes
14 changes
Resolved issues and error corrections
This fix prevents live chat call cleanup logic from disrupting automated checks for operator assignment and chatbot call behavior. It helps keep internal quality checks stable without changing the customer-facing live chat experience.
Original PR description
Since [1], rtc sessions are garbage collected when creating new live chat sessions. Rtc sessions that didn't receive any update during the last minute are considered as inactive. This can interfere with agent assignation tests: operators in a call are not prioritized. If the session is garbage collected, they are not in a call, and tests can fail. fixes runbot-232705 [1]: https://github.com/odoo/odoo/pull/211359 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#227716 Forward-Port-Of: odoo/odoo#227648
This update prevents an error when users validate deliveries for products with expiry tracking where no removal date is set. It lets the delivery process continue as expected while still handling expiry checks safely.
Original PR description
currently an error occur when user proceed except expired delivery. Steps to Reproduce: - Install the `product_expiry` module. - Create a product with the configuration: - In `Track Inventory`,…
currently an error occur when user proceed except expired delivery. Steps to Reproduce: - Install the `product_expiry` module. - Create a product with the configuration: - In `Track Inventory`, select `By Lots`. - In the `Inventory tab`, check `Expiration Date`. - In the newly created product, click `Lot/Serial Numbers` button, create a new `Lot/Serial Number`, and clear the `Removal Date` of that Lot/Serial Number. - Go back to the newly created product and update the `Quantity On Hand` of the linked `Lot/Serial Number` by clicking `Update`. - Now go to `deliveries` and create a new `delivery` and add the newly created product and `validate` > `Proceed except expired`. `TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'` This error occurs when user proceed except expired delivery, The removal_date of the move line is computed based on the lot's removal date and the move line's expiration date. If the lot does not have a removal date and the move line also does not have an expiration date, then removal_date on the move line is set to False [1], which raises the error here [2] This commit ensures that it only compares with the move line removal_date if it is present. [1]- https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/models/stock_move_line.py#L56 [2]-https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/wizard/confirm_expiry.py#L48 sentry-6864176071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The offer creation form now uses the correct employee when opened from an employee record. This prevents users from seeing the wrong employee name in the "Offer for" field, reducing confusion during offer preparation.
Original PR description
#### Steps to reproduce Employees -> Create employee (or select employee) with offer -> Offers smart button -> New: wrong employee name in "Offer for ..." #### Reason Wrong key passed to context of the offers view via action_show_offers method #### Solution Replace key 'default_employee_version_id' with 'default_employee_id' task-5003544
Long out-of-stock messages on product pages now stay within their visible badge or message area when the screen is narrowed. This prevents messy overflow on the shop page and improves the customer experience on smaller screens.
Original PR description
When the Out-of-Stock message contains a long string of text at certain screen sizes, the text is longer than the parent div Steps to reproduce -------------------- 1. Have a tracked product with Continue Selling off and a long custom Out-of-Stock Message. 2. View the product shop page on the website. 3. Reduce the horizontal screen size until the text goes over the edge of the parent div(red rounded box). Cause ----- No CSS to handle when the text is longer than the parent element. Solution -------- Add text-wrap to parent div so the child element text wraps when necessary. opw-5056843
Sales orders with multiple nested return deliveries can now be cancelled without triggering a system crash. This improves reliability for teams handling returned goods and avoids disruption during order cleanup.
Original PR description
The system crashes with a `RecursionError` during the `Sale Order` cancellation with nested `returns`. **Steps to produce:-** - Install the `Purchase Stock` and `Sales` modules. - Create a new `Sales Order` (SO) with `Product A`. - Confirm the `Sales Order` and click on the `Delivery` button. - Click on `Return > Return all`. - In the new window, also click on `Return > Return all`. - Return to the `Sales Order` and attempt to `Cancel` it. **Error:-** `RecursionError: maximum recursion depth exceeded` **Solution:-** - Added a check for the self not already visited in the method `_get_upstream_documents_and_responsibles` to prevent revisiting the same move multiple times and `avoid infinite recursion`. **Sentry - 6693197358** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227992 Forward-Port-Of: odoo/odoo#217113
This fix ensures tables copied from tools like Google Docs keep the formatting needed to appear properly when pasted into Odoo editors. It also adds the expected editable content area inside empty table cells, making pasted tables easier to use immediately.
Original PR description
### Steps to Reproduce: - Go to the website. - Copy a table from Google Docs. - Paste the table into the editor. - Observe that the table is not visible because some required classes are missing. - Notice that there is no base container inside the empty `<td>` elements. ### Description of the issue/feature this PR addresses: - When content is pasted from other source (e.g., Google Docs inside iframe), attribute nodes coming from another JavaScript context do not match the `Attr` prototype of the current context. ### Desired behavior after PR is merged: - Use `item.nodeType === Node.ATTRIBUTE_NODE` instead of `instanceof Attr` to detect attribute nodes. - Insert a base container into empty `<td>` elements when pasting tables from external sources. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restores correct order summary handling in the Point of Sale by using the current data-saving method. It helps prevent errors caused by calling an outdated method, improving reliability for cashier workflows.
Original PR description
Replace usage of `serialize` (method that was previously removed) by `serializeForORM` in `OrderSummary`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225583
The bank reconciliation report now excludes exchange rate adjustment entries that do not represent real bank money movements. This prevents currency revaluation differences from appearing incorrectly under miscellaneous operations, improving report accuracy for foreign-currency bank journals.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870) Forward-Port-Of: odoo/enterprise#94172 Forward-Port-Of: odoo/enterprise#93999
This fix makes several automated website test journeys handle page reloads and redirects correctly. It helps keep validation runs reliable for website, event booth, exhibitor sales, and click-and-collect flows without changing customer-facing functionality.
Original PR description
\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect **Issue:** 1. Several tours across multiple modules were failing on runbot because some steps triggered a…
\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect **Issue:** 1. Several tours across multiple modules were failing on runbot because some steps triggered a page reload or redirect without using `expectUnloadPage: true`, which caused those steps to fail. 2. In the `webooth_exhibitor_register` tour, the behavior of the last step before calling the `_getSteps` function differs depending on the installed modules: - With only `website_event_booth_exhibitor` installed, the last step does not trigger a page reload. - With `website_event_booth_sale_exhibitor` also installed, the same step triggers a redirect to the checkout page, which caused the tour to fail. **Fix:** 1. Added `expectUnloadPage: true` to steps that trigger a reload/redirect, so the tour now waits for the new page to load before continuing. 2. Updated `_getSteps` in both modules: - Moved the problematic step of the `webooth_exhibitor_register` tour inside `_getSteps`. - In `website_event_booth_sale_exhibitor`, the same step was updated with `expectUnloadPage: true` to correctly handle the checkout redirection during the payment flow. runbot-[231586](https://runbot.odoo.com/odoo/error/231586) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures employee timesheets are recreated correctly when a public holiday is deleted or its calendar assignment changes. It prevents missing time-off timesheets and keeps holiday and leave records aligned for accurate reporting.
Original PR description
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating…
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating Timesheets. Validate it. - Expected: on the day of the public holiday, no timesheet is generated for the `hr.leave` to avoid duplication. - Either delete the public holiday, or set a calendar on it different than the one defined on the employee. - Issue: the public holiday timesheet has been deleted, but its deletion should've lead to the creation of the `hr.leave` timesheet that we didn't create at the time the public holiday existed. - Second issue: after that, change the calendar of the public holiday to the same as the employee's. Still a missing timesheet. **Solution** We can use `_reevaluate_leaves` to find the leaves affected by changes in public holidays. `_generate_timesheets` then re-generates the timesheets as if the leave was just validated (the call to `list_work_time_per_day` ignores the already present resource.calendar.leave). We also check missing public holidays timesheets to fix the second issue. opw-4819697 Forward-Port-Of: odoo/odoo#227299 Forward-Port-Of: odoo/odoo#216901
This change reorganizes editor tests so each scenario has its own timeout instead of sharing one limit across multiple checks. It helps reduce random test failures and keeps development validation more dependable without changing user-facing behavior.
Original PR description
Grouping multiple `testEditor` in a single `it` is bad practice because the timeout of `it` is then shared between the different `testEditor` calls rather than each having their own separate timers. Technically, only the web_edior tests ever timed out, but I split the html_editor ones as well for good measure. runbot-231687 Forward-Port-Of: odoo/odoo#227985
Website builder dropdown options now show a live preview when users hover over alternative selections, restoring behavior from the previous builder. Color-related builder actions also correctly distinguish preview changes from final selections, making editing more reliable and predictable.
Original PR description
### [FIX] html_builder, website: pass `isPreviewing` to action with colors With the commit 4448303436fd2d5afe235263e13a9d5daa2d14e1, the `apply` method of actions should receive an argument…
### [FIX] html_builder, website: pass `isPreviewing` to action with colors With the commit 4448303436fd2d5afe235263e13a9d5daa2d14e1, the `apply` method of actions should receive an argument `isPreviewing`. This has not been done for `BuilderColorPicker`. This commit adds the argument `isPreviewing` when calling `apply` in `BuilderColoPicker`. task-4367641 ### [FIX] html_builder, *: make options with BuilderMany2One previewable *: web, website With the initial [website builder refactor], the options based on `BuilderMany2One` were not previewable (they were in the previous builder). This commit brings back that behaviour. To do so it adds props to `SelectMenu` and options to `Navigator` to receive the information needed for the preview Steps to reproduce: - On `/blog`, open website builder - Click on the author of a blog post - In the sidebar, click on "Contact" to open the dropdown - Hover other authors than the current one - Bug: the hovered author is not previewed in the dom (like in was in the previous builder) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Invoice PDFs now include both the product name and its description when a description is present. This prevents customers from seeing only the description and helps keep invoices clear and identifiable.
Original PR description
When printing an invoice for a product that has a description, only the description appears on the PDF. Commit https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab removed the concatenation of the product name and description in updateLabel (in product_name_and_description in product module). This commit reintroduce the concatenation of the product name and the product description for invoices by overriding updateLabel in product_label_section_and_note_field in account. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4988340) opw-4988340
The self-invoicing portal now normalizes accented names so they can match official government records that omit accents. This prevents avoidable errors when customers request Mexican electronic invoices after a point-of-sale purchase.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
16 changes
Resolved issues and error corrections
The point of sale payment screen now correctly disables the Validate button on mobile when no payment method is selected. This helps prevent checkout mistakes and gives cashiers clearer guidance during mobile payments.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. task-id: 5072759 enterprise PR: https://github.com/odoo/enterprise/pull/94100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225975 Forward-Port-Of: odoo/odoo#225917
This change prevents public website visitors using older Safari versions from seeing a crash when pages load. It adds browser compatibility support needed for translation caching, improving reliability for affected users without changing normal functionality.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale payment screen now correctly keeps the Validate button disabled on mobile when no payment method has been selected. This prevents cashiers from accidentally proceeding with incomplete payments and improves checkout reliability on mobile devices.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#94132 Forward-Port-Of: odoo/enterprise#94100
Brazilian service invoices using AvaTax now send installment amounts without tax values, preventing mismatches that could cause invoice rejection. This improves reliability when processing service invoices with installment payments.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95244 Forward-Port-Of: odoo/enterprise#85108
Large online stores can now generate product sitemaps without exhausting server memory. This helps prevent crashes caused by search engine crawlers repeatedly requesting sitemaps for very large catalogs.
Original PR description
### Issue Server crashes with MemoryErrors when a database has a large product catalogs. ### Solution This commit disables the prefetcher to avoid MemoryErrors when generating the sitemap for large product catalogs as web crawlers would continously crash the server when requesting the sitemap. ### References opw-5001680 opw-4955333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223054
Appointments linked to resources now appear in the calendar views where users expect to find them. This restores visibility after the removal of the previous “Everybody’s Calendar” option, helping teams manage resource bookings without missing scheduled appointments.
Original PR description
**Steps to reproduce:** - Install Appointment app - Create a new resource - Create an appointment type with the new resource - Create an appointment for this type - Go to the Calendar app or to Appointments > Schedule > Resources Bookings - Click on the calendar view - The new appointment can't be found **Issue:** As "Everybody's Calendar" option was removed, there is currently no way to display the appointments on resources in the calendar view. **Fix:** Added a `calendar.resource.filters` model and its flow to the calendar view. It was also necessary to revert the parallel fetching of filters in https://github.com/odoo/odoo/commit/aa5f2d5dc3b7c64217cea57535b04261e801c4d2 to ensure the order of filters remains constant. related: https://github.com/odoo/odoo/commit/08ceb41a47de5ee1a0758eb0ebba3a3c6964a2f9 opw-4964405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointments linked to resources can now be found and displayed in the calendar view again. This restores visibility for resource bookings after the previous shared calendar option was removed, helping teams manage appointments without missing bookings.
Original PR description
**Steps to reproduce:** - Install Appointment app - Create a new resource - Create an appointment type with the new resource - Create an appointment for this type - Go to the Calendar app or to Appointments > Schedule > Resources Bookings - Click on the calendar view - The new appointment can't be found **Issue:** As "Everybody's Calendar" option was removed, there is currently no way to display the appointments on resources in the calendar view. **Fix:** Added a `calendar.resource.filters` model and its flow to the calendar view. related: https://github.com/odoo/odoo/commit/08ceb41a47de5ee1a0758eb0ebba3a3c6964a2f9 opw-4964405
The point of sale settlement tests no longer rely on a fixed calendar year when choosing invoices to settle. This makes automated checks more stable over time and helps prevent false failures that could slow down future releases.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171
Cancelling a sales order after creating multiple nested returns no longer triggers a system crash. This improves reliability for teams handling returned deliveries and prevents disruption during order cancellation.
Original PR description
The system crashes with a `RecursionError` during the `Sale Order` cancellation with nested `returns`. **Steps to produce:-** - Install the `Purchase Stock` and `Sales` modules. - Create a new `Sales Order` (SO) with `Product A`. - Confirm the `Sales Order` and click on the `Delivery` button. - Click on `Return > Return all`. - In the new window, also click on `Return > Return all`. - Return to the `Sales Order` and attempt to `Cancel` it. **Error:-** `RecursionError: maximum recursion depth exceeded` **Solution:-** - Added a check for the self not already visited in the method `_get_upstream_documents_and_responsibles` to prevent revisiting the same move multiple times and `avoid infinite recursion`. **Sentry - 6693197358** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227992 Forward-Port-Of: odoo/odoo#217113
This fix removes a hardcoded year used when selecting invoices to settle in point of sale localization tests. It helps keep automated checks reliable over time, reducing false failures without changing business workflows.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 enterprise PR: https://github.com/odoo/enterprise/pull/93166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The bank reconciliation report now excludes currency adjustment entries that do not represent real bank money movements. This prevents exchange rate adjustments from appearing under miscellaneous operations, making the report clearer and more accurate for foreign-currency bank journals.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870) Forward-Port-Of: odoo/enterprise#94172 Forward-Port-Of: odoo/enterprise#93999
This change fixes an inconsistent accounting test caused by duplicate domestic fiscal position candidates. It removes an invalid test assumption and adds a safeguard to warn if future localization data introduces the problematic case.
Original PR description
#### Issue: `test_domestic_fp` randomly fail #### Cause: While computing domestic fiscal position, there are 2 fiscal position candidates for being domestic as they got the same `sequence` and no `country_id`. It happens randomly that the second one is fetch instead of the first one. #### Solution: The failing assert checks a case that doesn't exist in any fiscal position data. Therefore, this commits remove this part of the test, but add a warning in `test_all_l10n` to ensure this case won't happen in new data. runbot-231686 This PR is linked to [this PR](https://github.com/odoo/odoo/pull/224599) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix reorganizes editor tests so each check has its own timeout instead of sharing one combined limit. It reduces random test failures in automated validation, helping keep development and release checks more stable without changing user-facing behavior.
Original PR description
Grouping multiple `testEditor` in a single `it` is bad practice because the timeout of `it` is then shared between the different `testEditor` calls rather than each having their own separate timers. Technically, only the web_edior tests ever timed out, but I split the html_editor ones as well for good measure. runbot-231687 Forward-Port-Of: odoo/odoo#227985
POS receipts now display preset information, such as customer addresses or time slots, centered in the receipt header. This improves receipt readability and provides a cleaner presentation for customers.
Original PR description
We now want to center preset infos on receipt header (customer address or time slot) in POS. task-id: 5048706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican e-invoicing flow now handles customer names entered with accents in the self-invoicing portal. This prevents valid invoice requests from failing when government records store the same legal names without accents.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
Refreshing appointment time slots now handles cases where no resource is selected. This prevents errors when checking maximum capacity, helping customers continue booking appointments without interruption.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
5 changes
Resolved issues and error corrections
Tax return closing entry reports now show the selected reporting month instead of the month when the closing entry is posted. This prevents incorrect PDF and XML report labels, helping businesses file and review tax returns with the right period information.
Original PR description
**Issue** When posting a closing entry in September on a tax return report for the month of August, the generated report (PDF/XML) incorrectly shows September instead of August. **Steps to…
**Issue** When posting a closing entry in September on a tax return report for the month of August, the generated report (PDF/XML) incorrectly shows September instead of August. **Steps to Reproduce** 1. Install Belgian localization. 2. Go to Accounting > Reporting > Tax Return. 3. Select August as the reporting period. 4. Post the Closing Entry. 5. The report shows September as the month instead of August. **Root Cause** The logic in `_init_options_date` was changed in PR #89290 mutating the `options['date']['filter']` by replacing `"tax_period"` with a resolved period type (e.g., `"month"`). As a result, the `"month"` branch was triggered later in the code, recomputing `date_from` and `date_to` based on the current date instead of the selected tax period boundaries. **Fix** Keep the `options['date']['filter']` unchanged (e.g., `"custom_tax_period"`). Use `period_type` field to indicate whether the tax period represents a month, quarter, or year. Opw-5073081 Forward-Port-Of: odoo/enterprise#94322
This fixes the Swiss ISO20022 payment export so generated payment XML files are accepted by Swiss banks again. Businesses using Swiss batch vendor payments can continue submitting files in the required format without manual corrections or rejected payments.
Original PR description
Since July, the iso20022 payment method is to not be accepted by some Swiss banks anymore. How to reproduce? Install account_iso20022 and enable batch payments in the accounting settings. Configure your journal adding the payment method "Swiss ISO20022" in the outgoing payments and setting the XML format as "pain.001.001.09". Pay a vendor bill using the "Swiss ISO20022" payment method. Go to the journal payment, select the previous payment and create a batch. On the batch payment, you can find the XML file which is not validated by Swiss banks. test validation on: https://ubs-paymentstandards.ch/login opw-4976852 opw-4675667 opw-4996910 opw-4895258 opw-5006895 task-id: 5000729 Forward-Port-Of: odoo/enterprise#92532
The bank reconciliation report now ignores foreign exchange adjustment entries that are not actual bank movements. This prevents currency revaluation differences from appearing under miscellaneous operations, giving finance teams a clearer and more accurate reconciliation view.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870) Forward-Port-Of: odoo/enterprise#94172 Forward-Port-Of: odoo/enterprise#93999
The Mexican electronic invoicing flow now handles customer names entered with accents when matching them to official legal names that do not include accents. This reduces failed CFDI stamping for self-service invoices requested after point-of-sale purchases.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
Refreshing appointment slots could fail when no resource was selected, preventing capacity from being calculated correctly. The fix handles missing resource selections safely so customers can continue booking appointments without interruption.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
31 changes
Security fixes and vulnerability patches
This update improves how content is cleaned and escaped in the HTML editor history dialog. It helps prevent unsafe translated content from being injected, reducing security risk for users editing website or document content.
Original PR description
Prevent a potential Translation injection by better escaping the result of `_removeExternalBlockHtml()` task-5085650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New functionality added to Odoo
This change adds a standard project configuration file to the repository. It helps development and automation tools recognize project settings more consistently, with no expected direct impact on business users.
Enhancements to existing features
This update adds automated test coverage for the self-order point of sale flow and improves the way its test environment is set up. It helps reduce future regressions in ordering, printing, and related service behavior without changing the day-to-day user experience.
Original PR description
- Isolated `printer` service into a standalone file to avoid naming conflicts with `point_of_sale` during tests. - Introduced `setupSelfPosEnv` to mock and bootstrap the self-order testing environment. - Add Hoot test coverage for core components, models, and service logic Task-4945633 Forward-Port-Of: odoo/odoo#220537
Project Managers can now edit or delete task and project templates directly from the dropdown list. This saves time by removing the need to open each template first, while keeping the actions available only to authorized users.
Original PR description
**Current behavior:** The user can not directly edit or delete task or project templates from the dropdown list; they must open the template first to perform these actions. **New behavior:** - Added pencil (edit) and trash (delete) icons to the dropdown actions for both task and project templates. - These icons allow users to edit or delete templates directly from the dropdown. - Icons are visible only to Project Managers. - By default, icons are hidden and appear on mouse-over. - In a small device, icons are always visible. task-5073053
This update adjusts the colors used in onboarding suggestions so they better match Odoo’s visual standards. Users will see a more polished and consistent experience in appointment and marketing automation onboarding screens.
Original PR description
*: appointment Before this commit, some onboarding suggestions were not fully aligned with Odoo’s UI standards. This commit adjusts colors to ensure better visual consistency. task-5082681 requires: https://github.com/odoo/odoo/pull/227113 (com) | | Current | This PR (active + hover) | |--------|--------|--------| | Mkting auto | <img width="1097" height="592" alt="image 19" src="https://github.com/user-attachments/assets/64e3409c-2252-4398-94d8-351500cc9595" /> | <img width="1097" height="592" alt="image 20" src="https://github.com/user-attachments/assets/08fe355d-8c7d-4961-a597-d90c3d671c52" /> |
The onboarding suggestions in Loyalty and Survey now use colors that better match Odoo’s interface standards. This creates a more consistent visual experience for users when viewing these sample onboarding elements.
Original PR description
Before this commit, some onboarding suggestions were not fully aligned with Odoo’s UI standards. This commit adjusts colors to ensure better visual consistency. task-5082681 -- Requires: https://github.com/odoo/enterprise/pull/94728 Preview Changes | | Current | This PR (hover) | |--------|--------|--------| | Survey | <img width="1103" height="640" alt="image 21" src="https://github.com/user-attachments/assets/4d3b542d-16ce-4194-b24d-f142d3073b88" /> | <img width="1103" height="640" alt="image 22" src="https://github.com/user-attachments/assets/0b91dad5-38ba-4617-b9d5-6c188fc12f2c" /> | | Loyalty | <img width="1103" height="634" alt="image 24" src="https://github.com/user-attachments/assets/eadbbe37-47c9-4486-8ae2-813863db614a" /> | <img width="1103" height="634" alt="image 23" src="https://github.com/user-attachments/assets/7d547cad-4ef7-4b80-8328-66ee7ea8b044" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live chat agents can now find and manage conversation tags more easily, with highlighted search matches, keyboard-style navigation, clearer action icons, and better mobile display. Tags also stay updated in active help-session views, and the system now prevents creating tags made only of spaces.
Original PR description
This commit introduces the following improvements to the livechat info side panel tags feature: - Characters in the tags matching the search term are highlighted. - The list of tags is navigable and the active item is highlighted. - Small UI changes on edit and add icons. - Tags are kept synchronized in the "looking for help" sessions view. - On mobile the tag list is now show in the bottom sheet. This commit also fixes the issue of creating a tag with only whitespace. task-5065034
The product ribbon assignment options in Website Sale now use more consistent capitalization. This makes the setting easier to read and keeps the interface wording aligned with business-friendly labeling standards.
Resolved issues and error corrections
The website editor now respects the same filtering rules used in the backend when selecting related records such as job locations. This prevents users from seeing unrelated contacts and keeps website editing choices consistent with recruitment setup.
Original PR description
Steps to reproduce: 1. Install `website_hr_recruitment` 2. Open the Recruitment module's tree view 3. Create a new job position 4. See the Job Location field in the form view under the recruitment page 5. Observe the fetched records 6. Go to the website via the smart button 7. Edit the website and click on the remote under the job position (Job Location) 8. Observe contacts in the web editor Issue: All partners are fetched instead of the filtered ones. Cause: The backend domain of the clicked field is not applied while fetching records in the web editor. https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/hr_recruitment/models/hr_job.py#L25-L36 Solution: Apply the backend domain of the clicked field when fetching records in editor. opw-4879929
This fixes an issue where online orders could keep using the Click and Collect warehouse even after the customer switched back to standard delivery. Orders now recalculate the warehouse at the right time, helping quotations and fulfillment use the correct stock location.
Original PR description
Steps: - Activate Click and Collect, then create a new warehouse. - For the product, add quantities in both locations. - Assign the second warehouse to Click and Collect. - Go to the website, add the product to the cart, choose Click and Collect as the delivery method, then switch it to Delivery and confirm payment. Issue: - When checking the quotation, it still uses the warehouse linked to Click and Collect. Cause: - Warehouse recomputation logic is called after _remove_delivery_line which resets the delivery_type of sale order. Since delivery_type is reset the sale order filter for warehouse recomputation does not work as intended. Fix: - Moved warehouse recomputation logic to _set_delivery_method which will filter the sale order before _remove_delivery_line. opw - 4965726, 5004170 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227983 Forward-Port-Of: odoo/odoo#225989
Credit notes for Mexico's general public tax regime now keep the selected "Returns, discounts or bonuses" usage instead of being changed to "No fiscal effects." This helps businesses generate compliant XML documents when issuing refunds or discounts under current SAT rules.
Original PR description
**Steps to reproduce:** 1. Install `l10n_mx` and `l10n_mx_edi`. 2. Create an invoice with: * Enable *CFDI to Public*. * Confirm, then send to SAT. 3. Create a credit note with: * *Usage* = `Returns,…
**Steps to reproduce:** 1. Install `l10n_mx` and `l10n_mx_edi`. 2. Create an invoice with: * Enable *CFDI to Public*. * Confirm, then send to SAT. 3. Create a credit note with: * *Usage* = `Returns, discounts or bonuses` (G02). 4. Download the generated XML for the credit note. **Observed behavior:** - The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects). **Expected behavior:** - The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected. **Root cause:** - For regime 616 (`Público en general`), the code always defaults to `S01`. - The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes. **Solution:** - Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616. **ref:** http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls opw-5012917 Forward-Port-Of: odoo/enterprise#95246 Forward-Port-Of: odoo/enterprise#93071
This fixes a Website Editor issue where the Cover Image option could stay hidden after changing a blog snippet back to showing a single item. Editors can now reliably toggle snippet settings without losing access to the cover image control.
Original PR description
Steps to reproduce: 1. Open Website Editor and drop a single aside blog snippet. 2. Change the Fetched Elements option to > 1. - The Cover Image option disappears (expected). 3. Change the Fetched Elements option back to 1. - The Cover Image option stays hidden (unexpected). Issue: The Cover Image option visibility is managed by useDomState. In dynamic snippets, the core snippet is rendered by an Interaction, while options are rendered before the Interaction starts. Since useDomState observed the element before the Interaction rendered the final one, the option visibility became desynchronized. Fix: Use the `isSingleMode` state to ensure the Cover Image option remains in sync when toggling between 1 and >1 fetched elements. 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
A Chilean localization invoice report issue was fixed so invoiced Point of Sale orders can be validated without triggering a template rendering error. This helps businesses using Chilean electronic invoicing avoid blocked sales processing at checkout.
Original PR description
**Steps to reproduce:** - Install l10n_cl_edi_pos - Create a PoS order and enable the invoice option. - When clicking on the validate button, the following traceback appears - Error :- `Error while rendering the template` - Please see [issue](https://www.loom.com/share/24f02eca5b2344c083bf7e0b990d3979?sid=d20f31e8-2776-4dda-a6bc-819a76eb3275) **Cause**: - In [this commit](https://github.com/odoo/odoo/pull/223686/files#diff-c85e75bc27fc841662ca0598c09a22670e0a0b4e5120815934c0a50999ff02bfL175), we removed the 'current_total' section. **Solution:** - Correct the XPath according to the new commit
Creating a milestone from a Sales Order now keeps the correct project selected, preventing an error during milestone setup. This helps sales and project teams use milestone-based service products without manual workarounds.
Original PR description
**Steps to reproduce:** Create a service product with invoicing policy set to Based on milestones. Create and confirm a Sales Order with this product. Open the Sales Order and click on the Milestones stat button. In the milestones list view, click New to create a milestone. **Cause:** The default logic that was supposed to select the default project from context or active_id so it used the active_id which is Sales Order ID. **Issue:** When creating a milestone from a Sales Order, the project was not set correctly, which caused an error. **Fix:** Add the project_id field in list view to avoide default method call. task-5090316 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227491
Product packaging options are now shown even when a product has no variants, as long as it offers multiple units of measure. This helps shoppers see available packaging choices more consistently on the website product page.
Original PR description
Packaging options was only viewable if a product had variants. Modify condition to view product packaging when it has multiple uoms. opw-5104189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cancelling a sales order after multiple return steps no longer causes the system to crash. This improves reliability for teams handling product returns and prevents failed cancellation workflows.
Original PR description
The system crashes with a `RecursionError` during the `Sale Order` cancellation with nested `returns`. **Steps to produce:-** - Install the `Purchase Stock` and `Sales` modules. - Create a new `Sales Order` (SO) with `Product A`. - Confirm the `Sales Order` and click on the `Delivery` button. - Click on `Return > Return all`. - In the new window, also click on `Return > Return all`. - Return to the `Sales Order` and attempt to `Cancel` it. **Error:-** `RecursionError: maximum recursion depth exceeded` **Solution:-** - Added a check for the self not already visited in the method `_get_upstream_documents_and_responsibles` to prevent revisiting the same move multiple times and `avoid infinite recursion`. **Sentry - 6693197358** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227992 Forward-Port-Of: odoo/odoo#217113
This fixes an issue where receipt links for downloading invoices could fail because ticket numbers were required to be too long. The point of sale now accepts shorter ticket numbers again, helping customers and staff access invoices from receipts reliably.
Original PR description
- Since this PR (https://github.com/odoo/odoo/pull/222261) the minimum length of the Ticket Number (pos_reference) has been set to 12 characters. This was causing issues when trying to download invoices with the link on the receipt. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures employee time-off timesheets are recreated when public holidays are deleted or their calendars change. It prevents missing timesheet entries after holiday updates, improving accuracy for leave tracking and reporting.
Original PR description
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating…
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating Timesheets. Validate it. - Expected: on the day of the public holiday, no timesheet is generated for the `hr.leave` to avoid duplication. - Either delete the public holiday, or set a calendar on it different than the one defined on the employee. - Issue: the public holiday timesheet has been deleted, but its deletion should've lead to the creation of the `hr.leave` timesheet that we didn't create at the time the public holiday existed. - Second issue: after that, change the calendar of the public holiday to the same as the employee's. Still a missing timesheet. **Solution** We can use `_reevaluate_leaves` to find the leaves affected by changes in public holidays. `_generate_timesheets` then re-generates the timesheets as if the leave was just validated (the call to `list_work_time_per_day` ignores the already present resource.calendar.leave). We also check missing public holidays timesheets to fix the second issue. opw-4819697 Forward-Port-Of: odoo/odoo#227299 Forward-Port-Of: odoo/odoo#216901
Planning now correctly calculates weekly progress for flexible employee shifts that span across two weeks. This prevents the current week from showing hours that belong to the following week, making workload tracking more reliable.
Original PR description
### Steps to reproduce: - Install Planning app - Create a shift for a flexible employee that starts on Friday and end on the following Tuesday for example - Go to the gantt view for the week that the shift should start at - Notice the progress bar is showing the whole allocated hours not just the week's hours ### Cause: This mainly happening because when the employee is flexible we are getting the value by multiplying the hours_per_day of his schedule by the period.days and the period is the shift period ### Fix: We use the interval we are just checking as the period now so if the shift is extended to the next week we are just going to use the end of the week as the interval end not the shift's end_datetime opw-5022800 Forward-Port-Of: odoo/enterprise#95199 Forward-Port-Of: odoo/enterprise#93404
This fixes an issue where users on Safari, Firefox Mobile, and Chrome Mobile could not reliably grant microphone or camera access when starting a Discuss call. The call permission flow now works around browser limitations so users can enable audio and video as expected.
Original PR description
Before this commit, it was practically impossible to enable the microphone and camera on some User Agents. The User Agents affected include Safari Desktop/Mobile, Firefox Mobile and Chrome Mobile. On those platforms the `change` event of PermissionStatus is never fired, breaking the flow of the new permissions flow introduced in [1]. Steps to reproduce: 1. Open Discuss on one of the listed user agents. 2. Start a call 3. Unmute to prompt microphone permissions -> observe being unable to give permissions This commit fixes the issue by manually setting the permission status of voice and video on the affected user agents. [1] https://github.com/odoo/odoo/pull/226552 task-5090302
The Documents list for Sign now shows the most recently created sign requests at the top. This helps users find and open new requests faster without scrolling through older items.
Original PR description
Before: * New sign requests appeared at the bottom of the `Documents` list. * Users had to scroll down to find the latest requests. After: * The list is now sorted by creation date (newest first). * New sign requests appear at the top of the`Documents` screen. Impact: * Makes it easier for users to quickly find and access the most recent sign requests. task-5098740
The HTML editor now correctly allows users to replace Odoo, brand, regular, and duotone icons with standard Font Awesome icons. This fixes a limitation in content editing, making icon customization more reliable for website and document editors.
Original PR description
Description of the issue this PR addresses: Before this PR, It wasn't possible to replace Odoo icon (oi) or Font Awesome duotone (fad), brand (fab), and regular (far) icons to a font awesome (fa) icon. This PR adds support replace such icons to fa icons. task-4972193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Receipts now use a smaller, receipt-friendly version of the company logo and store it directly with the receipt data. This prevents missing logos on iOS devices, with large logo files, or when browser caching is unavailable, helping businesses keep receipts consistently branded.
Original PR description
Some clients reported that the company logo was not displayed on receipts. This issue was reproducible when using iOS with a large logo file, and in some cases when the browser cache was disabled. This commit addresses the issue by: - Using the image_256 version of the company logo to fix rendering on iOS. - Storing the logo as data url to avoid repeated URL requests and cache-related issues. Task-5055910 Sample company logo causing issue [logo.zip](https://github.com/user-attachments/files/22251877/logo.zip) Forward-Port-Of: odoo/odoo#227478 Forward-Port-Of: odoo/odoo#225743
Bank synchronization now avoids sending an extra payment identifier unless the related payment standard module is installed. This prevents failures for companies using Odoo’s online banking connection without that optional module.
Original PR description
Odoofin always give the 'end_to_end_uuid' info. But it's a field that is only defined in account_iso20022. So we should not give this field in the create if the module is not installed.
Survey invitation emails now correctly update their subject line when a different or edited email template is selected. This prevents outdated subjects from being sent and helps teams keep survey communications consistent with their chosen templates.
Original PR description
Description of the issue/feature this PR addresses: Fixed [previous commit] where the subject doesn't update when the template was updated. This was due to a filter in place preventing this from happening. Steps to reproduce on runbot: 1. Go to mail templates and search for Survey 2. Open the Survey: Invite template 3. Update the subject on this template 4. Open the Surveys app and select any survey 5. Click on Share and then enable send by email 6. Change the template being used 6. The subject will stay the same [previous commit]: https://github.com/odoo/odoo/commit/16a2c28c9aec307f7ce9dbed0a660b512db31f3a opw-4654411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227460 Forward-Port-Of: odoo/odoo#221049
Fixed an issue where notification messages with both a title and formatted content could display raw HTML instead of the intended button or styling. This improves clarity for users seeing alerts such as CRM enrichment credit warnings.
Original PR description
This commit fixes the notification's rendering issue when both message and title are provided. Before, the message's HTML was escaped even if marked as safe with `markup`. Steps to reproduce: - Open CRM app - Open a lead - Click on "Enrich" button => a notification appears "Not enough credits" but the button's html is not properly rendered (escaped). task-5088945
Fixes a problem that caused an error when users tried to translate a message from the mobile chatter action menu. This makes message translation work reliably on mobile, improving usability for multilingual users.
Original PR description
Steps to reproduce: - Open any chatter with a message on mobile - Try to translate the message using the Translate mobile action => Throws traceback This happens because the component here is `MessageActionMenuMobile` instead of `Message`, and MessageActionMenuMobile does not have the `onClickToggleTranslation` method. This PR fixes the issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227902 Forward-Port-Of: odoo/odoo#223567
The website generator help page now points users to the correct support contact instead of an incorrect email address. This helps customers reach the right support channel and reduces confusion when they need assistance.
Original PR description
Changing wrong email into the support /help page. Task: odoo.com/odoo/project.task/5100049?menu_id=4720
Long custom out-of-stock messages on product pages now wrap within their display box instead of spilling outside it at narrower screen widths. This keeps product availability information readable and preserves a cleaner shopping experience for customers.
Original PR description
When the Out-of-Stock message contains a long string of text at certain screen sizes, the text is longer than the parent div Steps to reproduce -------------------- 1. Have a tracked product with Continue Selling off and a long custom Out-of-Stock Message. 2. View the product shop page on the website. 3. Reduce the horizontal screen size until the text goes over the edge of the parent div(red rounded box). Cause ----- No CSS to handle when the text is longer than the parent element. Solution -------- Add text-wrap to parent div so the child element text wraps when necessary. opw-5056843 Forward-Port-Of: odoo/odoo#227010
Customers can now retrieve invoices through POS self-invoicing without encountering an incorrect ticket-number validation error. The fix updates the system to recognize the newer POS receipt sequence format, making invoice access smoother and more reliable.
Original PR description
Before this commit: - Fetching an invoice through self-invoicing caused an error: `Ticket Number should be at least 14 characters long`. After this commit: - With the revamp of the POS sequence, the new sequence format has been adapted, resolving the issue. task-5092989
Fixes a crash that occurred when users selected Add GIFs from the More Actions menu in chat. The GIF picker now opens correctly, including when no GIF service API key is configured, helping users continue composing messages without interruption.
Original PR description
**Description of the issue this PR addresses:** Traceback on clicking `Add GIFs` from more actions **Steps to reproduce:** - Open a Chat Window and click on `+` More Actions. - Select the Add GIFs option. **Desired behavior after PR is merged:** This PR ensures that the Add GIFs option is accessible from More Actions. If no API key is configured, the picker now opens the popover as expected instead of crashing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
24 changes
New functionality added to Odoo
Odoo spreadsheets can now calculate account residual amounts for selected periods and partner balances directly with new formulas. This helps finance teams build more complete reports without manual exports, while related performance improvements make accounting spreadsheet calculations faster and more predictable.
Original PR description
Problem --------- There is currently no formula to get the residual amount of accounts in a given period of time in spreadsheets. Similarly, there is no formula to get the balance of a partner. Objective --------- Add the formula ODOO.RESIDUAL and ODOO.PARTNER.BALANCE that does just that. Furthermore, this PR contains a refactor of the addons/spreadsheet_account/models/account.py for easier management and faster computation of the functions. Check the relevant commits for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Adds a dedicated option on the IoT Box homepage to resend connected device information to the Odoo server. This helps recover missing or reset IoT device records faster, avoiding unnecessary service restarts in lab, demo, or support situations.
Original PR description
In the context of the labodoo, database without IoT box are reseted which force to restart the IoT service to re-setup the IoT in the database. This does take some time and ressources that is not neccesary in this context as we would only need to retieve the IoT devices information. This PR propose the idea of having a dedicated route that would directly call the `send_alldevices` method which call `/iot/setup` route which will update the devices. I do think it can also be convenient in the context of the support in the case somehow a device was not synced (can likely happen if the odoo server was down when it was detected) or if the iot box record was removed from the odoo database and need to be recreated Preview: <img width="344" height="512" alt="image" src="https://github.com/user-attachments/assets/1b6c94b5-3f79-4d51-8e0e-f6a83f31bf46" /> task-5101536
Resolved issues and error corrections
Employees and managers can now enter a checkout time directly from the Attendance Gantt popup for open attendances. This fixes a display issue that hid the checkout field when it was empty, reducing extra navigation and manual correction steps.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978
Archived or trashed documents are now correctly hidden when users search for document values while setting up automation actions. This prevents users from accidentally selecting removed documents, while still allowing archived automation rules to remain visible where intended.
Original PR description
This PR addresses an issue where trashed files in documents would still appear when clicking on 'search more' when searching for documents.document in a scheduled action's action. The issue is that…
This PR addresses an issue where trashed files in documents would still appear when clicking on 'search more' when searching for documents.document in a scheduled action's action. The issue is that the base_automation_act view sets active_test context to False. This context is propagated to view_base_automation_form and results in the context for the field action_server_ids to be active_test = False. The fix for this issue will just be setting active_test to True for the action_server_ids field. This will make it such that the 'search more' action will no longer display anything archived but archived automation rules will still be displayed which was probably the original intention of setting active_test to False in base_automation_act. Steps to reproduce bug on empty DB: 1) Install base_automation and documents modules. 2) Create a new automation rule targeting the documents module. Make sure to add a trigger. 3) Click on 'Add an action' in the page 'Actions To Do'. 4) In the wizard under action details, set the targeted field to 'folder' (folder_id). Leave the action as 'Update'. 5) Click on the 'Choose a value' drop down. 6) Click on 'Search more'. 7) Notice the number of documents that show up. The numbers on the top right hand side of the wizard should be 1-y/x where x is the total number of documents. 8) Go to the documents module and select any document. 9) Move the document to the trash with the actions button. 10) Repeat steps 4-7. Notice how the number of documents did not change. Behavior after bug fix: Upon completing step 10 of steps to reproduce on empty DB, the number of documents will be one less than what it was originally since we trashed one of the documents. task-4886487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an automated test that could fail when Czech localization was installed. It makes the test use the actual payment reference generated by the system, improving build reliability without changing business functionality.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479
This fixes an issue where Ctrl+Backspace behaved differently in Firefox and Safari compared with Chrome when editing empty or adjacent paragraphs. Users now get consistent text deletion behavior across supported browsers, reducing editing surprises and accidental content changes.
Original PR description
**Current behavior before PR:**
In Firefox or Safari, `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` ends up with `<p>abc []</p>` which is different o/p than Chrome (`<p>abc def[]</p>`).
This happens because Firefox's Selection.modify("extend", "backward|forward", "word") behaves differently than Chrome when the cursor is at the start or end of a block (or in an empty block). This behavior breaks the output when pressing ctrl + backspace.
**Desired behavior after PR:**
This PR ensures that in such case deletion behavior is same across browsers as Chrome. In other words `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` should be `<p>abc def[]</p>` .
task-5055135
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCustomer statement emails sent from child contacts now avoid sending empty statement attachments. The statement button is also hidden when there is no activity or no amount due, reducing confusion for accounting users.
Original PR description
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and…
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and confirm it. 3. Go to the child contact and open the Customer Statement smart button. 4. Download the PDF → data is shown correctly. 5. Send the statement → the attachment in the sent mail is empty. **Issue:** - When sending customer statements via email from a child contact, the generated PDF attachment contains no data, showing empty amounts and transactions. - Additionally, the "Customer Statement" button was still visible even when the total due was zero. **Cause:** - The button visibility condition checks for `total_due == 0.0 and not has_moves`, which didn’t properly cover all use cases. **Solution:** - Update button visibility condition to: `invisible="not has_moves or total_due == 0"` ensuring it is hidden when there are no moves or the total due is zero. **opw-5009182**
This fix prevents key details on confirmed and locked sales orders from being changed in another browser window. It helps avoid data corruption when multiple users or tabs interact with the same order at the same time.
Original PR description
Add _get_protected_fields() method and protection logic to prevent modification of critical fields when sale order is locked, matching the existing protection in sale.order.line. Problem Critical…
Add _get_protected_fields() method and protection logic to prevent modification of critical fields when sale order is locked, matching the existing protection in sale.order.line. Problem Critical vulnerability where multiple users could simultaneously edit the same sale order, causing data corruption when an order was confirmed (and locked) in one window while still being edited in another. Specific scenario: Sale order opened in 2 windows/tabs simultaneously User A confirms the order → automatically locked ([locked=True](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html)) User B can still modify [partner_id](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html) from the other window Result: Corrupted data in confirmed order --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops internal users from being assigned to a website in a way that could later break module installation, such as Helpdesk. Users are now warned earlier when the setup is invalid, reducing unexpected installation failures and improving reliability.
Original PR description
Scenario: - Install website and set a website on an internal user - Install helpdesk Result: installation fails with a traceback containing the message "Remove website on related partner before they…
Scenario: - Install website and set a website on an internal user - Install helpdesk Result: installation fails with a traceback containing the message "Remove website on related partner before they become internal user.". Cause: 479e8d0cae98f7e086e5fb4a0ca4e33ed24bfc12 added a constraint so when the groups are changed, we raise an error if the user is internal and as a website_id set. But if we do it the other way (setting a website_id on an internal user), no restraint prevent this, but if at any moment the groups of the user are changed (which helpdesk does by adding implied_ids groups) we get an unexpected error. Fix: change the constraint to be triggered by both website_id and groups_id change so the user is aware sooner than he should not do it. Note: the current code also prefetched all internal users and would not work with non-active user, so this code simplifies that by just prefetching the groups of the current users. opw-5077601 PR note: putting this in draft since this is breaking some tests that I need to check
Membership invoices now keep the right invoice context when opened, so membership products remain searchable on invoice lines even if they are not marked as purchasable. This prevents users from being blocked when editing draft membership invoices after changing product purchase settings.
Original PR description
**Steps to Reproduce:** 1. Create a new membership product from the Membership module. 2. Open any partner and go to the Membership page. 3. Click on Buy Membership and select the created product. 4.…
**Steps to Reproduce:**
1. Create a new membership product from the Membership module.
2. Open any partner and go to the Membership page.
3. Click on Buy Membership and select the created product.
4. Click on Invoice Membership.
5. Open the newly created draft invoice.
6. From the invoice line, open the product form (via the internal link).
7. Disable the Can be Purchased option and return to the invoice using breadcrumbs.
8. Add a new line in the invoice and search for the same product by its name.
**Observation:**
1. When Can be Purchased is enabled on the product, the product appears in the invoice line search.
2. When Can be Purchased is disabled, the product no longer appears in the search.
**Issue:**
In the product field domain defined in
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029 the `default_move_type` context is `null`.
As a result, only the condition `[('purchase_ok', '=', True)]` is applied in the `name_search` domain.
**Solution:**
Pass the proper context value in the invoice action, ensuring the domain evaluates correctly and the product remains searchable.
**Note:**
The domain used in the following field
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/account/views/account_move_views.xml#L1022-L1029
is evaluated by a following JavaScript function
https://github.com/odoo/odoo/blob/9ba5b41ef0252f4421ff6cdcd7c047b7c53706f4/addons/web/static/src/core/py_js/py_interpreter.js#L483-L489
rather than on the Python backend. Because the domain logic depends on dynamic
context evaluation performed client-side, there is no straightforward way to
retrieve or test the domain arguments dynamically within the `name_search`
method on the server. As a result, it is not feasible to write automated test
cases for this specific domain filtering scenario in the backend.
opw-5028789
Forward-Port-Of: odoo/odoo#225230This fix corrects a typo that affected how a lock-date warning message was displayed when editing report external values. The message now appears as a properly formatted list, making it easier for users to read and understand what is blocking the change.
Original PR description
[FIX] account_reports: typo in error message typo in generation of error message saying that lock dates are blocking the modification of a report external value See odoo/enterprise#92949
The analytic distribution widget now limits analytic account choices to the company on the document. This prevents users in multi-company environments from seeing or selecting accounts from other companies, helping enforce company data separation rules.
Original PR description
**Description of the issue/feature this PR addresses:** When creating or editing an analytic distribution, the analytic account selection does not respect the company context. This allows users to…
**Description of the issue/feature this PR addresses:** When creating or editing an analytic distribution, the analytic account selection does not respect the company context. This allows users to see and select analytic accounts from other companies, which violates the multi-company record rules. <img width="669" height="333" alt="2025-09-08_09-28" src="https://github.com/user-attachments/assets/488eb4b1-fdfa-49ca-a57e-8f46a264107d" /> **Current behavior before PR:** The analytic account dropdown in the analytic distribution widget shows analytic accounts from all companies, instead of being restricted to the current company. **Desired behavior after PR is merged:** The analytic account selection in the analytic distribution widget is filtered by company. Only analytic accounts belonging to the document company will be displayed, ensuring compliance with multi-company record rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Public holiday timesheets now reflect each employee's flexible work schedule instead of defaulting to the company's standard 8-hour day. This prevents overstated time off entries for employees whose configured average day is shorter, improving accuracy in timesheets and leave reporting.
Original PR description
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible…
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule ## Cause: When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()` This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end) These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed: https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393 We want to use the calendar itself as the calendar resource to get the `work_hours_data` ## Steps to reproduce: - On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week - Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6) - In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values) - Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off opw-4881758
New customers created from Point of Sale now show the configured default pricelist instead of simply using the first available pricelist. This restores the expected behavior and helps cashiers avoid assigning the wrong pricing to new customers.
Original PR description
**Problem:** When creating a new partner from PoS, the suggested pricelist is not the default pricelist we defined in the configuration. It worked before 18.0, but now the suggested pricelist is the first one that we defined in the configuration, not the one we set as default. **Steps to reproduce:** - In the configuration, enable flexible pricelists and fill some available pricelists. - Set a default pricelist that is not the first one you defined in the available section. - Open a session, click on the customer and click on create. - Go to the Sales and Purchase tab. - The pricelist is not the default one. **Why the fix:** If we are in PoS, we now put the default pricelist as a default for the new partner. We only do that if it is available, otherwise we fall back to the default flow. This is how it worked before 18.0. opw-4876573
Invoices using multiple taxes included in the price now calculate taxable bases and tax amounts consistently when some taxes affect later tax calculations and others do not. This prevents incorrect tax report warnings and keeps financial reporting more reliable, with only minor rounding differences expected in related discount scenarios.
Original PR description
**Issue** When creating an invoice with two price-included taxes, one that affects the base of subsequent taxes (`include_base_amount=True`) and another that does not, the tax computation is…
**Issue** When creating an invoice with two price-included taxes, one that affects the base of subsequent taxes (`include_base_amount=True`) and another that does not, the tax computation is incorrect. This leads to inconsistent base amounts and triggers a warning in the tax report, particularly visible in the Tax Return Report. **Steps to Reproduce** 1. Create two taxes with `price_include=True`: Tax1 with "Affect Base of Subsequent Taxes" disabled Tax2 with it enabled 2. Add both taxes to the same invoice line and confirm the invoice 3. Open the Tax Report and filter by the invoice date 4. The report shows an inconsistency because the computed base is wrong **Root Cause** The batching logic separates taxes into groups when their properties differ. In this case, because the two taxes have different `include_base_amount` values, they are split into different batches. Since batching drives how price-included taxes are reversed to compute the base, splitting the batch leads to misinterpreted base amounts and incorrect tax calculations. **Fix** Adjusting batching conditions to allow taxes to be grouped together even if their `include_base_amount` flags differ. This ensures that price-included taxes are handled consistently and the base is computed correctly across all taxes in the group. Opw-4863100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Accounting follow-up report now stays usable when customers have many invoices and users load additional report lines. This prevents an error screen during collections or statement review workflows, helping finance teams continue their work without interruption.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**Barcode database lookups now fill in product details only when those fields are empty, so existing eCommerce descriptions are preserved. This prevents manually curated online product content from being accidentally replaced by external barcode data.
Original PR description
Scenario: - enable "Barcode Database" in general settings - set an eCommerce description on a product - set a barcode in the database on that product (eg. 799439112766) Result: the eCommerce description has been overwritten by the barcode lookup result. Fix: do like other _update_product_by_barcodelookup methods and only update value that are not yet set. Note: also fixes the return of the overridden methods. opw-5061231
This fix prevents customers using a QR self-ordering menu on separate devices from being sent to another customer’s order confirmation page after online payment. It ensures each device only confirms the order that belongs to it, reducing confusion during mobile ordering.
Original PR description
Before this commit, if two devices were using the mobile menu, when one order was paid through online payment, the other device was redirected to the confirmation page, but the payment was not for its order. Steps to reproduce: 1. Enable self ordering QR menu + Ordering 2. Create an online PoS payment method with demo payment provider 3. Open the QR code menu on 2 devices 4. On one device, make an order and pay => the other device is redirected to the confirmation page opw-5046207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refund orders created from the back office now receive the required identifier, preventing problems when opening them in the Point of Sale screen. This helps staff continue draft refunds and complete payments without interruption.
Original PR description
Before this commit, refunded orders created from the backend were missing a UUID. This could cause issues when trying to load a draft refund order into the PoS UI and proceed with its payment. opw-5081385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures custom gift card codes entered in Point of Sale are kept even if the order is reloaded before payment. It prevents automatically generated or mixed-up codes from appearing on receipts, PDFs, and backend coupon records.
Original PR description
**Steps to reproduce:** - Go to PoS - Buy a gift card, click on the sell physical gift card - Set a custom code and price - Reload the page - Go through with the payment and check the downloaded pdf…
**Steps to reproduce:** - Go to PoS - Buy a gift card, click on the sell physical gift card - Set a custom code and price - Reload the page - Go through with the payment and check the downloaded pdf - The coupon code is an automatically generated one **Problem:** When reloading the coupons after reloading the order, the gift cards lose their custom codes if it was set before. This means that the coupon will have an automatically generated name in the backend as well as in the pdf that is downloaded once the payment is done. **Why the fix:** This happens because we are trying to access the order.get_selected_orderline()?.gift_code to get the coupon code. https://github.com/odoo/odoo/blob/f13ee41a4a62f7fedbddc4245e52ee8e9dce9e0e/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L230 But when we leave the order to go back in afterwards, there is no selected line anymore, so the gift_code is undefined. We then fallback to the default code, which is to generate one for the user. The gift_code is still on the orderline, so all we need to do is to link the newly created coupon with the gift_code in the orderline. Another problem that arises her is that when purchasing a custom gift card AND a default gift card in the same order, then reloading, the gift codes will be mixed up in the pdf and in the backend as well. This happens because the custom code's name in the backend is 'code' and we use gift_code in the frontend, so we assign the gift_code to the code in the backend. opw-4964509
When a customer is selected in Point of Sale, the Quotation/Order action now shows only that customer’s quotations and orders. This prevents staff from seeing unrelated customer orders and helps them find the right sale faster.
Original PR description
Before this commit, when selecting a customer in the POS and clicking Actions → Quotation/Order, all quotations and orders were displayed instead of filtering by the selected customer. This commit ensures that only the quotations/orders of the selected customer are shown. opw-5074052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website page templates with highlight effects now keep the correct simplified highlight setup when selected from the preview. This prevents visual highlight issues from being carried into newly created pages, improving consistency for website editors.
Original PR description
Starting from [1], the code from the "Snippets Preview" and the "New Page Templates Preview" was adapted to be able to build a highlight using its simplified format when provided in XML. The goal of this PR is to fix the new page DOM when a template with highlights is selected. The DOM will be simply cloned and used for the created page, so we need to reset the inner highlights to their minimal format. [1]: https://github.com/odoo/odoo/commit/4a29fa66003ce1f42a7011bc56fc019f34a887f5 task-4215788
Partially refunded point-of-sale orders now recalculate the amount due using only the remaining order lines. This prevents customers or staff from paying the original full total again when processing a later refund.
Original PR description
Before this commit, refunding a partially refunded order did not update the total price based on the remaining lines. As a result, it was possible to pay the original total amount instead of the correct remaining amount. opw-5100790 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refreshing appointment time slots could fail when no resource was selected because the system tried to read an empty value as a number. This fix handles empty selections safely, so customers can refresh available appointment slots without errors.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
10 changes
Enhancements to existing features
Italian electronic invoice imports now keep the document type from the original XML and no longer rely on separate type variants that duplicated the same document code. This makes invoice and bill handling more consistent when the same FatturaPA document type can apply to either sales or purchases.
Original PR description
In the FatturaPA XML, the Document Type (Tipo Documento) doesn't indicate the direction of the journal entry. A `TD01` can be an `in_invoice` or `out_invoice` depending on whether the company is set to be the seller or the buyer. That's what we consider when importing invoices from the EDI. - saved the `l10n_it_document_type` from the imported bills' XML - removed the filter in the view - removed the `l10n_it_document_type` duplicates that just differed by `l10n_it_document_type.type` - updated the invoices to point to the original `l10n_it_document_type` if there were duplicates We will have to remove the field in `master` See odoo/upgrade#8484
Resolved issues and error corrections
This fix prevents synchronization error messages from causing a crash in the Romanian e-invoicing flow. Businesses using Romanian electronic invoicing get more reliable error reporting when communication issues occur.
Original PR description
Problem
---------
Currently, the 'error' message (in case of communication error) is stored in the 'answer' dict. However, the code verify for the 'error' key in the message dict itself.
Solution
---------
When checking if the 'error' key is present, check in the 'answer' dict rather than the message dict
The code is
```message = {**data, 'answer': {**data, 'error': ""}}```
The verifications were
```'error' in message ?```
and now they are
```'error' in message['answer'] ?```
opw-5046567
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects rounding behavior when Mexican companies register payments in pesos for invoices issued in a foreign currency. It helps prevent valid payment e-invoices from being rejected due to small currency conversion differences.
Original PR description
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de los importes de las bases registrados en los documentos relacionados donde el impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de este elemento.
This occurs because the precision set in
e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is too high and can lead to failed verification due to rounding issues
opw-4750981WhatsApp chats now update to the correct contact when a phone number is moved from one contact record to another. This prevents new messages from showing the old contact name, reducing confusion for teams managing customer conversations.
Original PR description
Issue: When we have a Whatsapp contact that we have already used and for some reason we decide to move this contact phone number to a different contact, then when receiving or sending messsages again to this contact, we will still see the old contact name for the new messages. Steps to reproduce: Notice: You will need to follow the steps needed to set up a Whatsapp account and connect it to the db. 1. Create a new contact with the phone number linked to your whatsapp. 2. Start a conversation with this contact through whatsapp. 3. Move now the phone number, to a different contact. 4. Send messages again from the whatsapp to our db. Solution: We could fix this by checking inside the _get_whatsapp_channel if our channel whatsapp partner still has a phone number linked to it, if it doesn't, then we should try to retrieve the new contact that has our phone number linked to, and set it as our whatsapp partner. opw-3812366
Sales order invoiced amounts now ignore invoice note and section lines, matching standard accounting behavior. This prevents non-billable display lines from affecting invoiced amount calculations and related filters.
Original PR description
When computing the invoiced amount for a SO, ignore the invoice's lines of `display_type` equal to `line_note` and `line_section` This matches the accounting features which always ignore such lines. **Current behavior before PR** Method `_get_sale_order_invoiced_amount` includes display lines. **Desired behavior after PR is merged** Method `_get_sale_order_invoiced_amount` ignores display lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Grouped views now exclude archived records, such as inactive contact tags, from group headings while still allowing empty values. This keeps reports and list groupings focused on active business data and avoids confusion from outdated categories.
Original PR description
**Steps to reproduce:** - Create a new tag - Add it to a contact - Archieve the new tag - Groupo the contacts by tags - The archived tag is still present as a column of the group_by results **Issue:** When a user performs a group by on a view with `webReadGroup`, if a record of the field used for grouping is archived, it still appears in the search results. This is caused by the field used not being filtered by its `active` status. **Fix:** Add a custom domain filter for the field of the group_by which can be overwritten. The filter allow unset value for the field and restrict the rest to records with active = true. opw-5032604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar events created with booking lines now correctly retain the resources selected by users. This prevents appointments from appearing without their assigned resources after saving, improving scheduling accuracy.
Original PR description
**Steps to reproduce:** 1. Create or use a calendar event with a resource. 2. Now go to the calendar view of that event. 3. Click to make an appointment and go to More Options. 4. Add a booking line…
**Steps to reproduce:** 1. Create or use a calendar event with a resource. 2. Now go to the calendar view of that event. 3. Click to make an appointment and go to More Options. 4. Add a booking line and select a resource. 5. Save the event. **Issue:** When creating a calendar event with booking lines, the `resource_ids` field is not correctly populated. This is due to the fact that the compute method relying on `booking_line_ids` does not work at creation time, as the One2many lines have not yet been created in the database when the compute runs. As a result, events created this way appear without any linked resources, even though the user selected them through the booking lines. **Fix:** To avoid relying on the computed field during record creation, we explicitly extract `appointment_resource_id` values from the inline booking lines in the incoming `vals_list` and assign them directly to `resource_ids`. This ensures that resource information is preserved at creation time, without relying on deferred compute logic that cannot access the booking lines yet. opw-4565161
Fleet vehicle manufacturers now show counts based only on active models, preventing archived models from inflating totals. Users can also filter vehicle models to find archived records when needed, improving data clarity without changing core workflows.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#222353
The company switcher now correctly displays nested company structures when a user can access a parent and a deeper child company, even if an intermediate company is not accessible. This prevents users from missing companies they are allowed to use and keeps the hierarchy clear by showing unavailable intermediate companies as disabled.
Original PR description
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2…
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled. This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list. `companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3. ### Solution: A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies. Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed. opw-4880477
This fix prevents external report values from being changed once they fall within locked accounting periods. It helps preserve finalized tax report data, such as after a closing entry is posted, reducing the risk of inconsistent or unauthorized post-closing changes.
Original PR description
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock dates. For example when the closing entry from the tax report is posted, the user is not supposed to modify any external values anymore. This commit is kind of a backport for what has been done in 18.0, see odoo/enterprise#92949 Also it has to be NOT fw-port as it's a 17.0 version ONLY task-5012442