Tuesday, April 7, 2026
31 changes · saas-19.1
Resolved issues and error corrections
This update resolves a technical issue that caused Odoo to crash when calculating annual leave days for newly created employees. The fix prevents the system from attempting direct database queries when a record is in its initial 'New' state, ensuring smoother operation and preventing errors.
Original PR description
This commit will add a guard condition to the `l10n_ae_annual_leave_days_total`'s compute method to skip SQL execution when the record has no database ID. Why: Users experienced a server-side traceback when opening Odoo Studio on the employee form and enabling the 'Annual Leave Days Total' field. The traceback occurred because the field's compute method attempted to execute a direct SQL query using `self.ids`. What: - Added a check for `self.ids` at the beginning of the compute method. - Ensured the field defaults to `0` or a neutral value if the record is still in the "New" state. task-5940225 Forward-Port-Of: odoo/enterprise#112867
This update resolves an issue where spreadsheet names weren't correctly reflected after renaming. By removing the outdated caching mechanism and using 'no-cache' headers, the system now always fetches the latest spreadsheet data, ensuring users always see the correct version.
Original PR description
This reverts commit 8f3e242e197b2f269827499b0d89b2e9080f5d09. Etag was computed from the spreadsheet content, but we forget to take spreadsheet metadata (like the name, ...) into account. So when user renames a spreadsheet, the browser still has the old version in cache and does not fetch the new name. This commit removes the ETag and use no-cache headers to ensure browsers always fetch the latest version of the spreadsheet data. Task: 5441251
This update corrects a calculation error within the Belgian HR contract salary module that was impacting the accurate determination of yearly cost sacrifice figures. The fix ensures that these figures are now calculated correctly, improving the reliability of financial reporting related to employee contracts. This change primarily affects payroll processing for Belgian entities.
This update resolves an issue preventing the launch of a Web Studio tour due to a problem with how the editor tracked changes. Additionally, a crash in the report processing system was fixed by using a more reliable architecture copy. This ensures the Web Studio functionality continues to operate smoothly.
Original PR description
These changes were made because the diff in https://github.com/odoo/odoo/pull/252844 caused a tour in *web_studio_test_ui_unit_report_tours.js* to fail Cause of issue: =============== For the tour, the powerbox wasn't opening because DOM changes weren't registered with the editor's state system. For *report.py*, after changes to the tour, the system tried loading from file using the backup key as an XML ID. Since backup keys contain dots https://github.com/odoo/enterprise/blob/7ca23bee6f84ccd0cd9c1cd747f434f3cc37861e/web_studio/controllers/report.py#L354 the XML ID parser crashed. Fix: ==== For the tour, registered the DOM mutation (span insertion in the other PR) with the editor's history, since the editor uses a MutationObserver that only processes changes it's aware of. For *report.py*, clearing arch_fs uses the already-copied architecture from arch_db instead.
This update fixes an issue where clicking links within charts directed users to the wrong view for data sources. Now, links correctly navigate users to the appropriate view type (e.g., a list view for a list datasource), improving the user experience and ensuring accurate data access.
Original PR description
Currently, if the user clicks on a datasource link (inside a chart) they will be directed to the default view of the action realted to the datasource model but it will not go to the corresponding type of view (e.g. a list datasource should direct to a list view). Task-5957004
This update resolves a technical issue that could cause errors when generating sales achievement reports, specifically when filtering by the current period. The fix ensures the system correctly handles date formatting, preventing a ValueError and ensuring reports run smoothly. This improves the reliability of sales reporting.
Original PR description
Before this commit, the following traceback could occurs when filtering the current period in achievements.
File "/home/arj/PycharmProjects/worktree/saas-19.1/enterprise/sale_commission/report/achievement_report.py", line 79, in _search
date_to_list = date_to_domain and [datetime.strptime(d[2], '%Y-%m-%d') for d in date_to_domain if len(d) == 3 and d[2]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 554, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 333, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data 'today' does not match format '%Y-%m-%d'This update resolves an issue where the system incorrectly identified late hours for employees without a recorded check-in time. The fix ensures that late hours visibility is only calculated when an employee has a valid check-in record, preventing errors and improving the accuracy of time tracking reporting.
Original PR description
_compute_l10n_sa_late_hours_visible, calling min() on the mapped check_in values and then .date() would crash with an AttributeError when check_in is False (e.g. during an onchange triggered by clearing the check_in field in the form view). Filter out records without a check_in before computing the date range, and mark them as not visible since late hours cannot apply without a check-in time. task-6067640
This update addresses an issue where the Master Production Schedule (MPS) wasn't correctly accounting for safety stock levels when calculating indirect demand. The fix ensures that safety stock is considered, leading to more accurate production forecasts and reduced stockouts. This improves the reliability of the MPS planning process.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838 Forward-Port-Of: odoo/enterprise#112811 Forward-Port-Of: odoo/enterprise#107671
This update fixes a misleading chart in the Purchase & Vendor Analysis dashboard. The chart title was previously inaccurate, suggesting supplier dependency instead of showing purchase orders by buyer. The title has been corrected to accurately reflect the data displayed, improving clarity and preventing user confusion.
Original PR description
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it…
Issue Before This Commit: ====================== Currently, the pie chart titled `Supplier Dependency Chart` in the Purchase & Vendor Analysis under the Logistics section is misleading because it suggests that the chart represents dependency on each supplier. However, the chart actually shows how many purchase orders are created by each buyer. Additionally, when there are no purchase orders, the sample pie chart displayed uses the title `Purchase Order by Buyer`, which creates inconsistency between the actual chart title and the sample chart title. Steps to Reproduce: ================= - Install the **purchase_stock** module with demo data. - Go to the **Dashboard** app. - Open the **Purchase & Vendor Analysis under the Logistics** section. - Scroll down to locate the pie chart titled **Supplier Dependency Chart**. Cause of the Issue: ================ In this [PR](https://github.com/odoo/enterprise/pull/93921), at [this line](https://github.com/odoo/enterprise/pull/93921/changes#diff-61d19b77200011a8808542c134a675631e6d4b4dbc88ca99353cacfe3448b396), The pie chart title was incorrectly set to `Supplier Dependency Chart`, which does not reflect the underlying data, as the chart displays purchase orders grouped by buyer. After This Commit: ================ The pie chart title is corrected from `Supplier Dependency Chart` to `Purchase Order by Buyer`, ensuring it accurately repersent the underlying data and avoids misleading users. TaskID-5891759 Forward-Port-Of: odoo/enterprise#110434
This update fixes a minor issue with the TDS/TCS report amounts in the Odoo accounting module for Russia (l10n_in). The automatic +/- sign handling was previously removed, and this change ensures the correct positive or negative sign is displayed for these report amounts, aligning with current tax regulations. This ensures accurate reporting for tax compliance.
Original PR description
In https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b, the automatic +/- sign handling was removed from the tax grid logic. To stay consistent with this change, the newly added TDS Report 2025 has been updated accordingly. task-6097997 Forward-Port-Of: odoo/odoo#257775
This update ensures that only invoices can be grouped within the account_edi_ubl_cii module. Previously, grouping was allowed for various document types, which could lead to inconsistencies. This change improves data accuracy and compliance by limiting grouping to invoices, the intended use case.
Original PR description
[FIX] account_edi_ubl_cii: Allow only invoices can be grouped Before this commit, no check was done on the document type at line grouping. This commit adds the check `is_invoice` so that we cannot group (e.g.) a journal entry type move no-task Forward-Port-Of: odoo/odoo#257314 Forward-Port-Of: odoo/odoo#255359
This update fixes a bug in how leave dates are calculated for employees, ensuring accurate scheduling across the system. Previously, the system missed potential leave windows if the initial search started too early. The change improves the reliability of leave scheduling and prevents employees from being incorrectly excluded from their approved leave periods.
Original PR description
Before this commit, in `_get_first_working_interval_batch` the `collect_employees` helper only inspected the first item of each employee's work interval. The batch calendar query starts from the global `min_dt` which is the earliest leave end across all employees in the batch. For an employee whose leave ends later, the first returned interval can therefore still fall before that employee's own threshold (`min_dts[employee_id]`). The old code would discard that interval and, since it never examined subsequent ones, silently skip the employee with no result. This commit fixes the issue by replacing the single-item check with a loop that iterates over all of the employee's intervals and picks the first start time strictly after `min_dts[employee_id]`.
This update fixes an issue where carrier tracking information wasn't consistently passed through multi-step delivery processes. The change ensures that tracking references are automatically propagated to subsequent pickings, even without a specific carrier assigned, improving shipment visibility and traceability. This enhancement simplifies tracking and reporting for our users.
Original PR description
Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Go to Warehouse Management → Operation Types
- Set Delivery to 3 steps
- Open the 3-step delivery routes and enable “Propagate carrier” on any rule
- Create a storable product P1
- Create a sales order with 1 unit of P1
- Confirm the sales order
- Open the generated picking
- Go to the Additional Info tab
- Set Tracking Reference = 123
- Confirm the picking
- Open the next picking (Pack operation)
Problem:
The tracking reference is not propagated to the next picking, even though the rule has “Propagate carrier” enabled.
Expected behavior:
The tracking reference should be propagated to the subsequent picking when carrier propagation is enabled on the rule. Even if no carrier set.
opw-6052930
Forward-Port-Of: odoo/odoo#256851This update resolves an issue where a company's Tax ID wasn't correctly displayed in documents. The fix ensures that the Tax ID entered in the document layout settings is now accurately shown, improving data visibility for accounting reports. This was caused by a previous code change and has been corrected.
Original PR description
### Steps to reproduce: - Download Accounting app - Open 'Settings' > 'Companies' > 'Document Layout' > 'Configure Document Layout' - Enter a 'Tax ID' and click continue > 'Tax ID' doesn't show in the document ### Cause of issue: The problem was introduced by https://github.com/odoo-dev/odoo/commit/fa55c2d1ca5db203ffaa13e10e4e4209717b7a6d, as the commited changes don't use the `company.vat` set by the user to be displayed in the documents. ### Fix: Since the `forced_vat` is only used in a few localizations, it is logical to check if the `company.vat` available for usage if there's no `forced_vat`. opw-5981630
This update resolves a bug where the bold formatting action wasn't consistently removing bolding when a `/file` component was present in the selected text. The fix ensures that bolding is correctly applied or removed based on editable text nodes, improving the reliability of the formatting tool. This prevents unexpected bolding behavior.
Original PR description
When determining whether the "bold" action is about adding bold or removing bold, non-editable text nodes are also taken into account. Because of this, if the selection contains an embedded component such as `/file`, it always considers bold was not applied on all nodes, and should therefore be applied. The action thus never removes bold. This commit fixes this by only taking into account the editable nodes. Steps to reproduce: - Go to a "To do" note - Add a few lines of text - Add a `/file` in the middle - Select all - Press Ctrl+B: bold is applied on the surrounding text - Press Ctrl+B again => Bold was not removed from the surrounding text task-5955977 Forward-Port-Of: odoo/odoo#257327 Forward-Port-Of: odoo/odoo#249816
This update fixes a bug where expected hours weren't consistently calculated for attendance records, particularly with overtime. Now, the system correctly updates expected hours after overtime is added, ensuring accurate reporting and time tracking. This resolves discrepancies in reporting views like the Attendance Pivot.
Original PR description
The expected_hours field was not always being computed for attendances. self.add_to_compute is used here to ensure that it is always recomputed. 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 Forward-Port-Of: odoo/odoo#251989
This update resolves an error that occurred when a purchase order line's promised date was removed. Previously, the system would fail to calculate on-time delivery rates. The fix ensures that the comparison between dates only happens when a promised date is actually set, preventing the error and maintaining accurate reporting.
Original PR description
Currently, an error occurs when the user removes the promised date on a purchase order line. **Steps to Reproduce:** - Install the `purchase_stock` module. - Create a `purchase order` with an order…
Currently, an error occurs when the user removes the promised date on a purchase order line. **Steps to Reproduce:** - Install the `purchase_stock` module. - Create a `purchase order` with an order line. - `Confirm` the purchase order. - `Validate` the receipt using the smart button on the purchase order. - In the order line, make the `Promised Date` (optional, hidden) field visible. - Remove the value of the `Promised Date` and save. `AttributeError: 'bool' object has no attribute 'date'` After [this commit], the partner on-time rate depends on the promised date. When the user removes the Promised Date from the purchase order line, it tries to compute partner on-time rate. When it filters the move records based on the comparison between the PO line promised date and the move date and accesses the date from promised date [1], it raises an error. This commit ensures that the comparison between the move date and the promised date is performed only when the promised date exists. [this commit]: https://github.com/odoo/odoo/commit/2ce0107c914f5eab3b724119ef6c812c347cdc8d#diff-c3231f0c5829f511c10589fc2c2298fe1c03d59f59a04a1ba8a60c85383ffa42 [1]- https://github.com/odoo/odoo/blob/2936763b700fcf31e3fd126a7c412c274783f342/addons/purchase_stock/models/res_partner.py#L57 sentry-7384699891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where chart links didn't always direct users to the correct view type (like a list view) for data sources. Now, clicking on a datasource link within a chart will reliably take you to the appropriate view, improving the user experience and data accuracy.
Original PR description
Currently, if the user clicks on a datasource link (inside a chart) they will be directed to the default view of the action realted to the datasource model but it will not go to the corresponding type of view (e.g. a list datasource should direct to a list view). Task-5957004 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 update fixes several issues within the Odoo spreadsheet component, improving its reliability and functionality. It includes bug fixes related to date formatting, grid layout, and error handling, ensuring a smoother user experience. This change is part of the 19.1 release.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fc2f8cdb34 [REL] 19.1.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fc2f8cdb34 [REL] 19.1.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d0cd1efd9b [FIX] Grid: hide the table resizer in readonly mode [Task: 6054035](https://www.odoo.com/odoo/2328/tasks/6054035) https://github.com/odoo/o-spreadsheet/commit/1a702e5b33 [FIX] package: update types/jest to match jest version [Task: 6092447](https://www.odoo.com/odoo/2328/tasks/6092447) https://github.com/odoo/o-spreadsheet/commit/24744dda83 [FIX] formats: bypass date format for invalid dates [Task: 6032998](https://www.odoo.com/odoo/2328/tasks/6032998) https://github.com/odoo/o-spreadsheet/commit/1719b27c12 [FIX] Formats: properly format dates with 3 year digits [Task: 6032998](https://www.odoo.com/odoo/2328/tasks/6032998) https://github.com/odoo/o-spreadsheet/commit/3586ef9341 [FIX] package: clean o-spreadsheet-engine leftovers [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f8e7d2a595 [REV] spreadsheet: remove o-spreadsheet-engine package [Task: 6081583](https://www.odoo.com/odoo/2328/tasks/6081583) https://github.com/odoo/o-spreadsheet/commit/45e20d4f99 [FIX] side panels: fix layout of panels with tabs [Task: 6022696](https://www.odoo.com/odoo/2328/tasks/6022696) https://github.com/odoo/o-spreadsheet/commit/11befa290e [IMP] Errors: Add error origin position for #SPILL errors [Task: 5959985](https://www.odoo.com/odoo/2328/tasks/5959985) https://github.com/odoo/o-spreadsheet/commit/c2891d4fa2 [FIX] config: move to ESM release tool [Task: sotg](https://www.odoo.com/odoo/2328/tasks/sotg) https://github.com/odoo/o-spreadsheet/commit/b2c6821808 [FIX] DV: Allow use of cellPosition-related functions in rules [Task: 5868662](https://www.odoo.com/odoo/2328/tasks/5868662) https://github.com/odoo/o-spreadsheet/commit/06c6715224 [FIX] CF: Allow use of cell position-related functions in formula [Task: 5868662](https://www.odoo.com/odoo/2328/tasks/5868662) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue where combo pricing in the self-order mode was incorrect in the backend. The fix accurately calculates prices for combos with multiple quantities, ensuring consistent pricing between the frontend and backend. This improves the reliability of self-order transactions.
Original PR description
**Steps to reproduce:** - Create 2 products, set their price to 0 - Create a combo product, set it's price to 10 - The combo choices should be the 2 products created before - Go to the self order,…
**Steps to reproduce:** - Create 2 products, set their price to 0 - Create a combo product, set it's price to 10 - The combo choices should be the 2 products created before - Go to the self order, order the combo and change the qty to 3 - The price is 30, correct in the frontend - Go to the order in the backend, the price is 0 **Why the fix:** In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines. This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 But the total price has been computed to zero, so the previously computed price_unit is overriden and set to zero. We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line. The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation. opw-6032408
This update corrects an issue in the Slovakian VAT reporting module, preventing duplicate data from being generated in the XML reports. The fix ensures that only one row (positive or negative) is populated, resulting in more accurate and reliable financial reports. This improves data consistency and reduces potential errors.
Original PR description
Add missing `sk_29.vat` in row 32 formula and ensure only one of the rows is filled: row 32 for positive amounts, row 33 for negative ones. This prevents both rows from being populated at the same time and fixes the generated XML accordingly. Related: https://github.com/odoo/enterprise/pull/112963 task-6040973
This update corrects a bug where invalid timezone selections (like 'localtime') in the event creation process caused website rendering errors. The fix removes unsupported timezones from the selection list, ensuring event dates display correctly and preventing potential runtime issues.
Original PR description
### Issue before this commit: When creating an event, the timezone selection dropdown could include values such as localtime or Factory. If one of these values was selected and the event was later…
### Issue before this commit: When creating an event, the timezone selection dropdown could include values such as localtime or Factory. If one of these values was selected and the event was later displayed on the website, it will led to a traceback error such as: Unknown timezone localtime. As a result, the event page will fail to render correctly or trigger runtime errors related to timezone handling. ### Steps to reproduce the issue: 1. Install Ecommerce and Events apps 2. Go to Ecommerce > Site > Events 3. Create a new test event 4. Activate the Unpublished button 5. Click on the button "Events" 6. Set the display timezone as localtime 7. Click the button "Go to website" 8. Traceback will appear saying: Unknown timezone localtime ### Cause of the issue: The issue was caused by the way the list of available timezones was generated. Timezones are retrieved using the system-provided timezone database through Python’s zoneinfo module. This list includes certain special or internal entries such as localtime and Factory. These entries are not meant to be used as real timezones but were still included in the selection field used by the event model. Since the code responsible for formatting event dates expects valid IANA timezone identifiers, selecting one of these special entries could cause failures. ### Reason to introduce the fix: The fix ensures that unsupported or special timezone entries are excluded from the list of selectable timezones. By filtering out values such as localtime and Factory, the system prevents users from selecting timezones that cannot be safely used in event date computations. opw-5994939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the cost of a sale order was incorrectly calculated when using the dropshipping feature. The fix ensures that the cost accurately reflects the purchase order price (e.g., $10) for dropshipped products, resolving a discrepancy in cost reporting.
Original PR description
**Problem:** The cost is not correctly computed on sale order line when the product is dropshipped. **Steps to reproduce:** - enable "margins" and "dropshipping" settings - create a tracked, fifo…
**Problem:** The cost is not correctly computed on sale order line when the product is dropshipped. **Steps to reproduce:** - enable "margins" and "dropshipping" settings - create a tracked, fifo product with dropship route - add a vendor in the purchase tab - confirm a sale order for 1 unit - set a unit price of 10 in the PO and confirm it - validate the dropship picking - come back to the sale order and unhide de cost column **Current behavior:** the cost is 0 **Expected behavior:** the cost should be 10 based on the unit price of the PO **Cause of the issue:** To compute the purchase price, when there is valued moves linked to the sale order line and the product is fifo/avco, we call _get_price_unit() on the moves. https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/sale_stock_margin/models/sale_order_line.py#L21 Which uses the value of the moves https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/stock_move.py#L237-L243 But for dropshipped move the value on the moves is always 0. So the return value will be 0 and purchase price will be 0. **fix:** - The idea of the fix is to use _get_value() instead of the move value for dropship moves. This approach is already used in the code inside _run_average_batch() https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/stock_account/models/product.py#L474-L475 - In case there is not only dropship moves we need to do a weighted average opw-6051004 Forward-Port-Of: odoo/odoo#256089
This update fixes an issue where date alignment was automatically applied to Czech tax documents after they were posted. This was causing problems with late tax deductions, which are common in the Czech Republic. Now, users must manually adjust dates for posted documents to ensure accurate reporting.
Original PR description
Description of the issue/feature this PR addresses: This automatic date alignment make sense in case of new document, but when you work on document that was posted. User should change it manually. In Czech republic we have something like late tax deduction and in this case there is not alignment of dates. Current behavior before PR: When you change taxable_supply_date it automatically change date Desired behavior after PR is merged: Disable this calculation od moves that hase been posted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257135
This update fixes an issue where a second resupply picking was being created when adding components to a subcontracting production order. The fix ensures that new components are correctly grouped with existing pickings based on shared purchase orders, streamlining inventory management and reducing manual effort. This improves the efficiency of our subcontracting processes.
Original PR description
Steps to reproduce: 1- Install Inventory, Purchase and Manufacturing 2- Enable 'multi-step routes' in the settings 3- Create Product A and create a Bill of Materials (BoM type: subcontracting,…
Steps to reproduce: 1- Install Inventory, Purchase and Manufacturing 2- Enable 'multi-step routes' in the settings 3- Create Product A and create a Bill of Materials (BoM type: subcontracting, Component A) 4- Repeat the same for Products [B,C] with components [B,C] correspondingly. 5- Assign the same subcontractor to all of them 6- Create a Purchase Order for both Product A and Product B with vendor as the subcontractor and confirm it 7- Add a new order line with Product C and save Description of issue: A second resupply picking is created Expected behavior: Should group the new product's component with the existing picking Why this happens: When assigning the resupply picking for the new product's component, the search domain for the existing picking includes production_group_id, which is different for the added product. This prevents merging of components into a single resupply picking despite sharing the same destination and purchase order Fix: We ignore production_group_id since it is not necessary in the resupply stock moves domain. opw-5906451 Forward-Port-Of: odoo/odoo#251713
This update resolves a bug where adding captions to images with `display:block` incorrectly removed surrounding text blocks. The fix ensures captions are applied correctly and the caption button remains active, preventing multiple captions from being added to the same image.
Original PR description
Steps to reproduce: - Go to To-do - Open a demo record (e.g., "Welcome Mitchell Admin") - Click on an image - Click on "Caption" from the toolbar - Click on the image again Description of the issue:…
Steps to reproduce: - Go to To-do - Open a demo record (e.g., "Welcome Mitchell Admin") - Click on an image - Click on "Caption" from the toolbar - Click on the image again Description of the issue: - When adding a caption, the parent paragraph block of sibling nodes is removed, making them direct children of the editable area. - After adding a caption, reopening the powerbox does not show the caption button as active, allowing multiple captions to be added on the same image. Cause: - When the image has `display:block`, `closestBlock` returns the image itself as its closest block. - As a result, when a caption is added to an image, its parent paragraph block is not split around the image even if the image has sibling nodes, and when `unwrapContents` is called, both the image and its siblings get unwrapped, making them direct children of the editable area. - Since `closestBlock` is the image (and not a `<figure>`), the caption button in the toolbar is not marked as active even when a caption already exists, so clicking it again adds another caption instead of removing the existing one. Solution: - Instead of using the image's `closestBlock` directly, find the `closestBlock` of its parent element. - This ensures the correct block is found even when the image has `display:block`. task-6051549 Forward-Port-Of: odoo/odoo#256436 Forward-Port-Of: odoo/odoo#255064
This update fixes an issue where the website header padding was incorrectly removed, leading to unexpected spacing. The change ensures the header boundaries are always visible regardless of background colors or images, improving the overall visual consistency of the website. This resolves a minor aesthetic problem and maintains a polished user experience.
Original PR description
Before this PR, the left/right padding of the header would be removed when the header had no background color or when its background color matches the pages color. In these cases, the header boundaries were not visible and so we allowed the header to take more space. However, the previous condition would not check if the page had a background image, or if the header had a shadow defined. The header would have visible boundaries and the element on the extremities would be stuck to the boundaries. This commit updates the condition to include any possible option that would make the header boundaries visible. task-5367502 Forward-Port-Of: odoo/odoo#244413
This update fixes issues with capturing Chrome logs during shutdowns and improves the stability of the Odoo server's stop process. The changes ensure critical errors are logged, even during unexpected shutdowns, and enhance the server's resilience to Chrome-related problems.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256656 Forward-Port-Of: odoo/odoo#256061
This update resolves a visual problem in the website editor previews, specifically with the filmstrip layout. The issue was caused by undefined variables that prevented certain styles from applying, leading to a missing placeholder rectangle. The code has been updated to ensure these variables are correctly defined, restoring the expected design.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255339
This update resolves a warning related to outdated software used in our documentation generation process. The change ensures compatibility with newer versions of Docutils, preventing potential issues with future updates. This ensures our documentation remains reliable and up-to-date.
Original PR description
Argument "writer_name" will be removed in Docutils 2.0. Specify writer name in the "writer" argument. Reference: - https://docutils.sourceforge.io/0.22/RELEASE-NOTES.html#writers Forward-Port-Of: odoo/odoo#257348
This update resolves an issue where switching browser tabs while a product configurator dialog is open would reset sales orders to their original state. Now, changes made within the dialog are correctly saved, ensuring data integrity when navigating between tabs. This improves the user experience when configuring complex products.
Original PR description
## Versions 18.0+ ## Issue When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been…
## Versions
18.0+
## Issue
When the product configurator dialog is open, a browser tab change acts like a discard on the SOL: coming back to the Odoo tab displays the dialog but the SOL has been reverted to its previous state.
## Steps to reproduce
- Create a new SO for any customer:
- Add a standard (non-combo/non-variant) product (e.g. "Apple Pie");
- Save manually;
- Change the product for a combo or variant one (e.g. "Customizable Desk");
- With the opened dialog, change from browser tab then come back;
- The SOL has been reset to the standard product ("Apple Pie") and confirming the dialog has no effect).
## Cause
The `beforeVisibilityChange` hook is triggered by the tab change and saves the form without updated values. This is because the hook checks for two conditions to be true: https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/web/static/src/views/form/form_controller.js#L479-L483 The tab change indeed changes the document's visibility to "hidden" but the controller has never been updated with the form's display in the dialog and, therefore, `this.formInDialog` is indeed equal to zero.
## Test
No test as we cannot simulate a browser tab change then come back to the first tab.
opw-5494089
Forward-Port-Of: odoo/odoo#257846
Forward-Port-Of: odoo/odoo#247797