Daily updates from Odoo
Tuesday, January 14, 2025
13 changes · saas-17.2
Resolved issues and error corrections
Activity Plans are now filtered so users only see plans for the company they have selected, along with global plans when no specific company is chosen. This prevents confusion from unrelated company plans appearing in the list and helps teams work with the right HR activity templates.
Original PR description
Steps: - Go to the 'Activity Plans' section. - Select a company in the company widget. - Activity plans were not filtered based on the selected company. Issues: - Activity plans were not filtered correctly by the selected company, showing plans from unrelated companies. Fix: - Added domain to display activity plans assigned to the selected company. - Added domain to display global activity plans when no company is selected. Task - 4441838 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Miscellaneous changes
**Affects** 16.0+ **Steps to reproduce:** - Render the Contact qweb widget with fields ["phone", "website"] ```py Contact = self.env["ir.qweb.field.contact"] partner = self.env["res.partner"].create( { "name": "Test Partner", "phone": "1234567890", "website": "https://www.example.com", } ) result = Contact.value_to_html(partner, {"fields": ["phone", "website"]}) ``` **Result:** - The website is not shown --- This is a regression int
Original PR description
**Affects**
16.0+
**Steps to reproduce:**
- Render the Contact qweb widget with fields ["phone", "website"]
```py
Contact = self.env["ir.qweb.field.contact"]
partner = self.env["res.partner"].create(
{
"name": "Test Partner",
"phone": "1234567890",
"website": "https://www.example.com",
}
)
result = Contact.value_to_html(partner, {"fields": ["phone", "website"]})
```
**Result:**
- The website is not shown
---
This is a regression introduced in 9e53aea9, in combination with some buggy behavior in the qweb compilation.
Somehow the `t-elif` condition is applying on the next element instead on itself, hiding the website item. I did not investigate this further.
ping @lvsz @ryv-odoo
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192460
Forward-Port-Of: odoo/odoo#191201Partly backporting 3731550474dc90819fa1667385f35f4a22ee4f11 Currently, to ensure the filled forms are set as readonly, we erase all the existing flags. Instead, we now only force the readonly flag. Forward-Port-Of: odoo/odoo#191207
Original PR description
Partly backporting 3731550474dc90819fa1667385f35f4a22ee4f11 Currently, to ensure the filled forms are set as readonly, we erase all the existing flags. Instead, we now only force the readonly flag. Forward-Port-Of: odoo/odoo#191207
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move. Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not bei
Original PR description
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the…
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session.
But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move.
Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not being matched correctly with the tax amounts from the PoS move (since we only look for the transition account on the PoS move).
Reproduce on runbot for l10n_mx
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS
* Payment method: Cash on journal CSH1
* Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Cash payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account)
```
* 1 entry in the POS journal (order)
base: | - 100.0 $
tax: | - 16.0 $
receivable: | + 116.0 $
* 1 entry in the CSH1 journal (cash / payment)
cash: | + 116.0 $
receivable: | - 116.0 $
* 1 entry in the CBMX journal (caba)
base: | - 100.0 $
base: | + 100.0 $
tax: | - 16.0 $
tax: | + 16.0 $
* 1 entry in the EXCH journal (exchange difference)
for the cash basis rounding difference
tax: | - 16.0 $
tax: | + 16.0 $
```
This commit fixes the issue by just skipping the creation of caba moves during the reconciliation of the PoS move lines. Further we make sure no exchange difference entry is created for the (not even created) cash basis entries.
opw-4355124
Forward-Port-Of: odoo/odoo#193375
Forward-Port-Of: odoo/odoo#193195Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss) Steps to reproduce: - Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%) - Confirm -> amount = 108.9 - Duplicate the invoice (in the ticket: Create a Credit Note) Issue: => The credit not
Original PR description
Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an…
Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss) Steps to reproduce: - Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%) - Confirm -> amount = 108.9 - Duplicate the invoice (in the ticket: Create a Credit Note) Issue: => The credit note is not of the same amount = 106.80. That is, MINUS discount * tax_amount <-> 108.90 MINUS 10% * 21= 106.80 Cause: When there is a "Separate discount accounts on invoices" that is set, discount line appear on the journal items of the document; moves between the default account for such transaction to the chosen move in the settings. When iterating through those discount lines, the condition was not strict enough to filter them out and would put a tax on them (as my dear colleague Andrea said: the bomb has been planted) Therefore, when creating a credit/duplicating, we copy the data wrongly (but in a correct a way for a standard flow) which gives incoherent results opw-4166601 Forward-Port-Of: odoo/odoo#187565
Description of the issue this commit addresses: The Italian tax report lacks clarity and can be improved both in readabilty and usability by splitting the monthly and the annual reports. --- Desired behavior after this commit is merged: The Italian tax report is now split in a monthly and an annual report. The report uses the sections mechanism to be split in the different parts it is made from and clean the UI by not having everything on the same sreen. --- Enterprise PR: h
Original PR description
Description of the issue this commit addresses: The Italian tax report lacks clarity and can be improved both in readabilty and usability by splitting the monthly and the annual reports. --- Desired behavior after this commit is merged: The Italian tax report is now split in a monthly and an annual report. The report uses the sections mechanism to be split in the different parts it is made from and clean the UI by not having everything on the same sreen. --- Enterprise PR: https://github.com/odoo/enterprise/pull/62405 Task-3479785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164064
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193358
Original PR description
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193358
Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<scr
Original PR description
Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<script>" are excluded from search results. opw-4420622 Forward-Port-Of: odoo/odoo#192029
Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759
Original PR description
Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759
After modifying the price of an order line, going to floorplans, selecting the previous table and setting a customer now keep the price previously manually set. As the attribute `order_line.price_manually_set` is not saved in backend, when loading an order from the backend its value is always False. Now we recompute this attribute by comparing the default price of the product and the unit price of the orderline. opw: 4393328 Description of the issue/feature this PR addresses: Current
Original PR description
After modifying the price of an order line, going to floorplans, selecting the previous table and setting a customer now keep the price previously manually set. As the attribute `order_line.price_manually_set` is not saved in backend, when loading an order from the backend its value is always False. Now we recompute this attribute by comparing the default price of the product and the unit price of the orderline. opw: 4393328 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#193015 Forward-Port-Of: odoo/odoo#191053
Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453
Original PR description
Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453
Steps to Reproduce the Bug: - Enable multi-storage location - Create a storable product “P1” with the following BoM: - Component: C1 - Create two orderpoints: - First orderpoint: - Route: Manufacture - Product: P1 - Min: 1, Max: 1 - Location: Shelf 1 - Second orderpoint: - Route: Manufacture - Product: P1 - Min: 1, Max: 1 - Location: Shelf 2 - Click on “Order Once” of the first orderpoint. - A manufacturing order (MO) is created with the destination loca
Original PR description
Steps to Reproduce the Bug:
- Enable multi-storage location
- Create a storable product “P1” with the following BoM:
- Component: C1
- Create two orderpoints:
- First orderpoint: - Route: Manufacture - Product: P1 - Min: 1, Max: 1 - Location: Shelf 1
- Second orderpoint:
- Route: Manufacture
- Product: P1 - Min: 1, Max: 1 - Location: Shelf 2
- Click on “Order Once” of the first orderpoint.
- A manufacturing order (MO) is created with the destination location: Shelf 1.
- The “To Order” field will be computed as 0.
- Click on “Order Once” of the second orderpoint.
Problem:
The same manufacturing order is updated, even though its destination location is Shelf 1 which is wrong and The “To Order” quantity for the second orderpoint remains at 1. So each time the scheduler is triggered, the MO is updated by one unit if the trigger is set to “auto”.
opw-4418632
Forward-Port-Of: odoo/odoo#192035## Description Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption. We introduce an upper bound on the delegated `_name_sear
Original PR description
## Description Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded…
## Description
Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption.
We introduce an upper bound on the delegated `_name_search`. To avoid excessive iterations when there is no limit, the bound is set large enough but not so large that it causes blocking regressions. Each iteration becomes more selective than the previous one, as already found templates are excluded from the search scope.
## Benchmark
On a database with over half-million active products, a non-selective `name_search` that matches 1/3 of the products (For ex: `name='d', args=[('sale_ok', '=', True)]`, which happens during via dropdown of products on a `sale.order`):
| | Before | After |
|---------------|------------------|-------|
| Timings (hot) | 15min+ (timeout) | 50ms |
## Reference
opw-4448182
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193448
Forward-Port-Of: odoo/odoo#193293