Tuesday, April 2, 2024
35 changes
Resolved issues and error corrections
Fixed a bug where the 'propagate_cancel' checkbox in purchase orders was hidden from users, preventing them from controlling whether canceling a purchase order should also cancel related sales order deliveries. Users can now access and modify this setting to manage how purchase order cancellations affect their sales operations.
Original PR description
Activate "Reception Report" feature Create a SO for a storable product, confirm. Create a PO for the same product. Confirm the PO and check the delivery, open the "Allocation" report Assign the Product to the delivery of the SO. Go back to the PO and cancel the order, delivery of the SO will be cancelled. Issue: Currently the user cannot modify this behavior as the `propagate_cancel` checkbox is unaccessible opw-3733512 Forward-Port-Of: odoo/odoo#159782 Forward-Port-Of: odoo/odoo#158587
This fix restores the allocated time label that was missing from the project task portal view when using day-based timesheet encoding. Previously, the label only appeared for non-day encoding methods, causing confusion for users who couldn't see how much time was allocated to their tasks. The fix now displays the label consistently regardless of the timesheet encoding method used.
Original PR description
Versions: ------------ saas-16.4 Steps to Reproduce: --------------- - open project - create a project and allow timesheet - open timesheet and change encoding method to days/half days - create a task in the project and set allocated time - open portal view of the task Issue: ------------ - There is no label for allocated time. Cause: ---------- - Condition was added in this commit 82a85d42c86cffcd6e96b0712c8ff9a221f25d87 to show the label if encoding method is not in days. Fix: -------- - We apply the label for both encoding method of timesheet. task-3761269 Forward-Port-Of: odoo/odoo#156449
This fix corrects a bug in how the website editor detects when page options need to reload. A previous update accidentally passed an array instead of properly checking individual option methods, which could cause crashes in customized versions. This fix ensures the reload detection works correctly and prevents potential system failures.
Original PR description
Follow-up of [1]. Commit [2] refactored the way we check if an option update needs to trigger a page reload: if the option is marked as a page option (`data-page-options="true"` on the option's main…
Follow-up of [1]. Commit [2] refactored the way we check if an option update needs to trigger a page reload: if the option is marked as a page option (`data-page-options="true"` on the option's main `<div>`), then it will reload whatever the method used if there is a `reload` parameter. Note that this `reload` parameter does not make much sense anymore, it should be reviewed/removed in master. Problem: [2] made a mistake in its implementation, pushing an array instead of concatenating it. This worked by chance, as instead of asking "does this option method requires a reload", it was asking "does this set of option methods requires a reload"... and in that case, the code is fallbacking on retrieving common parameters, which `reload` likely is without custo. This could have been fixed in master only. Given the very low risk of breaking anything critical updating this code, it was chosen to prevent a potential crash in custo (which could occur as we give a wrong parameter type to a main method) and allow overrides to make `reload` a specific parameter for a specific method without the need of `data-reload` added in the DOM. [1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345 [2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-70f7fe38208aa7fe678f18e329d3c11b70065dee723921352b6005774e8bab53R456 Forward-Port-Of: odoo/odoo#159640
This fix resolves crashes that occurred when checking if an employee is newly hired in the HR module. The issue happened because the system was inconsistent in handling different data types (dates, datetimes, and boolean values) when determining new hire status. After this fix, the newly hired field can be reliably queried without errors.
Original PR description
Description of the issue/feature this PR addresses: - This PR addresses an issue in the `hr_contract` module where the `_compute_newly_hired` method can crash depending on the value type of the…
Description of the issue/feature this PR addresses: - This PR addresses an issue in the `hr_contract` module where the `_compute_newly_hired` method can crash depending on the value type of the `new_hire_field` field. Current behavior before PR: - In an Odoo instance with `hr_payroll` installed, when querying the `newly_hired` field on the `HrEmployeeBase` model, the request fails with an error (refer to issue #154849). - This failure is due to a change in the field used by Odoo to determine if the employee is newly hired, from a Datetime (`created_at`) to a Date (`first_contract_date`). - The request also fails if the employee has never been associated with any contract because the return value is a boolean. Desired behavior after PR is merged: - This PR ensures that the `newly_hired` field can be queried without causing a crash, correctly indicating if an employee is newly hired. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when approving expense reports from the list view, the system properly validates that all required analytic accounting information is complete, just as it does in the form view. Previously, expense reports could be approved without proper analytic data when using the list view, creating inconsistencies in financial records.
Original PR description
**Steps to reproduce:** - Install Accouting and Expenses - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans" - Create…
**Steps to reproduce:** - Install Accouting and Expenses - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans" - Create an analytic plan with the following line: * Domain: Expense * Applicability: Mandatory - Create an analytic account from the plan via "Analytic Accounts" smart button - Create an expense without analytic - Create a report from it - Submit it to manager - Try to approve it => An expected Validation Error will raise: "One or more lines require a 100% analytic distribution." - Go to "Expenses / Expense Reports" (list view) - Select the created expense report - Try to approve it **Issue:** The report will be approved even if there is no analytic configured on it. **Cause:** "validate_analytic" option is not passed in the context when approving the report from list view as it is done in form view. opw-3806787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160013 Forward-Port-Of: odoo/odoo#159043
This fix prevents readonly fields from being saved when updating records in paginated list views within forms. Previously, when an automated process tried to update a record on a page the user hadn't viewed yet, readonly field values were incorrectly being sent to the server, causing operation errors. The fix now properly evaluates which fields are truly readonly before saving, preventing these invalid operations.
Original PR description
Have an x2many with several pages containing a field with a readonly modifier (in the view, not in the field definition), e.g. `readonly="1"` in the arch. Have an onchange that returns an UPDATE…
Have an x2many with several pages containing a field with a readonly modifier (in the view, not in the field definition), e.g. `readonly="1"` in the arch. Have an onchange that returns an UPDATE command for a record that isn't in page 1 (so a record we haven't read), with a value for that readonly field. Before this commit, the value was sent in the UPDATE command, even though readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly expressions, as they can depend on other fields, which we didn't read if the record is in a page we didn't browse to yet. However, "static" expression like `"1"`, or `"context.get('something')"` can totally be evaluated, and they should. This is what this commit does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2" - Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save - Change quantity to 2 - Save => Invalid Operation
opw 3819253
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-prThis fix corrects how inventory quantities are calculated when unpacking materials in manufacturing operations. Previously, the system was incorrectly tracking reserved units when components were packed and then partially moved, causing inventory counts to be wrong. This ensures accurate inventory visibility and prevents discrepancies in stock levels during multi-step manufacturing processes.
Original PR description
Steps to reproduce: - Install MRP - Enable packages and multi-step routes - Enable two steps manufacturing - Create a component and a product - Create a BOM for the product and add the component - Make an MO for 100 units of the product - Go to the picking and make a move of 20 units of the component with a destination package - Put in pack - Create the backorder and validate the transfer of the remaining components - Go back to the MO Issues: Units reserved is wrong. The problem is when we are unpacking, we were using result package inside the key. But what we want is to remove quantity from the package the quantity originate from. opw-3759006 Forward-Port-Of: odoo/odoo#159810 Forward-Port-Of: odoo/odoo#158166
This fix resolves crashes that occurred when checking if an employee is newly hired in the HR module. The issue happened because the system was not properly handling different data types (dates, datetimes, and empty values) when determining new hire status. After this fix, the newly hired field can be reliably queried without errors.
Original PR description
Description of the issue/feature this PR addresses: - This PR addresses an issue in the `hr_contract` module where the `_compute_newly_hired` method can crash depending on the value type of the…
Description of the issue/feature this PR addresses: - This PR addresses an issue in the `hr_contract` module where the `_compute_newly_hired` method can crash depending on the value type of the `new_hire_field` field. Current behavior before PR: - In an Odoo instance with `hr_payroll` installed, when querying the `newly_hired` field on the `HrEmployeeBase` model, the request fails with an error (refer to issue #154849). - This failure is due to a change in the field used by Odoo to determine if the employee is newly hired, from a Datetime (`created_at`) to a Date (`first_contract_date`). - The request also fails if the employee has never been associated with any contract because the return value is a boolean or none. Desired behavior after PR is merged: - This PR ensures that the `newly_hired` field can be queried without causing a crash, correctly indicating if an employee is newly hired. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where custom code using the button loading effect feature could cause the system to crash. The fix ensures that if the feature is used in an unexpected way, it will simply do nothing instead of breaking, maintaining system stability for users with customizations.
Original PR description
Follow-up of [1] which changed code in stable in such a way it could break when the function was used in a way it was not intended to in some custom code. Note that the function could also be used by giving a string selector to it, that will not work anymore: but instead of crashing, this commit will just make it do nothing (it is only about adding a button loading effect anyway). [1]: https://github.com/odoo/odoo/commit/8bd51d060a48378652ae10c57a1949c3bb7d78de Forward-Port-Of: odoo/odoo#160178
This update fixes how taxes are calculated on product prices in the online store to match the standard sales process. Previously, the website store used an older tax calculation method that didn't handle all tax scenarios correctly, particularly when taxes were included in prices. Now all tax calculations use a single, more reliable method that properly handles complex tax situations.
Original PR description
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single entry point, `_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product), but not in `_get_sales_prices` (/shop page). opw-3700803 Fixes #155162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160125 Forward-Port-Of: odoo/odoo#159122