Daily updates from Odoo
Tuesday, September 23, 2025
28 changes · 17.0
Resolved issues and error corrections
Contacts in the Dominican Republic can now use valid 11-digit Cedula VAT identifiers, not only 9-digit RNC numbers. This prevents valid customer or company records from being incorrectly rejected during VAT checks.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Sign reminder process no longer fails when a document is sent without a “Valid Until” date. This keeps scheduled reminder emails running reliably and avoids error logs for affected signing requests.
Original PR description
Currently below error occurs when cron "Sign: Send mail reminder" is executed.
Error: `TypeError("'<' not supported between instances of 'bool' and
'datetime.date'") while evaluating 'model._cron_reminder()'`
### Steps to reproduce :-
- Open 'Sign' >> Go to 'Templates' >> Click 'Send' on a template.
- Set 'Valid Until' field as empty and 1 as the 'Reminder' >> click 'Send'.
- Run 'Schedule Action' (cron) **Sign: Send mail reminder** ( make sure it has
been 2/3 days since last reminder or change the date to 2/3 days from today.
- The error appears in the log.
This commit solves the above issue by making sure that `validity` is passed.
sentry-6168813276This fix prevents manufacturing work order planning from failing when no start date is available. If the start date is missing, the system now uses today’s date as a fallback, helping production scheduling continue without interruption.
Original PR description
The issue occurs when the system tries to convert different types of date or date objects into proper python datetime.datetime object but 'date_start' is False in vals at [1]. It might be write when…
The issue occurs when the system tries to convert different types of date or date objects into proper python datetime.datetime object but 'date_start' is False in vals at [1]. It might be write when `_plan_workorders` is executed and mrp workorder has not 'leave_id' [2]. The issue occurs when the system attempts to convert various date or date-related objects into a valid Python datetime.datetime object. However, at [1], 'date_start' in 'vals' is False [1]. This may be write when the '_plan_workorders' method is executed and the mrp workorder does not have a 'leave_id' [2]. Link [1]: https://github.com/odoo/odoo/blob/a848c3854c94b5c2b752edddbcf49337acf9d6ea/addons/mrp/models/mrp_production.py#L875 Link [2]: https://github.com/odoo/odoo/blob/a848c3854c94b5c2b752edddbcf49337acf9d6ea/addons/mrp/models/mrp_production.py#L1533-L1536 To resolve this, provide a default date as today if start date is not available Sentry-6255515427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error in the accounting reconciliation wizard when journal items are not available to identify a company. The system now uses the current company as a safe fallback, helping users continue reconciliation without interruption.
Original PR description
The issue occurs when the system attempts to get a 'company_id' from the move line in the account reconciliation wizard, but the move lines are not available at [1]. Link [1]: https://github.com/odoo/enterprise/blob/0b8820aadfcdfaff4df4bbd26c161951fa95b67d/account_accountant/wizard/account_reconcile_wizard.py#L122 To resolve this, Provide a current company_id as default value if move lines are not available in the account reconciliation wizard. Sentry-6237590490
This fixes an issue where Accounting reports could crash if a report expression used an invalid subformula with the Aggregate Other Formulas engine. Instead of showing an error, the report now handles the invalid setup safely, improving reliability for users opening financial reports.
Original PR description
Currently, a traceback is occurring when the user tries to open a The report contains a subformula in the report expression that does not match. To reproduce this issue: 1) Install `Accounting` 2)…
Currently, a traceback is occurring when the user tries to open a The report contains a subformula in the report expression that does not match. To reproduce this issue: 1) Install `Accounting` 2) Open the `Profit & Losses` report and open any `line` 3) Add the subformula as `sum` for any `report expression` 4) Make sure the `Computation Engine` for expression as `Aggregate Other Formulas` 5) Now open the above report from the `Accounting Reporting` Error:- ``` AttributeError: 'NoneType' object has no attribute 'groupdict' ``` This error occurs when the user gives a subformula to the engine type `Aggregate Other Formulas`. Because it tries to match and group the subformula as `currency_1`, `amount_1`, `criterium`. To do this we need a valid subformula. https://github.com/odoo/enterprise/blob/0611a56074616bd935b0a9e5e7db98b23d8184f0/account_reports/models/account_report.py#L3007-L3013 When the user gives an invalid subformula, the regex results as None. which leads to the above traceback. We can resolve this issue by returning unbound_value if the regex is None. sentry-6325843987
The Product Routes Report now handles manufacturing routes that do not have a source location set. This prevents users from seeing an error when opening the route diagram for products configured for manufacturing.
Original PR description
This error occurs when users view the Product Routes Report. Steps to Reproduce: - Install the `mrp` modules. - Open `Products`. - In the Inventory tab, enable `Manufacture` in Routes. - Clear the `Production Location` field. - Click View `Diagram` in Routes. ValueError: False is not in list This error occurs because, in `Warehouse > Routes`, when a rule is created with the Manufacture action, the Source Location field is not required. However, when generating the Product Routes Report, the system attempts to access this field even if it is empty, resulting in an error. This commit ensures the Product Routes Report view correctly Sentry-6487434464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Studio now shows a clear user-facing error when someone duplicates a report that points to a template that does not exist. This prevents an unclear system crash and helps users understand what needs to be corrected in the report setup.
Original PR description
This error occurs when a user duplicates the report using Studio. Steps to Reproduce: - Install the `web_studio` and `hr` modules. - Go to `Reporting > Reports`. - Click New, set the Model Name to hr.employee, and enter a non-existent template name like hr.demo in the Template Name field. - Go back and click the Studio icon. - Navigate to Employees > Reports, duplicate the newly created report. `ValueError: Expected singleton: ir.ui.view()` This error occurs because the user attempts to duplicate a report in Studio that references a non-existent template. This commit ensures that if a user duplicates a report with a non-existent template name, a UserError is raised. Sentry-6528691775
Website domain settings are now checked before they are saved, preventing invalid entries with spaces or overly long domain parts. This avoids errors when visitors or search engines access site files such as robots.txt and gives users a clear message to correct the domain.
Original PR description
The system did not previously validate the `website_domain` field, which could result in domains with invalid formats (e.g., containing spaces or exceeding the maximum acceptable length). The error is generated when the user sets the long domain and tries to access `/robot.txt`. **Steps to Produce:-** 1. Go to **Website's setting > set too long Domain > Save**. 2. Remove all after the first `/` from the URL and add **robots.txt**. **Error:-** `QWebException: Error while render the template` `UnicodeError: label too long` **Solution:-** - Added a constraint on the website_domain field. - The domain must: - Not contain any spaces. - Not exceed 71 characters. - Labels of domain should not exceed 63 characters. - A ValidationError is raised with a descriptive message if any of these conditions are violated. **sentry-6613845697** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kenyan eTIMS submissions no longer fail when a vendor bill includes an invoice line without tax. This prevents an error during submission and lets users continue processing valid vendor bills even when tax details are absent.
Original PR description
Currently, an error occurs when clicking the "Send to eTIMS" button on vendor bills. Steps to Reproduce: - Install the l10n_ke_edi_oscu module without demo data. - Create a new company with Kenya as the country and switch to it. - Go to Vendors > Bills, create a new bill, and add an invoice line without tax. - Confirm it, then click Send to eTIMS. StopIteration This error occurs because when the user removed the tax from the invoice line and clicked 'Send to eTIMS', the tax details got empty at [1]. As a result, no tax line is found using next(), which raises a StopIteration error. [1] https://github.com/odoo/enterprise/blob/e9cd1fa8c11d5d9a3dce7a8027a9ac9e19f44190/l10n_ke_edi_oscu/models/account_move.py#L234 This commit ensures that if there are no tax details present in the invoice line, the calculation of line_values is skipped for that case. sentry-6641334969
Swiss payroll now guides users to enter employee names in the expected first-name-then-last-name format. This also fixes the way legal first and last names are derived, helping SwissDEC payroll reports use the correct personal details.
Original PR description
* Add placeholder text to employee name field with Swiss cultural examples: "e.g. Roger Federer, Jean-Luc Godard, Johannna Spyri, ..." * Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851
This fix ensures timesheet reports correctly include related helpdesk ticket information when applicable. It resolves a prior report update that did not properly target the existing report section, helping users see the expected ticket context in exported or printed timesheet reports.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if.
The system now handles incorrectly written filter rules on relational fields more gracefully. Instead of showing a technical crash, users receive a clear validation message so they can correct the field setup.
Original PR description
Currently an error occurs when a syntactically invalid domain is added to any relational field. Steps to replicate: - Go to `Settings > technical > Fields` and click on New. - Make the field type as…
Currently an error occurs when a syntactically invalid domain is added to any relational field.
Steps to replicate:
- Go to `Settings > technical > Fields` and click on New.
- Make the field type as `Many2one` (any relational type would work).
- Add the domain as `[('x_isLaundy), '=', True)]`, which has a syntax error.
- Add other required fields and save.
Error:
`SyntaxError: unterminated string literal (detected at line 1) (, line 1)`
This error was caused by a `SyntaxError` raised during `safe_eval()` [1] evaluation of a malformed domain. Since the exception wasn't handled properly, it resulted in a traceback.
This commit resolves the issue by catching the `SyntaxError` raised during domain evaluation and converting it into a user-friendly `ValidationError`, preventing unhandled tracebacks.
[1] - https://github.com/odoo/odoo/blob/a3e9b4de2714bd0cc7831e924a0cce490f5da39e/odoo/addons/base/models/ir_model.py#L633-L636
sentry-6676988276
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCSV imports with missing columns or incorrect separators now show a clear validation error instead of failing unexpectedly. This helps users identify and fix formatting problems in their files, especially for large imports that may skip preview checks.
Original PR description
This error occurs when importing a CSV file containing rows with missing columns or incorrect separators. Large files may bypass preview checks, leading to failures during the actual import. **Steps to replicate:** * Settings>User & Companies>Users >Gear icon>Import Records * Import the [csv file](https://drive.google.com/file/d/1rkYjuiS_8ZO94lBwt_DvPbuRDr36xW1N/view?usp=sharing). * Set role field > title > Import `IndexError: list index out of range` **Solution:** * Catch `IndexError` during row processing and raise a `ImportValidationError` to handle rows with missing or misaligned columns. **Sentry-5588088802**
Creating a new website page with a title that looks like a filename, such as demo.xml, no longer triggers an error. This improves reliability for website editors and prevents a failed page creation flow when using common title formats.
Original PR description
Currently, an error occurs when creating a new page on the website. Steps to Reproduce: - Install the `website` module. - Go to `Pages` on website. - Click `New` and choose any template except Blank.…
Currently, an error occurs when creating a new page on the website. Steps to Reproduce: - Install the `website` module. - Go to `Pages` on website. - Click `New` and choose any template except Blank. - Enter demo.xml as the page title and click Create. `IndexError: list index out of range` This error occurs when creating a new page and the title includes a file extension. The _guess_mimetype function [1] uses the extension to determine and return the related template name. In [2], if the template does not contain a 'div' with id="wrap", the XPath query returns an empty list. When it tries to access the first element of this empty list, it raises an error. [1] https://github.com/odoo/odoo/blob/8ddc065c5d75750d8fe0736c2232888a543424fd/addons/website/controllers/main.py#L640 [2] https://github.com/odoo/odoo/blob/8ddc065c5d75750d8fe0736c2232888a543424fd/addons/website/models/website.py#L881 This commit ensures that it accesses the first XPath only if there is an element present in the list. sentry-6696313055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading an OFX bank statement with malformed date values now shows a clear validation error instead of causing an unexpected import failure. This helps accounting users understand that the file content is invalid and prevents a confusing system error during bank statement import.
Original PR description
This error occurs when an uploaded OFX statement file contains malformed date values. For example, the date string `89310133` is interpreted as `8931-01-33` in the `YYYYMMDD` format — but since day 33 is invalid, it causes an error. **Steps to replicate:** * Install `accountant` module with demo data * Accounting Dashboard> Bank>Dropdown>Import [File](https://drive.google.com/file/d/1qWd2mrf1Vh5ZgvDmng-dioNe1xwdfi7y/view?usp=sharing) `OfxParserException:unconverted data remains: 3` **Solution:** * Raise a `ValidationError` when an invalid date is encountered in the file. **Sentry-6715864025**
This fixes an issue that could cause a server error while handling responses from the Nilvera e-invoicing service in Turkey. Users should now receive the intended error message instead of an unexpected technical failure.
Original PR description
The http response object doesn't have a `code` attribute, this commit fixes this typo which has already been fixed in 19.0 as a part of #222869 task-5050516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Membership invoices now open with the right sales invoice context, so membership products remain searchable on invoice lines even if they are not marked as purchasable. This prevents confusion when editing draft membership invoices and helps users complete invoicing without changing product 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-5028789The website shop price range filter now uses corrected close-match search terms when calculating available price limits. This prevents shoppers from losing the ability to filter by price after a near-miss search, improving product discovery and checkout flow.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545This fix prevents appointment slot refreshes from failing when no specific resource is selected. It helps users continue booking appointments smoothly by safely handling missing or empty resource selections before calculating available capacity.
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
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