Wednesday, December 6, 2023
20 changes · 17.0
Resolved issues and error corrections
This fixes an issue where manually adjusted component quantities on a manufacturing order could be reset during validation. Businesses can now rely on validated manufacturing orders to keep the actual quantities entered by users, improving production accuracy and inventory tracking.
Original PR description
Steps to reproduce the bug: - Create a storable produce P1 with BoM: - select any component, qty: 1 unit - Create a MO to produce one unit of P1 - Confirm the MO - Update the qty of the component to 2 - Validate the MO Problem: The quantity of the component is overwritten and reset to 1 Because, when the new qty of the component is set, only the “manual_consumption” field is updated to “True” thanks to their compute: https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_move.py#L138-L145 But the field ‘picked’, is not updated So when we check if we have to set a quantity, the condition is false and the quantity is reset to the original value: https://github.com/odoo/odoo/blob/26193fdb707a631d498cbc37d68c08497e32a31d/addons/mrp/models/mrp_production.py#L1201-L1202 opw-3616628
Status buttons now display more consistently across Point of Sale, HR organization charts, and general forms. The “More” dropdown is better aligned, handles long labels more gracefully, and avoids overflowing on smaller screens, improving usability for translated and mobile interfaces.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/50256 The bar containing the status buttons in the control panel presents a few issues. Firstly, the status buttons don't all have the same…
Enterprise PR: https://github.com/odoo/enterprise/pull/50256 The bar containing the status buttons in the control panel presents a few issues. Firstly, the status buttons don't all have the same structure due to the way they're called (either via a field or a hard-coded button) which gives us visual differences such as a larger font-size. This issue is present in multiple status buttons across different modules, most of these have been fixed in PRs targetting `16.3` and the `milk` refactoring branch: (https://github.com/odoo/odoo/pull/121367 and https://github.com/odoo/enterprise/pull/41041) | Before | After | |--------|--------| |  | | Secondly, concerning the "More" dropdown, the alignment inside the button is off and the fixed width of the dropdown box can give a horizontal scroll if the contents are too long (e.g.: long translations) | Before | After | |--------|--------| |  |  | | Before | After | |--------|--------| |  |  | And finally, on smaller screens the buttons can overflow depending on the sizes of each button. Note that the fix in this PR is a temporary solution. | Before | After | |--------|--------| |  |  | task-3573807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error pop-up when removing an item from a Point of Sale order while using French localization. Staff can now remove items normally, improving checkout reliability and avoiding disruption during sales.
Original PR description
[FIX] point_of_sale : Removing orderline Steps to reproduce: 1- Install POS module and French Localization 2- Open a session in POS 3- Add an item to the order then remove it and set the quantity to 0 Current behavior before PR: When you try to remove an item from POS while using french localization it gives an error 'null exception'. This happens because we are trying to set the quantity to the order after unlinking the order line and setting the order with null. Desired behavior after PR is merged: The error pop-up is not there anymore and you can remove any item. Now we set the new quantity to the order before unlinking the order to avoid the null exception opw-3607956 
Fixes an issue where overlapping work schedule intervals could cause an error when opening Time Off. The duration is now calculated reliably even when work periods overlap, helping HR teams manage schedules without interruptions.
Original PR description
### Steps to reproduce: 1. install **Time Off** module 2. Go to the **Employees** app 3. In the menu above, go to **Configuration > Working** Schedules 4. Click on **Standard 40 hours/week** 5.…
### Steps to reproduce: 1. install **Time Off** module 2. Go to the **Employees** app 3. In the menu above, go to **Configuration > Working** Schedules 4. Click on **Standard 40 hours/week** 5. Delete **Monday Lunch** work interval 6. Change the **work from** property of the **Monday Afternoon** to **12:00** so it overlaps with the **Monday Morning** interval 7. Go to the **Time Off** app 8. An Error is raised! ### Investigation: - When two work intervals overlap they are being merged together https://github.com/odoo/odoo/blob/1229c13c12eedc71aa49dc14fa51059de01885d0/addons/resource/models/resource_calendar.py#L358 That corrupt the metadata of the newly created interval as each one has a different name, day period and more importantly id. - These intervals' metadata are then used to calculate the duration of each but as they are corrupted, an error arises https://github.com/odoo/odoo/blob/1229c13c12eedc71aa49dc14fa51059de01885d0/addons/resource/models/resource_calendar.py#L491 ### Solution: Following the same approach in version 16.4 by not extracting the `day_duration` from the metadata of the intervals when calculating the duration but rather interfering them. opw-3588805
This fixes an issue where content copied from the Odoo editor could disappear when pasted into an editor embedded in an iframe. Users working in embedded editing contexts can now paste copied HTML content reliably, reducing content loss and editing frustration.
Original PR description
Before this commit, pasting html content that had been copied from the the Editor failed to paste any content when inside an iframe. This happened because the DOMPurify library was not configured to use the iframe's window for Node prototypes, which led `instanceof` checks to fail, removing nodes a result. Additionally, commit [1] did not do the job completely: while the document for creating the document fragment became the one received as parameter, the DOMParser constructor remained the one from the window in which the JS code is executed, which might be different from the received document's window. This mismatch happens in particularly when the editable is inside an iframe. task-3575496 [1]: https://github.com/odoo/odoo/commit/c74d01279e49fadc5f509cfc3f6baf43d2b532d1
This fix makes mail-related record updates more reliable by ensuring related data changes happen in the correct order. It helps prevent inconsistent or incomplete information from appearing when records are added, deleted, or recalculated.
Original PR description
1. [REF] mail: field.onAdd/Delete & record.delete at end of update cycle 2. [FIX] mail: insert data in relational field 3. [FIX] mail: lazy fields not properly recomputed 4. [FIX] mail: invoke onAdd/onDelete hooks on inverse relational field
When managers resend feedback surveys from employee appraisals, the survey deadline will now be properly updated to reflect the new send date. Previously, the deadline remained unchanged even when the survey was resent, which could cause confusion about when responses were due.
Original PR description
Prior, when we resent the survey from appraisal, the deadline was not updated. This commit fixes the issue task - 3599707
This fix resolves an issue where confirming a subscription order with a zero billing period would cause the system to crash. The update ensures that billing period values are properly converted to valid date intervals, allowing orders to be confirmed successfully without errors.
Original PR description
The issue: Having a recurring plan with billing period set to 0, a traceback raised when you try to confirm the order The fix: converting the value to a valid datedelta object opw-3606819
This update fixes an issue where Mexican invoices could not be saved when using CFDI origin code '07'. The system was rejecting this valid code, preventing users from properly referencing related invoices. This fix adds support for code '07', allowing the invoice workflow to complete successfully.
Original PR description
### Steps to reproduce - Create and send an invoice (in order to get a CFDI number) - Create a new invoice and fill in the field CFDI Origin with `07|<CFDI number from invoice created above>` - attempt to save the invoice You should be met with an error. ### Cause The code '07' is not accounted for. opw-3618081
Fixed an issue where FedEx Regional Economy shipments were missing required customs information, causing shipment validation to fail with a "Customs Value is required" error. The system now properly includes customs details when using the Regional Economy service type, allowing international shipments (such as EU to UK) to be processed successfully.
Original PR description
Steps to reproduce: 1. set up FedEx shipping method, choose `REGIONAL_ECONOMY` service type 2. make a sale order from EU to UK, add FedEx shipping 3. confirm the sale order, validate the delivery Error: `2033: Customs Value is required.` FedEx requires customs info for `REGIONAL_ECONOMY` service type, so it should be included accordingly. opw-3527006 Forward-Port-Of: odoo/enterprise#51890 Forward-Port-Of: odoo/enterprise#50371
This fix corrects how appraisals are displayed when viewing a specific department in the Employee module. Previously, all department appraisals were shown regardless of which department was selected. Now, only appraisals for the selected department are displayed, ensuring accurate and relevant information for HR managers.
Original PR description
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Appraisals'. --- **Issue:** - When viewing the department's appraisal in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358 Forward-Port-Of: odoo/enterprise#49093
Fixed an issue in the Map View where technical status names were displayed instead of user-friendly labels when grouping tasks by status. Users will now see clear, readable status labels in the left-side panel, making it easier to organize and understand task groupings.
Original PR description
Steps: ------------ - Open Projects - Go to Tasks - Open Map View - Group By Status - In left-side panel ,the technical name of the state is displayed instead of its label Issue: ------------ - When using the selection field in map view, the technical name is being displayed instead of the label. Cause: ------------ - The issue arises because the code lacks proper handling for the "selection" field type. Fix: --------- - With this fix,the code now correctly handles "selection" fields and ensures that the label associated with the selected value is used for grouping records. task: 3552597 Forward-Port-Of: odoo/enterprise#49964
This fix resolves a system error that occurred when calculating whether a subscription invoice was overdue. The system was trying to compare dates without first checking if the next invoice date existed, causing crashes during upgrades. Now the system properly handles cases where the next invoice date is empty.
Original PR description
`next_invoice_date` field is not required field and was using on computation of `display_late` field and used
`order.next_invoice_date < today` without checking if order.next_invoice_date. so for some record
we found NULL value for next_invoice_date and will get traceback from that line during upgrade
```
File "/home/odoo/src/enterprise/17.0/sale_subscription/models/sale_order.py", line 502, in _compute_display_late
order.display_late = order.subscription_state in SUBSCRIPTION_PROGRESS_STATE and order.next_invoice_date < today
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```Fixed an issue where the UPS configuration tab was not appearing when setting up a new UPS shipping method. Users can now properly access and enter their UPS credentials and configuration settings. This fix updates the technical conditions used to display the configuration interface.
Original PR description
Steps to reproduce: 1. Install `delivery_ups_rest` module 2. Make a new shipping method 3. Choose "UPS" as provider The UPS configuration tab that allows user to enter their credentials and configuration will not show up. The problem is that the condition for `invisible` attribute is defined in the old way. (vid https://github.com/odoo/enterprise/pull/35255) opw-3618579
This fix resolves a system error that occurred when creating payslips with multiple "Other inputs" of the same type and attempting to compute the sheet. The issue was caused by incorrect dictionary access in the code, which has now been corrected to ensure payslip calculations work properly in all scenarios.
Original PR description
Steps to reproduce: ------------------- - create a payslip with multiple "Other inputs"; - click on the compute sheet button. Issue: ------ A traceback appears. Cause: ------ We're trying to access an item in a dictionary by a way that doesn't work. opw-3620353
This fix adds necessary safety controls to the POS Pricer module to prevent test database copies from interacting with external systems in ways that could impact production. This allows support teams to safely investigate issues on database duplicates without risking unintended changes to customer data or production systems.
Original PR description
This commit adds the missing neutralisation necessary for the `pos_pricer` module introduced in [1] The purpose of the standard neutralisation framework is to allow us to create database copies that will not interract with external systems in ways that could impact the production database (or if it is not possible to prevent the interractions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/enterprise/pull/50368
Fixed an issue where FedEx international shipments with insurance would fail when the sale order used a different currency than the company's default currency. The system now correctly uses the sale order's currency for insurance calculations, allowing shipments to process successfully without FedEx validation errors.
Original PR description
Steps to reproduce: 1. Set up FedEx International shipping method 2. Add insurance percentage (any number above zero) 3. Make a sale order for a customer in another country 3. Add a product and use a currency other than that of company currency 4. Validate the shipment FedEx error: ```All Currency Types in the Requested Shipment must match.``` To fix this, we need to use the currency used in the sale order instead of currency of the company. opw-3557669 Forward-Port-Of: odoo/enterprise#49564
This fix corrects an accounting imbalance in Finnish financial reports where two accounts (2250 and 2370) were missing from the Balance Sheet. By properly referencing these accounts, the Balance Sheet now correctly balances with Assets matching Liabilities and Equity, ensuring accurate financial reporting.
Original PR description
According to the Balance Sheet diagnosis tool in #36838, accounts 2250 and 2370 were not being referenced in the Balance Sheet, causing an imbalance between Assets and Liabilities/Equity. Referencing them solves the issue of the unbalanced Balance Sheet. The same issue is present in master and will be solved by this fix. taskid: 3060790 Forward-Port-Of: odoo/enterprise#51953
The Balance Sheet report for Serbia was showing unbalanced figures due to incorrect cross-references to the Profit and Loss report in the earnings sections. This fix corrects those references and removes unnecessary technical configurations, ensuring the Balance Sheet now accurately reflects financial data.
Original PR description
According to the Balance Sheet diagnosis tool in #36838, the Balance Sheet was unbalanced. On closer inspection, this was seen to be caused by an incorrect cross-report to the Profit and Loss in the Current Year Earnings and Retained Earnings sections. The same issue is present all the way to master. This commit fixes the cross-report references. We also take the opportunity to remove all the redundant `date_scope=normal` data. Since Balance Sheet reports work with a single (end) date, the normal date_scope works exactly the same as the strict_range date_scope, which is the default. taskid: 3060790 Forward-Port-Of: odoo/enterprise#51970
This fix resolves a crash that occurred when navigating between list views and other screens in the Studio editor. The issue happened when the system tried to check if a list could be edited in Studio at the same moment a new dialog was opening, causing it to reference incorrect data. The fix ensures the Studio editor feature only activates for appropriate list views and not for temporary dialogs, improving overall stability.
Original PR description
Before this commit, the clickAll tour crashed (https://runbot.odoo.com/runbot/build/54182109 (version 17.0 and after, but the fix is relevant before those versions) This was -- probably -- due to: - a list renderer is opened, the web_enterprise upsell studio feature listens on the actionService to determine if the current action can be editable with studio. - a client action is mounted - just before the list renderer stops listening (which happens at unmount time) the same function of the first list renderer triggers. - at this point the action that is evaluated is the one of the client action, which crashes because res_model is not defined on client actions definitions. The fix is relevant in 16.0 because it solves a case were a second act_window action, in target new, would spawn with a list renderer too, making the first one trigger its function without crash but in the wrong conditions. Forward-Port-Of: odoo/enterprise#52113 Forward-Port-Of: odoo/enterprise#51449