Tuesday, November 28, 2023
6 changes · 17.0
Resolved issues and error corrections
Grouped reports now produce drill-down filters that better match what each user is allowed to see. This prevents totals for empty many-to-many fields from linking to incomplete or inconsistent record lists when some related records are hidden by access rights.
Original PR description
\* = test_read_group
Currently, a search with the following domain `[('m2m_field', '=', False)]` will return only the records for which the m2m field is actually empty and not take access rights into account. This means that, for a given user and depending on access rules, `record.m2m_field` can give an empty recordset while a search using the previous domain won't return this record.
This behavior is problematic when such a domain is returned by the read_group. Indeed, when using read_group to group on a m2m field, records for which this m2m field appears empty for the current user will be counted in the column 'False'. However, the domain associated to this column is not always valid, as this m2m field can appear empty for the current user but still have records in it that the current user does not have access to. Such records won't be returned by a search performed using the domain returned by the read_group for the False column.This fixes cases where changing quantities or splitting draft manufacturing orders could incorrectly advance related stock movements to confirmed. Keeping these movements in draft helps prevent premature workflow steps and ensures multi-step manufacturing processes create the expected pickings.
Original PR description
When changing the demand quantity on a draft picking line or on a production order, the related stock.move that should be in draft will be confirmed. This is because the write function incorrectly calls _recompute_state on draft moves. Also for mrp, using the split function on draft moves will mark the stock.moves of the new production order(s) as confirmed because that's the only state given by _get_backorder_move_vals. Due to that, multisteps mrp wouldn't correctly create pickings since it looks for draft moves. This is also fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the spreadsheet application from crashing when a user undoes changes that remove a datasource while the datasource panel is still open. The system now automatically closes the panel when the underlying datasource no longer exists, providing a smoother user experience.
Original PR description
How to reproduce: -Insert a datasource from a standard pivot view - open the corresponding sidepanel (top menu > Data > datasource in question) - undo 2-3 times so that the datasource is no longer in the sheet -> crash Task: 3551443 Forward-Port-Of: odoo/enterprise#49822 Forward-Port-Of: odoo/enterprise#48871
This update fixes an issue in the Spanish tax reporting export where group taxes (taxes containing multiple child taxes) were not being properly handled, causing inaccurate tax records in exported reports. The fix ensures all child taxes within a group are correctly registered and also improves handling of taxes marked as 'ignore' to exclude them from the export.
Original PR description
When looping over the tax in report line's tax_ids, sometimes the tax we receive is a group tax, which consist of 2 children tax inside it. They all have different id, and that causes the sheet_line_vals dictionary that depend on the id to be inaccurate. This commit register all of the children inside the tax group to the sheet_line_vals, by applying a `flatten_taxes_hierarchy` on the tax_ids This commit also adds an improvement where tax with l10n_es_type of 'ignore' are now ignored (for example: DUA's 'Subtract Base' line), and DUA line should have a type of 'F5' instead in `exp_line_vals` community-PR: https://github.com/odoo/odoo/pull/143314 task-id: 3604971
This fix corrects how the Master Production Schedule (MPS) calculates component demand when products have variants. Previously, when forecasting demand for different product variants with variant-specific components, the system was incorrectly doubling the demand for components in the second variant. Now each variant's components are properly tracked independently, ensuring accurate demand forecasts for manufacturing planning.
Original PR description
MPS does not fully consider product variants.
Steps to reproduce:
- create component 1
- create component 2
- create finished product P, attribute 'version', values 'V1' & 'V2'
- create bill of material for P with lines:
- component 1 applying on variant 'V1'
- component 2 applying on variant 'V2'
- add P - V1 and its bom in MPS
- add P - V2 and its bom in MPS
- set forecasted demand of P - V1 to 10
: indirect demand forecast of component 1 goes to 10
: ok
- set forecasted demand of P - V2 to 10
: indirect demand forecast of component 2 goes to 20
: ! should be 10 !
task: 3556620
Forward-Port-Of: odoo/enterprise#51394Fixed an issue where clicking to review an appointment after creating your first resource-based appointment type would incorrectly create a new appointment instead of opening the existing one. This ensures users can properly review their newly created appointments during the onboarding process.
Original PR description
**Before this PR** Clicking to review an appointment after creating your first resource-based appointment type with onboarding panel still creates a new one. **After this PR** It opens the existing appointment. Task-3503869 Forward-Port-Of: odoo/enterprise#48091