Friday, August 23, 2024
8 changes · 17.0
Resolved issues and error corrections
Automated actions can now create records for models that do not use a standard name field. This prevents errors in affected automations and makes record creation behavior more reliable across different business objects.
Original PR description
Currently, the `_run_action_object_create` method (used in particular to propose record creation using a `name` field in automations) assumes that all models have a `name` field, which is not true.
In fact, before this commit, we used
```py
res = {'name': self.value}
res = self.env[self.crud_model_id.model].create(res)
```
This will cause a traceback in models without a `name` field.
This commit uses `name_create` directly, which is what it's for.
opw-4100885A small typo introduced during earlier time off refactoring was corrected. This keeps the employee time off logic aligned with the intended behavior and reduces the risk of minor errors in leave management.
Original PR description
During refactoring of hr_holidays for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a) a typo was introduced.
Completed and locked delivery orders no longer allow users to add new detailed operation lines. This keeps finalized stock movements consistent and prevents accidental changes after validation.
Original PR description
### Steps to reproduce: - Create and validate a delivery order for some product - Click on the "Detailed Operations" button on top of the picking form #### > You are able to create new move lines on your picking even thought it is done and locked. ### Cause of the issue: The `create` attribute of the view determines if the record can or can not be created. However, it is currently not set in the context of the view called by the `action_detailed_operations`. ### Note: This `action_detailed_operations` did not exist in 16.0. opw-4103700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Purchase quotations now remove a vendor discount when the ordered quantity no longer matches any discount rule. This prevents outdated discounts from staying on purchase lines and helps ensure supplier pricing remains accurate.
Original PR description
Problem: When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains. Steps to reproduce: - Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10% - Create a new quotation with the product and set the quantity to 10. - Update the quantity to 20. - Update the quantity to 1. The 10% discount still appears, even though it should have been removed. opw-4123984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Project app now keeps the option to add a new stage visible after users refresh or directly open a project task board. This prevents confusion and ensures project teams can continue managing task stages without needing to navigate away and back.
Original PR description
To reproduce the issue: - In the project app, click on a project to enter the Kanban view - Refresh the page The "+ stage" button to add a stage to a project disappears upon page refresh. This is caused by a context check that functions correctly during the normal flow. However, when directly accessing the link or refreshing the page, the `active_model` context is lost. Since the action `act_project_project_2_project_task_all` always filter project on active_id, we can add as a default context ´'active_model': 'project.project'´ opw-4075290
This fix makes automated checks for website form editing wait until newly added content is properly editable before trying to change it. It helps prevent false test failures without changing the normal user experience in the website editor.
Original PR description
When an editable content is dropped in the website form, the editable elements identification and adaptation happens on `start()` (async). In a normal user interaction context, the dropped content would be set as editable in time, but when doing automated testing, we need to make sure the dropped content has `[contenteditable=true]` before editing its content. Remark: This commit also removes the `_keydown()` test function from the tour (since it still uses the deprecated `execCommand()`) and replaces it with a simple `run: "text ..."`. runbot-64816
The purchase reporting pivot now labels rows grouped by purchase order with the actual order reference instead of an unhelpful count. This makes it easier for users to identify and analyze purchase orders directly in reports.
Original PR description
**Current behavior:** In the purchase report pivot view, grouping by order does not display the order reference on the row's label. **Expected behavior:** Rows corresponding to a purchase order should be labeled with the order reference (name). **Steps to reproduce:** 1. In the Purchase app, go to Reporting -> Purchase 2. Switch to the pivot view 3. Expand the row to Add Custom Group -> Order 4. See that the reference does not get displayed **Cause of the issue:** When we select group by for the `order` option, the rows are aggregated via `count_distinct`, so the label for the pivot becomes '1' (as they are grouped by id which is unique). **Fix:** Make the order_id field in the view `type=row` instead of `type=measure` so that they do not get aggregated. opw-4075321
This fix resolves a test failure in the partner commission module where salespeople lacked the necessary permissions to view sale order templates. The change ensures that the sale order template field is properly visible during testing, allowing the commission plan rules test to run successfully without demo data.
Original PR description
Before this commit, the salesmen did not had the right group and the test crashed with the following error when the test was run without demo data:
```
FAIL: TestCommissions.test_commission_plan_rules_with_template
Traceback (most recent call last):
File "/data/build/enterprise/partner_commission/tests/test_commissions.py", line 221, in test_commission_plan_rules_with_template
form.sale_order_template_id = so_template
File "/data/build/odoo/odoo/tests/form.py", line 326, in __setattr__
self[field_name] = value
File "/data/build/odoo/odoo/tests/form.py", line 331, in __setitem__
assert field_info is not None, f"{field_name!r} was not found in the view"
AssertionError: 'sale_order_template_id' was not found in the view
```
runbot task: 70916 and 73195
https://runbot.odoo.com/web/#id=70916&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=73195&view_type=form&model=runbot.build.error&menu_id=405&cids=1