Tuesday, February 18, 2025
18 changes · saas-17.4
Resolved issues and error corrections
Odoo now avoids treating plain text message content as if it were HTML. This prevents links or other message features from being detected when they are only text, reducing misleading behavior in Mail and related messaging views.
Original PR description
When message content is not markup(), it will not render its content as HTML but as text when using t-out. This case was not taken into account when manually processing the content, leading to incorrectly detecting links or other features within purely text content. Those are now properly ignored. From https://github.com/odoo/odoo/pull/190461
Point of Sale notes are now shown in the order configured by users. This makes the PoS interface more predictable and ensures staff see notes in the intended sequence.
Original PR description
Before this commit, the PoS notes were not displayed in the correct order in the PoS interface, despite the existence of a `sequence` field that allowed users to define their desired order. opw-4473463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This commit comes as an apology for the horrible code I wrote in PR #166043 in order for the installation of `l10n_hu_edi` to not fail if some of the default Hungarian taxes (defined in `l10n_hu`) had been deleted. Instead of rolling back the loading of the EDI-specific fields if some taxes don't exist, we can just load those fields on the taxes that do exist. Which is a lot cleaner and simpler. Sorry again! task-none Forward-Port-Of: odoo/odoo#196471
Original PR description
This commit comes as an apology for the horrible code I wrote in PR #166043 in order for the installation of `l10n_hu_edi` to not fail if some of the default Hungarian taxes (defined in `l10n_hu`) had been deleted. Instead of rolling back the loading of the EDI-specific fields if some taxes don't exist, we can just load those fields on the taxes that do exist. Which is a lot cleaner and simpler. Sorry again! task-none Forward-Port-Of: odoo/odoo#196471
Backport of https://github.com/odoo/odoo/pull/166533: > For the Bizkaia tax agency in Bask country, we also need to send vendor bills and vendor bill refunds. In Odoo standard however, we only have a link towards one original vendor bill for a vendor bill refund. > > The problem however is that your vendor can send you a vendor refund for multiple original vendor bills and that for the moment, you do not really have a good way to encode it. > > So, we added a field to put the other ori
Original PR description
Backport of https://github.com/odoo/odoo/pull/166533: > For the Bizkaia tax agency in Bask country, we also need to send vendor bills and vendor bill refunds. In Odoo standard however, we only have a link towards one original vendor bill for a vendor bill refund. > > The problem however is that your vendor can send you a vendor refund for multiple original vendor bills and that for the moment, you do not really have a good way to encode it. > > So, we added a field to put the other original vendor bills as a many2many. > > We also updated the translations. > > opw-3719158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-4966 Forward-Port-Of: odoo/odoo#193376 Forward-Port-Of: odoo/odoo#191303
This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190529
Original PR description
This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190529
**Current behavior:** For `real_time`, `avco` prod: When posting the bill of a reception which originated from a PO with a foreign currency, if a return for the receipt was generated as well as a return for that return, there will be an extraneous SVL created which illogically affects the product's `standard_price` (product value has increased from nowhere). **Expected behavior:** The product cost prior to posting the bill and after posting the bill is equal. **Steps to reproduce:** 1.
Original PR description
**Current behavior:** For `real_time`, `avco` prod: When posting the bill of a reception which originated from a PO with a foreign currency, if a return for the receipt was generated as well as a…
**Current behavior:** For `real_time`, `avco` prod: When posting the bill of a reception which originated from a PO with a foreign currency, if a return for the receipt was generated as well as a return for that return, there will be an extraneous SVL created which illogically affects the product's `standard_price` (product value has increased from nowhere). **Expected behavior:** The product cost prior to posting the bill and after posting the bill is equal. **Steps to reproduce:** 1. Create an `avco` + `real_time` costing/valuated productA 2. Activate 2 additional currencies + give them unique exchange rates 3. Create a purchase order in the first of the two additional currencies, for `N` units of productA at $`price_unit` 4. Confirm the PO -> receive the product 5. Create another purchase order in the second of the two currencies, again `N` units @ $`price_unit` 6. Confirm + receive, then generate a return for this reception 7. Generate a return for the return of step 6 8. Note the current `standar_price` of ProductA 9. For the second purchase order (the one with the returns) create the vendor bill 10. Observe that the `standard_price` of ProductA has increased without any legitimate basis **Cause of the issue:** In `_generate_price_difference_vals`: https://github.com/odoo/odoo/blob/55658e7f43375d7e1af07293e2cd9d1cc4b33883/addons/purchase_stock/models/account_move_line.py#L307-L314 We operate with the assumption that, because we are in a return of a return, any existing pdiff will have already been compensated for- so we take the POL price unit at face value to compare with the AML price unit. But, in case the POL and AML are in different currencies, this will fail to prevent a pdiff SVL from being created. **Fix:** Convert the purchase line's returned price unit to the currency used by the layer for which we are finding the pdiff. opw-4334372 Forward-Port-Of: odoo/odoo#197817 Forward-Port-Of: odoo/odoo#196222
Consider the following DOM: ```html <ul> <li><h1>[test</h1></li> <li><h1>content]</h1></li> </ul> ``` Inserting paragraphs there (say, `<p>test</p><p>content</p>`) resulted in the loss of the `li`s: ```html <ul> <p>test</p> <p>content[]</p> </ul> ``` This is because the `insert` function failed to check further than the text node's immediate parent when looking if it was in a `li`. This PR also prevents the default behavior of a mousedown event on the Cha
Original PR description
Consider the following DOM:
```html
<ul>
<li><h1>[test</h1></li>
<li><h1>content]</h1></li>
</ul>
```
Inserting paragraphs there (say, `<p>test</p><p>content</p>`) resulted in the loss of the `li`s:
```html
<ul>
<p>test</p>
<p>content[]</p>
</ul>
```
This is because the `insert` function failed to check further than the text node's immediate parent when looking if it was in a `li`.
This PR also prevents the default behavior of a mousedown event on the ChatGPT alternatives dialog so it doesn't cancel the user's text selection in the editor. This way, like with every other dialog, whenever it's open nothing can happen in the background.
task-4258167
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#186881Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange meth
Original PR description
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from…
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange method `_onchange_location_in` triggers. https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/product_strategy.py#L80-L83 We get the `loc_in` value as an empty recordset, because the user removed the `location_in_id` value. So it will lead to the above traceback from the below line https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/stock_location.py#L453-L455 sentry-6210564390 Forward-Port-Of: odoo/odoo#195555
**Current behavior:** Invoicing some product at a price unit different from that at reception (with the product having manual valuation and non-standard costing) will create pdiff account move lines on the invoice. **Expected behavior:** With manual valuation, there should not be pdiff AMLs. **Steps to reproduce:** 1. Create a product with average costing and manual valuation 2. Receive 10 units @ $100 to establish some std price 3. Consume the 10 product qty (scrap, sale, ...)
Original PR description
**Current behavior:** Invoicing some product at a price unit different from that at reception (with the product having manual valuation and non-standard costing) will create pdiff account move lines on the invoice. **Expected behavior:** With manual valuation, there should not be pdiff AMLs. **Steps to reproduce:** 1. Create a product with average costing and manual valuation 2. Receive 10 units @ $100 to establish some std price 3. Consume the 10 product qty (scrap, sale, ...) 4. Create the invoice on the purchase order 5. Change the price unit on the bill to $120 per product -> post 6. In the journal items tab on the invoice, see the pdiff AMLs **Cause of the issue:** No consideration for valuation when creating the AMLs for pdiff. **Fix:** Check that valuation is not manual prior to creating the AMLs. opw-4492217 Forward-Port-Of: odoo/odoo#197009 Forward-Port-Of: odoo/odoo#196786
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191686 Forward-Port-Of: odoo/odoo#173010
Original PR description
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191686 Forward-Port-Of: odoo/odoo#173010
Previously, if a request in the Nilvera Client failed due to connectivity issues, a traceback was thrown. This behavior caused upgrade CI failures because the internet is blocked and check_nilvera_customer would be triggered for newly created partners. This commit enhances the exception handling for all requests and fixes the upgrade CI issue by silently exiting the function when a connectivity problem is detected. no task ID. Forward-Port-Of: odoo/odoo#197797
Original PR description
Previously, if a request in the Nilvera Client failed due to connectivity issues, a traceback was thrown. This behavior caused upgrade CI failures because the internet is blocked and check_nilvera_customer would be triggered for newly created partners. This commit enhances the exception handling for all requests and fixes the upgrade CI issue by silently exiting the function when a connectivity problem is detected. no task ID. Forward-Port-Of: odoo/odoo#197797
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#76341
Original PR description
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#76341
When an employee takes a leave, the private car reimbursement amount is reduced by a certain amount. However, when they take multiple leaves, the computation doesn't follow. This commit fixes the issue. task-4353922 Forward-Port-Of: odoo/enterprise#79450 Forward-Port-Of: odoo/enterprise#75552
Original PR description
When an employee takes a leave, the private car reimbursement amount is reduced by a certain amount. However, when they take multiple leaves, the computation doesn't follow. This commit fixes the issue. task-4353922 Forward-Port-Of: odoo/enterprise#79450 Forward-Port-Of: odoo/enterprise#75552
This commit fixes an issue with knowledge's members permission computation. If the additional fields given to the method weren't valid fields, the computation would crash and return an error. With this fix we filter the valid additional_fields provided so that we only use those for the computation. task-4562838 Forward-Port-Of: odoo/enterprise#79221
Original PR description
This commit fixes an issue with knowledge's members permission computation. If the additional fields given to the method weren't valid fields, the computation would crash and return an error. With this fix we filter the valid additional_fields provided so that we only use those for the computation. task-4562838 Forward-Port-Of: odoo/enterprise#79221
This commit adds some QoL improvements on l10n_uy_edi when creating an Uruware testing account, as listed: - if in test mode, skip the uuid validation - if in test mode, use the current user email address for the contact for Uruware to send the credentials - in the successful event notification, display the email address where the credentials will be sent from Uruware - add cooldown period of 24 hours everytime a successful request for creating uruware account is sent related IAP PR: ht
Original PR description
This commit adds some QoL improvements on l10n_uy_edi when creating an Uruware testing account, as listed: - if in test mode, skip the uuid validation - if in test mode, use the current user email address for the contact for Uruware to send the credentials - in the successful event notification, display the email address where the credentials will be sent from Uruware - add cooldown period of 24 hours everytime a successful request for creating uruware account is sent related IAP PR: https://github.com/odoo/iap-apps/pull/974 task-id: 4411564 Forward-Port-Of: odoo/enterprise#78008
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
Original PR description
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
Forward-Port-Of: odoo/enterprise#79261
Original PR description
Forward-Port-Of: odoo/enterprise#79261
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423
Original PR description
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423