Daily updates from Odoo
Tuesday, September 23, 2025
263 changes
10 changes
Resolved issues and error corrections
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
10 changes
Resolved issues and error corrections
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
4 changes
Resolved issues and error corrections
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
14 changes
Resolved issues and error corrections
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
20 changes
Resolved issues and error corrections
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
5 changes
Resolved issues and error corrections
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