Daily updates from Odoo
Wednesday, October 16, 2024
40 changes
3 changes
Resolved issues and error corrections
When adding new content to an online course with multiple sections, the system now automatically selects the most recently created section if no section was chosen. This reduces extra clicks and helps course editors continue adding content in chronological order.
Original PR description
Purpose ======= When users are editing course content and created multiple sections they are most likely working "chronologically" adding content to sections one after the other. It seems the fix to preselect last section by default when many exist to populate new content is in regression. How to fix ========== Whenever a channel has sections and users has not selected one: make the last section as the default one. task-4109586 see odoo#132934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures invoice tax is calculated from the same rounded base amount shown as the tax-excluded total. It prevents small mismatches in tax totals, such as a one-cent difference, when global rounding is used with discounted invoice lines.
Original PR description
### Steps to reproduce the issue: 1. Make sure the Rounding Method is set to "Round Globally" 2. Have a Tax of 21% 3. Create a Product with sale price 5.75 and set the Sale Tax 4. Create an Invoice and add 6 lines with the Product 5. For each line, set the quantity to 5 and add an 18% discount 6. The Tax Amount is of 29.70 when the Total Tax Excluded is of 141.48 (141.48 * 21% ~= 29.71) ### Explanation: Since 17.2, the base amount of a tax is not rounded before the calculation of the tax amount, this creates an issue where the base amount and `amount_untaxed` are different when `tax_calculation_rounding_method` is set to 'round_globally'. (e.g.: 141.45 vs 141.48) ### Fix reasoning: `raw_price` is rounded out if `precision_rounding` is specified to avoid rounding to unit, it will replace all occurences of `price_unit * quantity` in the tax calculation. opw-4136024
The calendar library used by Odoo was updated to prevent a crash when viewing tasks with back-to-back scheduling. This improves reliability for users working with project and timesheet calendars, especially around dense task schedules.
Original PR description
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it anyway which leads to the intersection span being null which causes a traceback. I suspect that the fix is https://github.com/fullcalendar/fullcalendar/commit/362a37345a4b7cb65d16f345e8555f727f1c8450 However for good measure and to fix preemptively other bug from fullcalendar an update seems like the best decision. opw-3997810
2 changes
Resolved issues and error corrections
A new shop floor setting lets manufacturers control how many work order cards are shown at once. This helps teams keep the screen focused and easier to use when many manufacturing orders are active.
Original PR description
…e shop floor
This update fixes how the Master Production Schedule handles ordering limits and lead times across different planning periods. It helps avoid misleading replenishment quantities, such as applying a monthly cap to a yearly view, and improves demand forecasts for components with lead times.
Original PR description
This PR contains the following commits: - [IMP] mrp_mps: hide Order buttons in non-default periods When the date type shown (year, month, week, day) is different from the one defined in the settings, we hide the order buttons. - [FIX] mrp_mps: disable max_to_replenish_qty in non-default period `max_to_replenish_qty` should only be applied for the period defined in the settings. Otherwise we have situation where a limit of 15 per month is applied for a whole year. - [FIX] mrp_mps: use real dates with lead times When a bom has a lead time, we want to use the real date to compute the indirect demand forecast of the components in the MPS. task 4172967
27 changes
Resolved issues and error corrections
This fixes the invoice print template so VAT amounts show correctly in the totals section when invoices with standard tax are sent or printed. Businesses using GCC invoice localization will see accurate tax totals on customer-facing documents.
Original PR description
Create an Invoice with a standard tax Send&Print Issue: In totals section VAT amount will be wrong opw-4256242 opw-4256566
The Discuss onboarding tour is now included in the correct application assets instead of being limited to test-only files. This ensures users can see the intended onboarding guidance when using Discuss, improving first-time user orientation.
Original PR description
The discuss onboarding tour was missing because it was in the tests assets. It has been moved and change for the new system of onboarding tour. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes website editing behavior for SVG shapes and illustrations that still use older file paths after the content moved to a new location. Business users will see the correct editing options, such as Dynamic Colors, while unsupported actions like cropping illustrations remain blocked as intended.
Original PR description
In [1] shapes and illustrations were moved to `html_editor`. While some features have been adapted to the new path, others did not. No upgrade script was created to convert existing `/web_editor/shape/` paths to new `/html_editor/shape/` paths. Instead, the old route was kept available. However, some conditions, selectors and domains that recognized those paths have not been adapted to detect both kinds of paths. This commit adapts those conditions, selectors and domains so that both kinds of paths are identified as being shapes or illustrations. Steps to reproduce: - Add an SVG illustration in a website page - Select it => The "Dynamic Colors" options were not displayed [1]: https://github.com/odoo/odoo/commit/44129d85bdc993e37384536519a03d7c29ac7e83 task-4052712
The sales order confirmation warning now better explains what to do when an order was created before a warehouse existed. This helps users resolve the issue by assigning the warehouse to the order instead of repeatedly being told to create one.
Original PR description
### Steps to reproduce: - Create a new company - With this new company, create an SO for a storable product - Try to confirm the SO #### > A redirect warning is raised: "Please create a warehouse…
### Steps to reproduce: - Create a new company - With this new company, create an SO for a storable product - Try to confirm the SO #### > A redirect warning is raised: "Please create a warehouse ..." - Go to warehouses and create such a warehouse - Try to confirm the SO once more #### > The same warning is raised: "Please create a warehouse ..." ### Cause of the issue: The redirect warning that asks you to create a warehouse is raised when you try to confirm an SO wihtout a set "warehouse_id": https://github.com/odoo/odoo/blob/114b476755c37ae670f613200ffcc03377258873/addons/sale_stock/models/sale_order.py#L102-L113 https://github.com/odoo/odoo/blob/114b476755c37ae670f613200ffcc03377258873/addons/stock/models/stock_warehouse.py#L166-L172 Since you created the SO before the warehouse, the SO is curently not linked to any warehouse. Furthermove, when you created the warehouse, it did not update the 'warehouse_id' so that the exact same warning will be raised after the warehouse creation. opw-4250791 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website task creation form preview no longer crashes when opened directly without an existing task. This helps website editors test and configure forms more reliably.
Original PR description
Currently, an exception is generated when the user clicks on the preview URL of the "Create a Task" form by following the steps: - Go to any website page and open the website editor - Add form to website page - click on the added form and select Action as "Create a Task" - Click on the Preview URL button of the added form >> errro generated Error `KeyError: 'task'` This is because when the user opens the direct URL, no task is available. This commit will fix the above issue by accessing the key `task` when it is available in view. sentry-5983056185
This update prevents manufacturing report logic from accidentally mixing up an input value while processing operations. It helps keep bill of materials structure reporting consistent and reduces the chance of incorrect results in manufacturing views.
Original PR description
This commit makes sure `operation` parameter is not reused in the `for` loop. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where videos used as the cover media in website Card snippets could appear shifted or fail to fill the card correctly when a fixed ratio was applied. Website editors can now replace card cover images with videos and expect the layout to remain consistent.
Original PR description
In the "Card" snippet, if the cover image is replaced by a video, and if it has a ratio (i.e. the "Ratio" option is not set on "Image default"), the video is not placed correctly. This happens because the videos have a rule setting their position to `relative`, overriding the `absolute` position set and needed by the `ratio` class. This commit fixes that by setting the position of card cover videos as `absolute`, to be placed correctly according to the ratio. Steps to reproduce: - Drop a "Card" inner snippet. - Click on the cover image and replace it by a video. => The video is shifted and does not fill the wrapper properly. Related to task-3674888
This fix prevents Odoo from automatically opening a default form view in list screens unless the user is creating a new record or the action explicitly requests it. This avoids confusing navigation in certain list views while preserving the intended behavior for dedicated open-form buttons.
Original PR description
This commit tweaks the behavior of the openFormView function introduced in https://github.com/odoo/odoo/pull/176707 by making it fallback on the default form view only in create mode or when the caller explicitly wants it to (using the force parameter). This solves issues with some list views where we don't want to show the form view on click while keeping the spec intact in case of list's open_form_view button. Task-4164683
This fixes an ecommerce issue where choosing the same product in multiple combo options only added it once to the cart. Customers now get a separate cart line for each selected combo item, so orders better match what they selected and expect to receive.
Original PR description
When using combo products in ecommerce, if two of the combos contained the same product and they were selected, only one row with a quantity of 1 would be created. e.g. if a you had a double burger combo product and the combos looked like: - Burger 1: Cheeseburger, Double Cheeseburger, Chicken Burger - Burger 2: Cheeseburger, Double Cheeseburger Currently if you were to choose double cheeseburger in both options it would only add 1 burger with quantity of 1 to the basket. Ideally it should be following the same practise as sale orders and create a line per each item. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where scrolling an open Gantt popover out of view could trigger an error while it was closing. The change improves stability by ensuring the interface only repositions popovers when the required page elements are still available.
Original PR description
Since [1] have a gantt popover opened and then scroll the popover out: a traceback occur due to the onPositioned callback still called when the popover is being closed. Now usePosition will check if needed elements are connected before the positioning computation. [1]: https://github.com/odoo/enterprise/commit/ebeb633be737eb7bd614c2b474fafd65cd54f0ae
This update corrects a leftover internal reference in the hardware drivers used for customer-facing displays. It helps ensure connected display devices continue to launch and use the browser state correctly after a previous cleanup.
Original PR description
In #183565 the `chromium_additional_args` variable was removed, however a reference to it was missed in `DisplayDriver_L`. This PR fixes this reference by replacing it with `browser.state`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales orders that open tasks from the Tasks button now show the expected project navigation bar when all tasks belong to the same project. This restores easier navigation for users moving between a sales order, its project, and related tasks, while keeping the previous behavior when tasks span multiple projects.
Original PR description
Steps to reproduce: ------------------- 1. Install Project and Sales app 2. Create an SO which generates a project with tasks on confirmation 3. Confirm the SO 4. From the SO form view, click on the 'Tasks' stat button 5. The top bar is unavailable Fix: ------------------- In the action method, we check if all the tasks linked to the SO are in the same project. If so, we display the top bar by retrieving the right xml_id and passing the active_id of the project in the context. If not (more than one project), we fall back on the current behaviour. task-4239673 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users verifying Indian E-waybill credentials in production will now see a clear validation message when the username or password is incorrect. This prevents a confusing system error and makes it easier to correct setup issues during accounting configuration.
Original PR description
Before this PR, if the E-waybill credentials are wrong, the user gets a traceback in the production environment due to 61a85754800. Instead we introduce a `ValidationError`. Steps to reproduce: - Turn On (✓) "Production Environment" and "Indian Electronic Waybill" from accounting configuration settings. - Click "Verify Username and Password" in "Indian Electronic Waybill".
This fix restores lot and serial number information in Maintenance when Inventory is also installed. It avoids a dependency issue that could prevent the feature from working reliably in existing databases.
Original PR description
Commit [1] is using models and data from `stock` module but `maintenance` does not depend on this one. A bridge would not be a solution on stable, since existing DBs that have both `stock` and `maintenance` would just lose the feature (the bridge would not be auto-installed) [1] https://github.com/odoo-dev/odoo/commit/1f2a5806b832529bd2ec53a878991e04800079bf sentry-5964505411
This fix lets users select multiple cells in tables when editing HTML content in Firefox. It removes a browser-specific editing issue, making table editing more reliable for users who work in Firefox.
Original PR description
This is a forward port of [1] to html_editor Issue: ====== - We can't select multiple cells in a table Origin of the issue: ==================== - When selecting multiple rows or columns inside a table in firefox, firefox creates multiples ranges per table cell selected. Solution: ========= - The first time we encounter more than 1 range, we merge them together and we manually update the selection - After the manual upadte, firefox will not trigger selectionchange anymore when we move the mouse, to deal with that we just manually call `handleFirefoxSelection` in `mousemove` event. task-4240675 [1]: https://github.com/odoo/odoo/commit/541c8baa550f072530c3ab9b7d3a9c32e2e6f095
Customers who must log in before ordering event tickets will no longer lose their selected tickets after signing in. This prevents frustration and avoids forcing attendees to restart the booking process.
Original PR description
Steps to reproduce ==================== - Say logging is mandatory to order (website settings). - Log in as a visitor, pick some tickets, and fill in the attendee details. - Try to confirm. - You are redirected to the login page and then to the event. - Your tickets are lost and you need to start again. After this PR ================== The cart will be restored with the ticket picked up, after login. Task-4039974
This fix ensures users can save email templates when using the mass mailing composer. If the composer cannot be saved first, the system now stops and shows the normal validation guidance instead of continuing into a broken template creation flow.
Original PR description
In the new composer design [1] saving a template is done by first saving the composer, then opening the "template creation" view on the same composer. The second step thus requires the composer to be properly saved first. This is easily checked as `Record.save` returns false on failure. In that case we do nothing and let the framework point out why the record could not be saved. [1]: 6c4526ec3b9509e0a6b99503d8d888417b2695e0 task-4246399
Dashboard administrators are now automatically treated as internal users, preventing permission mismatches that could break dashboard-related tests or setup flows. This keeps administrator access consistent and avoids errors caused by dashboard admins being treated like portal users.
Original PR description
With this commit, all Dashboard Admins are also automatically internal users. Steps to reproduce: - install module spreadsheet_dashboard_edition - run test `.test_session_info_with_right` => the test fails because of a combinaision of two factors: - the user is granted the group `group_dashboard_manager` but he is not an internal user (which means he is a portal user) - `_inverse_calendar_res_users_settings` creates `res.users.settings` for portal users (will be fixed independently) and it crashes in the readonly transaction --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Web Studio onboarding tour now appears correctly for users. This helps new or returning users discover Studio features as intended, improving guidance without changing core business workflows.
Original PR description
The studio onboarding tour was missing because it was in the tests assets. It has been moved and change for the new system of onboarding tour.
The update fixes an internal Documents test so it handles users who already belong to another company. This helps keep access-rights checks reliable in multi-company setups without changing everyday user behavior.
Original PR description
This commit fixes the test. When there is extra company then test is failing because it replaces the companies in user, instead of adding the new company.
This fixes an internal issue that could incorrectly shorten sorting rules used in grouped views and reports. The change helps ensure accounting and document lists are ordered consistently when custom sorting logic is involved.
Original PR description
`_read_group_orderby` used `cr.mogrify`, `split(",")` and `split()[0]` for the
result coming from the `_order_to_sql` which may come from `_field_to_sql`
As a side effect, SQL code after a space/newline not adjacent to a comma will
be dropped after `split()[0]`. So the mogrified customized `_field_to_sql`
shouldn't have any space/newline not adjacent to a comma if the field is used
for `Model._order`.Posting tax closings for foreign VAT reports no longer changes the company tax lock date. This prevents unnecessary restrictions and exceptions when businesses still need to post activity for other jurisdictions.
Original PR description
Before this commit, posting any tax closing would always set the tax lock date. This was a bit restrictive, and required making lock date exceptions in order to post operations for other non-closed reports. We alleviate that by only setting the tax lock date when the domestic closing is posted ; the idea being it's the main one. So, tax closings posted for other countries for which a foreign VAT fiscal position is defined do not affect the tax lock date anymore.
This update corrects how withholding reference information is read in the Indian TDS/TCS reporting module. It helps ensure the report uses the right linked accounting records and avoids errors caused by incomplete field access.
Original PR description
With this PR, field `l10n_in_withholding_ref_move_id` will be accessed with `mapped` from the record set which was missing in the commit https://github.com/odoo/enterprise/commit/69e5817f5c72b75f3879801364ca78c83b522f83
The SEPA direct debit mandate report layout has been adjusted so it prints on a single page. This helps users generate cleaner, more professional documents without awkward page breaks.
Original PR description
Adapt the layout of the account sepa direct debit report to make it fit on a single page. task-4183056
This update prevents Odoo from creating duplicate Avalara tax records when taxes share the same visible name but have different jurisdiction codes. It reduces billing and tax calculation interruptions by aligning how taxes are matched with Odoo's uniqueness rules.
Original PR description
We recently reworked the way taxes are named [1]. It considered the description part of the "key" that uniquely identifies a tax. The description contains the jurisCode field returned by Avatax [2].…
We recently reworked the way taxes are named [1]. It considered the description part of the "key" that uniquely identifies a tax. The description contains the jurisCode field returned by Avatax [2]. This key is used to find an already existing tax, and creates it if it doesn't yet exist. _constrains_name() of account.tax however, doesn't consider the description field. This means that two taxes with the same name (e.g. CA STATE 6%) and different jurisdiction codes (e.g. 001 and 013) cause issues. The first one will be created as normal. When the second one is processed it will fail to find a match because the description is different, so Odoo will create a second one resulting in a constraint error. To resolve this, stop adding the jurisdiction code and stop looking at the description all together. In the end it's not critical information that needs to be in Odoo. For tax details the user already relies on the Avalara portal anyway. [1] https://github.com/odoo/enterprise/pull/68549 [2] State assigned code identifying the jurisdiction. Note that this is not necessarily a unique identifier of the jurisdiction.
Users who try to validate the same project document twice will now see a clear invalid operation message instead of an unexpected error. This prevents disruption and makes the issue easier to understand and resolve.
Original PR description
Steps to Reproduce: 1. Select a document 2. validate document 3. click on validate again 4. Traceback thrown Technical Reason: Instead of raising a UserError, it throws a ValueError when evaluating directly '_()' in the XML file without using the 'env' context. After this commit: An invalid operation dialog will open with the message 'Impossible to validate twice'. Task-4228827
Manufacturing users can now post work-in-progress accounting entries even when a work order has been started but not yet given an end time. This avoids an unexpected error and helps keep manufacturing accounting actions from being interrupted.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario
8 changes
Resolved issues and error corrections
This fix improves the robustness of the Spanish Profit and Loss report by using stricter date range calculations. Previously, if an account was incorrectly configured with the wrong type, the report could display incorrect historical balances. The fix ensures the report handles such misconfigurations more gracefully without requiring immediate account corrections.
Original PR description
Before this fix, when a P&L account was wrongly configured with a Balance Sheet type, the 'normal' date_scope set on the P&L expressions made it so that the balance of this account was computed on the whole accounting history. Of course, the most proper fix in that case is to fix the account type, but using strict_range as the date_scope will just make the report a little more robust. This is a partial backport of what was done in https://github.com/odoo/enterprise/commit/6e607e662dd2ae3ee5e3616bded11b62332ac2f9 for 18.0 Forward-Port-Of: odoo/enterprise#71578
This update fixes three critical issues in the bank reconciliation report: system crashes from division errors, incorrect display of partially reconciled amounts, and duplicate entries appearing in the report. The fix improves the underlying logic for how the report calculates and displays bank reconciliation data, ensuring users see accurate and complete information without errors.
Original PR description
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always…
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All 3 issues can happen due to the way the entries in the report are generated: Consider a single bank statement (line) / its associated "bank move". To generate the line the report we join the bank statement line and bank move to each line of the bank move (except the liquidity line). The report groups by move line id. This generates 1 row in the report per move line (except the liquidity line) of the bank move. This directly causes issue (3). It also causes issue (2) due to the following: The reason we join all the move lines in the first place is to compute the unreconciled amount of the bank move. (By summing amounts on the move lines). But when generating a single row of the report we only have the information about 1 line (due to the grouping by id) and not the whole sum. Thus we do not have the full residual information. opw-4178134 (Issue 1) community PR: https://github.com/odoo/odoo/pull/182589
This update resolves an error that occurred when users tried to filter subscriptions by customer or salesperson in the subscription dashboard. The fix corrects the underlying field references used for filtering, allowing users to successfully apply these filters without encountering system errors.
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204This fix improves the responsiveness of shared spreadsheets by processing updates immediately instead of waiting for server confirmation through the websocket. Users will now see their changes reflected faster, and the system is more reliable if the connection drops while they're the only person editing the spreadsheet.
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#71782
This fix corrects how shift end times are calculated when employees have working calendars with breaks. Previously, the system would simply add the shift duration to the start time without accounting for lunch breaks or other non-working intervals, resulting in incorrect end times. Now the scheduling system properly considers the employee's working calendar and break times when calculating shift durations.
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#63002
This fix resolves a critical error that occurs when processing invoices in the Point of Sale system for Chilean businesses. The system was looking for an outdated field name, causing the invoice payment process to fail. The fix updates the code to use the correct field name, allowing invoices to be processed smoothly.
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528
Fixed an issue in the Argentine VAT report that was causing the system to slow down or crash when displaying large numbers of records (over 6,000 lines). The fix limits the number of records shown in the web interface while still allowing the full dataset to be exported to Excel or PDF files.
Original PR description
ticket 80761
This update resolves a memory error that occurred when processing large numbers of accounting transactions (170,000+) in Indian localization. The system was trying to load all transaction data into memory at once. The fix optimizes how the system processes these transactions by only loading the relevant Indian records, preventing system crashes during updates.
Original PR description
After applying l10n_uk patch, the l10n_in_transaction_type field is set to compute in a customer database with approximately 170,000 moves. For each move, we need to check if move.country_code ==…
After applying l10n_uk patch, the l10n_in_transaction_type field is set to compute in a customer database with approximately 170,000 moves. For each move, we need to check if move.country_code == "IN". To optimize performance and prevent memory errors, we should fetch only the records where the country code is 'IN' and avoid loading unnecessary data.
[l10n_uk](https://github.com/odoo/odoo/pull/181154/commits/3b1fef4bbb667fb747e1272db7852f1f27263b0e)
```python
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 514, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/17.0/addons/l10n_uk/migrations/1.1/end-migrate.py", line 7, in migrate
env['account.chart.template'].try_loading('uk', company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 153, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/enterprise/17.0/l10n_ae_corporate_tax_report/models/template_ae.py", line 9, in _load
super()._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 213, in _load
self._load_translations(companies=company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 1326, in _load_translations
translation_importer.save(overwrite=False)
File "/home/odoo/src/odoo/17.0/odoo/tools/translate.py", line 1446, in save
env.flush_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 721, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 717, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6929, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1367, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1340, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4893, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/l10n_in_reports/models/account_move.py", line 23, in _compute_l10n_in_transaction_type
if move.country_code == "IN":
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4893, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6649, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2907, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3795, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3845, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3955, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1113, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
opw-4161124
upg-2056124
```