Daily updates from Odoo
Thursday, October 30, 2025
28 changes · saas-18.4
Resolved issues and error corrections
Opening the duplicate transaction view without a linked journal no longer causes an error. This prevents an accounting setup or administration screen from crashing in this edge case, improving reliability for users managing bank synchronization data.
Original PR description
When user opens the ``account.duplicate.transaction.wizard.form`` view, a traceback appears.
Steps to reproduce the error:
- Install ``Accounting`` module
- Using Open View, Open ``account.duplicate.transaction.wizard.form`` view
Traceback:
```py
UndefinedFunction: operator does not exist: integer = boolean
LINE 5: WHERE st_line.journal_id = false
^
```
https://github.com/odoo/enterprise/blob/8146cfc7b47ba8536f0fa5208cc69685371b55b8/account_online_synchronization/models/account_journal.py#L278
When the view is opened, the ``_compute_provider_duplicate_ids`` method is triggered,
which calls ``_get_provider_duplicate_transactions`` method.
Since no journal is linked to the wizard, it will raise the traceback from the above line.
ref: 218e8a365b153a202d062152ff69234482bcccf2
sentry-6943450225
Forward-Port-Of: odoo/enterprise#97196This fix prevents users from disabling required Peppol electronic invoicing services, reducing the risk of compliance problems. It also corrects invoice format labels and improves access to print-related invoice actions so accounting workflows behave more reliably.
Original PR description
#### [FIX] account_peppol: disallow disabling services Currently it is possible to disallow any services in the configuration. This can lead to complicance issues; i.e. if someone disables "BIS…
#### [FIX] account_peppol: disallow disabling services Currently it is possible to disallow any services in the configuration. This can lead to complicance issues; i.e. if someone disables "BIS Billing 3.0". 1. Ensure Peppol is activated (test mode or production; not demo) 2. Settings -> Accounting -> PEPPOL Electronic Invoicing -> Configure Peppol Services 3. Any service can be disabled. This commit hides the button to open the service wizard. (Also in the wizard it is now not possible to disable services anymore.) #### [FIX] account: generation of print-related entries in cog menu Before this commit: The dynamic generation of the print related entries in the cog menu does not work correctly. Problem / Solutions: There is a check in the javascript that does not work as intended. Thus the entries are not added to the cog menu in all cases. The check was intended to only block it for "new" records (not saved yet); to avoid issues in case the move has no id yet. After this commit we just check the id directly. #### [FIX] account_edi_ubl_cii: missing parenthesis in invoice_edi_format Follow-up to commit 860c0974f9b541be63f4079ef52366f91c1994ce . There we improved the eInvoice format labels for clarity. But 2 label were formatted differently than the others. This commit fixes that. #### References task-4737164 Forward-Port-Of: odoo/odoo#233629 Forward-Port-Of: odoo/odoo#233382
Restoring a database no longer breaks when the built-in OAuth provider record has previously been deleted. This prevents avoidable restore failures and helps administrators recover or duplicate databases more reliably.
Original PR description
**Description of the issue/feature this PR addresses:** When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database. **Current behavior before PR:** You'll get this…
**Description of the issue/feature this PR addresses:**
When a user has deleted the Odoo Oauth provider, an error occurs when restoring the database.
**Current behavior before PR:**
You'll get this error:
```
odoo.service.db.restore_db(dbname, backup, copy, **extra_kwargs)
File "<decorator-gen-27>", line 2, in restore_db
File "/opt/ou/odoo/odoo/service/db.py", line 44, in if_db_mgt_enabled
return method(self, *args, **kwargs)
File "/opt/ou/odoo/odoo/service/db.py", line 360, in restore_db
env['ir.config_parameter'].init(force=True)
File "/opt/ou/odoo/addons/auth_oauth/models/ir_config_parameter.py", line 13, in init
oauth_oe = self.env.ref('auth_oauth.provider_openerp')
File "/opt/ou/odoo/odoo/api.py", line 611, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2059, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/opt/ou/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/opt/ou/odoo/odoo/addons/base/models/ir_model.py", line 2052, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: auth_oauth.provider_openerp
Error: External ID not found in the system: auth_oauth.provider_openerp
```
**Desired behavior after PR is merged:**
No error will occur
The afflicted versions are AFAIK, **16.0**, **17.0**, **18.0**, and **19.0**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233633This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
Original PR description
This commit is a follow-up of this commit [[1]]. The aim of this commit is improving the Finnish translations for the localization. no task id Co-authored-by: [sahak-fin](https://github.com/sahak-fin) <sahak@odoo.com> [1]: https://github.com/odoo/odoo/commit/d0017410646500928bf8fe08077f21569c1fa47e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233482 Forward-Port-Of: odoo/odoo#233042
This fixes an issue that prevented website editors from changing the main heading on the blog landing page. Businesses can now update the default blog title directly in the website editor, keeping public-facing content easier to customize.
Original PR description
*: html_builder, website Since [1] and [2] reverting it by mistake, the blog landing title was not editable anymore. Steps to reproduce: - Open /blog in the website editor. - Try to edit the "Our Latest Posts" heading. After this commit the heading becomes editable in the website editor. [1]: https://github.com/odoo/odoo/commit/ec49429d0d405948fcb93228e7350dfea585246f [2]: https://github.com/odoo/odoo/commit/f503f98915ab39efff80a5904494c879805bb057
The Chilean electronic invoicing flow now selects only one matching company when several share the same tax ID. This prevents processing errors for businesses with branches or duplicate company records using the same RUT.
Original PR description
Before this commit, if multiple companies shared the same RUT (VAT), for example companies with branches, searching a recipient could return more than one company record. This could lead to errors when accessing variables that expect a single record. To prevent this issue, the search is now limited to one company record. OPW-5128543 Forward-Port-Of: odoo/enterprise#98352
The attendance management filter for items needing approval now also shows records with no overtime. This helps managers review, edit, or approve all relevant attendance entries instead of missing some because they had zero overtime.
Original PR description
Currently attendances having 0 overtime are hidden by the filter "To approve", which is weird because managers might want to manually edit them, or approve them. task-5189190 Forward-Port-Of: odoo/odoo#232796
This fix restores Swedish POS blackbox validation so orders can be properly checked and synced under current POS flows. It also corrects receipt reprint tracking and organisation number formatting, helping Swedish businesses stay compliant and avoid failed order validation.
Original PR description
Before this commit, the Swedish blackbox was completely broken in 18.0 because the `push_single_order` function is no longer used. To fix this, the same approach as `pos_blackbox_be` was used, where the `preSyncAllOrders` function was overridden instead. In addition, the old receipt reprinting logic was no longer working, and so it now uses the `nb_print` field to keep track of the number of reprints. Finally, we also forward port a fix from 17.0 (ddbc1fc) to correct the format of the organisation number, which for some reason was not forward ported originally. task-5077448 Forward-Port-Of: odoo/enterprise#98179 Forward-Port-Of: odoo/enterprise#98139
This fix prevents an error when saving a changed cost on an expense category that uses vendor taxes from multiple companies. It helps users working in multi-company setups update expense categories without being blocked by company-specific tax settings.
Original PR description
Steps to reproduce: - Create 2 companies - Create a tax one each - Create an expense category - Set the 2 taxes as Vendor Taxes - Select only one of the companies - Change the cost of the expense category - Try saving --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232291
Deleting a signer role from a Sign template now works correctly even when that role has radio buttons on the template. This prevents an unexpected error and lets users clean up or adjust signing templates without interruption.
Original PR description
Before this commit, when deleting a Signer role that already had a radio button dropped in the Template, it would trigger a traceback since the were trying to delete radio buttons individually. This was problematic because radio buttons are deleted in chain, so when deleting the first, we already delete all the remaining radio buttons and its chain link. After this commit, no issue is raised anymore when deleting a signer role, as radio buttons already deleted are now skipped in the code. task-5130925 Forward-Port-Of: odoo/enterprise#96097
This fixes how product unit prices are shown in electronic invoices when tax-included pricing is used. It helps invoices pass Peppol validation by keeping calculated line totals consistent with the submitted subtotal.
Original PR description
At the moment, the UBL's Price/PriceAmount node is rounded to the same number of decimals as the database's product price precision. This causes a Peppol schematron validation error due to rule PEPPOL-EN16931-R120 in the case where the user uses tax-included prices. For example, if you have a tax-included unit price of 12.95, a quantity of 8 and a 21% tax, then the tax-excluded subtotal is 85.62. Divide 85.62 by 8 and you get a raw unit price of 10.7025. But if we round to 2 decimal places, we get 10.7 but `10.7 * 8 = 85.6 != 85.62`. Solution: We need to round the unit price to enough decimal places to ensure that unit price * quantity ~= line subtotal (with a tolerance of less than 0.02) opw-5072134 Forward-Port-Of: odoo/odoo#226869
Removing an image shape in the website editor now restores the image's original proportions when no manual crop was set. This prevents pictures from staying unintentionally cropped or distorted, making page editing more predictable for users.
Original PR description
Steps to reproduce: - Enter website edit mode. - Drag and drop a snippet containing an image onto the page. - Click the image. - Apply a shape that enforces a 1/1 ratio with stretch disabled (e.g the first one). - Remove the shape with the close button. Before this commit, removing the shape kept data-aspect-ratio at 1/1, so the picture stayed cropped or distorted. After this commit, removing the shape clears the crop dataset when no manual crop values exist, restoring the original proportions. task-5170195
Employee weekly working hours now show the selected schedule correctly when an employee's contract or occupation starts before the current employee version date. This prevents valid schedules, such as 24 hours per week, from incorrectly appearing as zero and improves related availability displays.
Original PR description
**Issue / current behavior:** When you create an employee with version date = today and set him an occupation starting in the past and then when we try to assign him a working schedule 24h/week it shows 0 working hours. **Required behavior:** It should display 24 working hours or whatever selected. **Solution:** Changed the field of available time of the week to contract_start_date from the version_start_date. task-4985887 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a test scenario for employee attendance planning when an employee is created today but their work assignment started in a previous month. It helps ensure weekly available hours are calculated reliably in attendance Gantt views.
Original PR description
Modified the test case to check the flow for when we create employee for the date = today and set him an occupation starting in the past month. task-4985887
This fix prevents an error when archiving an employee and entering a departure description. The change keeps the departure note visible in the employee record's chatter, helping HR teams retain the information without disrupting the archiving process.
Original PR description
Issue: The tracking is not implemented for the html field, so when we archive an employee the tracking cannot work. Purpose of this PR: The tracking has been removed from the html field. The tracking is now replaced by a message in the chatter in the write method. Steps to Reproduce on Runbot: install hr archive employee set a `departure description` Notes: originally fixed by #140527 reintroduced by #223342 opw-5137695
This fix prevents upgrade failures when a previously removed default admin employee record is not recreated correctly. It moves the payroll-related setup to the appropriate module so upgrades remain reliable without changing day-to-day HR workflows.
Original PR description
The data file adds `structure_type_id` field to `employee_admin` [because](https://github.com/odoo/odoo/pull/217855) it is required in module `hr_payroll`. The original record for `employee_admin` became `forcecreate=0` but the override (in the same file) still will try to create it with no data if the users have removed the record. This fix moves the override to the module where it is needed, with forcecreate=0. Issue encountered during upgrades --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where deliveries linked to split manufacturing orders could show only the quantity from the original order instead of the full ordered amount. The change ensures backorder manufacturing steps stay connected to the correct delivery movement, so sales deliveries reflect accurate quantities after production is completed.
Original PR description
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to…
Issue ----- After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity. Steps to reproduce ----- - Unarchive MTO route - Create a stored product - Routes MTO & Manufacturing - Empty BoM - Create a Sale Order for 3 units of the product & confirm it - Go to the linked MO and split it in 2 (quants of 1 and 2) - Confirm both MOs (and produce) - Go to the sale's delivery > The delivery's move only shows 1 unit of the product Why the move quantity is only 1 ----- After confirming the first of the 2 backorder productions, when we manufacture the product, we go through https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054 Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 Which creates a SML for the delivery move when reserving it https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858 https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971 This in turn triggers the computation of the move's quantity since it depends on the move's lines https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383 Our move ends up with a quantity of 1. When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091 This means we don't create a new SML for the delivery move, so the quantity stays at 1. Why there is no move_dest_id ----- When splitting the production, we go through https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829 We create new a MO and SM for the backorder. The SM is created here https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915 When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656 So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78 In the write, we get to a line where we access the production's state https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931 This triggers a recompute of the field. https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552 In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished` https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800 The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f). https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167 ----- Ticket: opw-4865082 Forward-Port-Of: odoo/odoo#233114 Forward-Port-Of: odoo/odoo#223792
Image galleries now refresh their small carousel thumbnails when an image is replaced or edited. This keeps the page preview consistent and avoids showing outdated pictures to website editors and visitors.
Original PR description
Steps to reproduce: - Drag and drop an "Image Gallery" snippet onto the page. - Set the indicators to "Squared Miniatures". - Replace an image using the media dialog. - Look at the carousel indicators. They didn’t update. - Same issue if you change any other image options (filter, etc.) Before this commit, the edited image was updated but the small thumbnails under the gallery still showed the old picture. After this commit, the gallery listens to media updates and the thumbnails now refresh to match the edited image. task-5189020
Employee profile pictures now appear consistently and properly aligned when viewed on mobile devices. This improves the employee form experience for users accessing HR records from phones or smaller screens.
Original PR description
The employee form view displayed misaligned or inconsistent avatar images on mobile screens. task-5058793
Point of Sale receipts now calculate total discounts correctly when an order uses both a discounted pricelist and combo products with free items. This prevents free combo items from being counted as extra discounts, making receipts clearer and more accurate for customers and staff.
Original PR description
Before this commit, if a pricelist with a discount was assigned to a PoS order, combo products that included free items would display an incorrect total discount on the receipt. The discount amount wrongly included the prices of the free products. Since combo price calculations follow a different logic, this commit ensures that pricelist discounts are excluded from the total discount computation for combo products to avoid confusion. opw-5046691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the spreadsheet component to the latest available version for this Odoo release. It also fixes an upgrade mapping issue so customers moving between intermediate versions have a more reliable spreadsheet experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e00f63d8d9 [REL] 18.4.15 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/94f784ff17 [FIX] upgrade: half-versions are missing in mapping [Task: 5116401](https://www.odoo.com/odoo/2328/tasks/5116401) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Fixes a crash in Italian Point of Sale that happened when a cashier deleted a product line after configuring an Italian fiscal printer. This improves checkout reliability for Italian retailers and prevents interrupted sales during normal cart edits.
Original PR description
Currently POS crashes with the Italian localization if they delete a product line. Steps to reproduce: ------------------- * Install l10n_it_pos and switch to the IT company * Create a pos and…
Currently POS crashes with the Italian localization if they delete a product line. Steps to reproduce: ------------------- * Install l10n_it_pos and switch to the IT company * Create a pos and configure Italian printer * Open shop * Add a product to cart * On the numpad try deleting the line > Observation, pos crashes Traceback: TypeError: Cannot read properties of undefined (reading 'tax_details') Why the fix: ------------ When first hitting the delete button we will put the price unit to 0. With that we have ``` const reduced_base_lines = Object.values(base_line_map).filter( (base_line) => !floatIsZero(base_line.price_unit, base_line.currency_id.decimal_places)); ``` returning an empty list. Utlimately making `reduce_base_lines_to_target_amount` return an empty list. `[][0]` returns `undefined` and we were passing `[undefined]` in parameters of `fix_base_lines_tax_details_on_manual_tax_amounts`, we enter the loop with undefined and try to access some variables. We also set `l10n_it_epson = False` in order to avoid recursively looping. opw-5184113 Forward-Port-Of: odoo/enterprise#98229
Calendar entries created across multiple days now show the correct start and end times in week view. This avoids misleading 12 PM or midnight labels on event segments, making schedules clearer for users.
Original PR description
When creating an event in week view spanning over multiple days, all parts of the event display 12pm as end date (except the last one) and 00am as the start date (except the first one). This fix allow calendar views to display the correct hour in week view when the event spans multiple days. task-4700158 Forward-Port-Of: odoo/odoo#233642 Forward-Port-Of: odoo/odoo#230624
Chilean electronic invoice imports now recognize numeric currency codes as well as standard currency abbreviations. This prevents import failures for vendor bills using numeric currency values and defaults safely to Chilean pesos when a currency cannot be matched.
Original PR description
### Steps to reproduce: - Install "l10n_cl_edi" and switch to a Chilean company - Go in Accounting > Vendor > Bills - Import an XML with the line `<Moneda>013</Moneda>` - Traceback ### Cause: `Moneda` can be the currency name code like `USD` but also a numeric code corresponding to the currency. ### Solution: Add a dictionary linking codes to the currency names and check the dictionary if `Moneda` is numeric. Also add a fallback on `CLP` in case the value of `Moneda` fails to be translated to a currency. This avoids a traceback later when reading `vals['currency_id']`. opw-5184950
Vendor bill imports for Ecuador now select purchase taxes instead of accidentally applying sales taxes from the same tax group. This helps ensure imported supplier bills have accurate tax treatment and reduces manual correction work for accounting teams.
Original PR description
### Issue:
When importing a bill, some sale taxes are added to the lines.
### Steps to reproduce:
- Install 'l10n_ec_edi' and switch to an Ecuadorian company
- Accounting > Vendor > Bill
- Import an XML fill with a tax of 15%
- The created lines use the tax "VAT 15% G" which is a sale tax
### Cause:
The search to get the tax takes the first one from the right tax group.
### Solution:
Added `('type_tax_use', '=', 'purchase')` in the search domain to only retrieve purchase taxes.
opw-5174139This fix keeps manufacturing work order time tracking entries intact when saved, especially when recorded time periods overlap. It aligns how duration is calculated and updated so users do not lose logged production time unexpectedly.
Original PR description
Issue: In this bug, workorder duration inverse is causing some time_ids to be deleted. To reproduce: 1- Create a db with mrp installed, and enable work orders in Setting 2- Create a MO, and confirm…
Issue:
In this bug, workorder duration inverse is causing some time_ids to be deleted.
To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
- First one 10:00 -> 12:00
- Second one 10:00 -> 11:00
5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked
Cause:
The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.
To be specific this is the compute function override:
https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766
In which duration is calculated using get_duration:
https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837
Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.
However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400
As a result, if time_ids overlap:
new_order_duration < old_order_duration
As a result some time_ids will be unlinked and some will have duration changed.
Fix:
Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```
As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899
The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.
In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.
opw-5082477
Forward-Port-Of: odoo/odoo#230328Fixes an issue where overlapping time tracking entries on manufacturing work orders could be removed or changed after saving. This keeps recorded work time consistent and prevents loss of production tracking details.
Original PR description
#### Issue: In this bug, workorder duration inverse is causing some time_ids to be deleted. To reproduce: 1- Create a db with mrp installed, and enable work orders in Setting 2- Create a MO, and…
#### Issue:
In this bug, workorder duration inverse is causing some time_ids to be deleted.
To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
- First one 10:00 -> 12:00
- Second one 10:00 -> 11:00
5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked
#### Cause:
The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.
To be specific this is the compute function override: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766
In which duration is calculated using get_duration: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837
Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.
However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals: https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400
As a result, if time_ids overlap:
new_order_duration < old_order_duration
As a result some time_ids will be unlinked and some will have duration changed.
#### Fix:
Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```
As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899
The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.
In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.
However, this might cause another issue:
If `order.duration` is not computed yet, and inverse method `_set_duration` is called, then `get_duration` inside `_set_duration` will be called before the `get_duration` in compute method. As a result there might be a small unexpected time difference between `old_order_duration` and `new_order_diuration`. To avoid that inside `get_working_duration` we can use cursor now instead:
```diff
+ now = self.env.cr.now()
- now = datetime.now()
```
opw-5082477
Forward-Port-Of: odoo/enterprise#96632Fixed an issue where running a test import with batching could cause the real import to start from the last tested batch instead of the beginning. This helps ensure all records in a CSV are imported as expected after a successful test run.
Original PR description
Steps to reproduce ================== - Go to contacts - Click on the cog menu > Import records - Upload a csv file - Limit the batch limit to a value lower than the total number of records in the csv file - Click on the test button - Click on the Import button => Only the last batch is imported Cause of the issue ================== The start line is not reset after the test import, which can be confusing Solution ======== When the test import fully succeeds, we reset the start line opw-4916102 Forward-Port-Of: odoo/odoo#232938 Forward-Port-Of: odoo/odoo#230805