Wednesday, October 30, 2024
22 changes · saas-17.2
Miscellaneous changes
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from
Original PR description
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by…
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from account.tax records. It's not always going to match. It's not possible to fix this by externally calculating taxes on the down payment invoice. The single down payment line cannot accomodate all different tax categories. Creating a down payment line per tax category (e.g. avatax_category_id) was considered, but a specific down payment product would need to be created per used tax category which would clutter the database. On top of that, down payment products are removed in later versions [1] which would complicate this approach even further. This solves the issue by not calculating taxes on down payments at all. The down payment invoice will not be sent to external tax calculators. The resulting down payment lines on the SO won't have taxes set, and those lines will be excluded from the request to the external tax calculator. The final, "regular invoice" transaction will happen as if no down payments were made. The down payment lines won't be sent, so this will look like a regular invoice from the external calculator's view. By default, the downpayment lines equal the subtotal of the selected down payment amount. We remove tax_ids from the lines because we cannot count on calculating tax locally (see above). To keep the behavior analogous we override the downpayment wizard to create a single down payment line with a total equal to the entered total in the wizard. [1] odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5 opw-3971513 Forward-Port-Of: odoo/enterprise#70517
Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error. Backport of https://github.com/odoo/enterprise/pull/66479 opw-4292494 Forward-Port-Of: odoo/enterprise#73028
Original PR description
Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error. Backport of https://github.com/odoo/enterprise/pull/66479 opw-4292494 Forward-Port-Of: odoo/enterprise#73028
Collection of small shop floor fixes for v17. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#70704
Original PR description
Collection of small shop floor fixes for v17. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#70704
**Current behavior:** Return labels are being generated with the `shipper` field set to the partner defined on the delivery picking (i.e., customer). **Expected behavior:** `shipper` should match the `ship_to` field (the original sender) as this field informs who gets billed for the return shipment. **Steps to reproduce:** Generate a return label with `delivery_ups_rest`. **Cause of the issue:** The return label is generated with `shipper=picking.partner_id`. **Fix:** Set it to
Original PR description
**Current behavior:** Return labels are being generated with the `shipper` field set to the partner defined on the delivery picking (i.e., customer). **Expected behavior:** `shipper` should match the `ship_to` field (the original sender) as this field informs who gets billed for the return shipment. **Steps to reproduce:** Generate a return label with `delivery_ups_rest`. **Cause of the issue:** The return label is generated with `shipper=picking.partner_id`. **Fix:** Set it to `shipper=picking.picking_type_id.warehouse_id.partner_id` (which matches the `ship_to` argument). opw-4147118 Forward-Port-Of: odoo/enterprise#72482
Some reports have been edited to have qweb default content that was meant to only be used from within studio. ```xml <t t-field="some_field">studio placeholder</t> ``` This content is displayed if the evaluated value is either False or None. This can also happen outside studio, if the field is not required. An attribute `data-oe-demo` was introduced for t-fields. ```xml <t t-field="some_field" data-oe-demo="studio placeholder"/> ``` This attribute was introduced for t-field no
Original PR description
Some reports have been edited to have qweb default content that was meant to only be used from within studio. ```xml <t t-field="some_field">studio placeholder</t> ``` This content is displayed if the evaluated value is either False or None. This can also happen outside studio, if the field is not required. An attribute `data-oe-demo` was introduced for t-fields. ```xml <t t-field="some_field" data-oe-demo="studio placeholder"/> ``` This attribute was introduced for t-field nodes in order to only display placeholder content inside the report editor. We didn't introduce it for `t-out` as it was possible to change the expression `<t t-out="obj.prop"/>` -> `<t t-out="obj.prop or ''"/>` While this definitely works, the attribute better signals the intent of the change. We thus add support for the attribute on t-out. Forward-Port-Of: odoo/enterprise#72967
Add support for connecting to the MyInvois API, in order to send and receive E-Invoices. see https://github.com/odoo/iap-apps/pull/849 Task id # 3953659 Forward-Port-Of: odoo/odoo#174813
Original PR description
Add support for connecting to the MyInvois API, in order to send and receive E-Invoices. see https://github.com/odoo/iap-apps/pull/849 Task id # 3953659 Forward-Port-Of: odoo/odoo#174813
Issue found at commit: https://github.com/odoo/odoo/commit/0e8f3d5c42b4f219e4e7db6915dd1dd7ec45e4b4 After the above mentioned commit when using eWaybill with e-Invoicing the log note of ewaybill i.e. ``` E-wayBill Sent Number -> 0 Validity -> None ```  where as in the response attachment of eWaybill, the ewaybill number does exist In this commit, we resolve the above issue and the correct ewaybil
Original PR description
Issue found at commit: https://github.com/odoo/odoo/commit/0e8f3d5c42b4f219e4e7db6915dd1dd7ec45e4b4 After the above mentioned commit when using eWaybill with e-Invoicing the log note of ewaybill i.e. ``` E-wayBill Sent Number -> 0 Validity -> None ```  where as in the response attachment of eWaybill, the ewaybill number does exist In this commit, we resolve the above issue and the correct ewaybill number gets logged opw-4280093 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#185680
**Behaviour before PR:** In chatGPT prompt dialog, scroll position is not set to the latest message automatically after hitting 3-4 prompts. User has to scroll to bottom manually. **After this PR:** This commit aims to make sure that the scroll postion is set to the latest message after submitting prompt. task-4256085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183862
Original PR description
**Behaviour before PR:** In chatGPT prompt dialog, scroll position is not set to the latest message automatically after hitting 3-4 prompts. User has to scroll to bottom manually. **After this PR:** This commit aims to make sure that the scroll postion is set to the latest message after submitting prompt. task-4256085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183862
Currently, when sending a Bis 3 xml to Pagero, which in turn sends it to Chorus Pro, the invoice is rejected by Chorus. This is because the `PartyIdentification` tag for the `AccountingSupplierParty` should be filled with the siret of the supplier if it is located in France, or with the VAT if it is located in the EU. Surprisingly, the xml received by Chorus contains a `PartyIdentification` that has most probably be added by Pagero, but it is filled with a VAT, and causes a rejection from
Original PR description
Currently, when sending a Bis 3 xml to Pagero, which in turn sends it to Chorus Pro, the invoice is rejected by Chorus. This is because the `PartyIdentification` tag for the `AccountingSupplierParty` should be filled with the siret of the supplier if it is located in France, or with the VAT if it is located in the EU. Surprisingly, the xml received by Chorus contains a `PartyIdentification` that has most probably be added by Pagero, but it is filled with a VAT, and causes a rejection from Chorus since the supplier is french. opw-4139689 Forward-Port-Of: odoo/odoo#184871
Currently, the invisible fields are considered in the export default fields. It doesn't make sense from a user perspective as those are generally technical fields used for computation. This wasn't the case prior to v17. The fix is to filter the invisible fields. task-4277023 Forward-Port-Of: odoo/odoo#184719
Original PR description
Currently, the invisible fields are considered in the export default fields. It doesn't make sense from a user perspective as those are generally technical fields used for computation. This wasn't the case prior to v17. The fix is to filter the invisible fields. task-4277023 Forward-Port-Of: odoo/odoo#184719
In 865baf9ef154e2a36817e40a50e09d5e98cf95f9, makeAsyncHandler has been incorrectly modified so that the promise rejection is consumed by the catch, instead of letting it bubble up through a finally. Indeed, contrarily to makeButtonHandler, makeAsyncHandler doesn't create a new Promise object. This means that the finally is applied on the result itself. In makeButtonHandler, the then handler returns a new Promise that is different from result, but that will be rejected if result is rejected.
Original PR description
In 865baf9ef154e2a36817e40a50e09d5e98cf95f9, makeAsyncHandler has been incorrectly modified so that the promise rejection is consumed by the catch, instead of letting it bubble up through a finally. Indeed, contrarily to makeButtonHandler, makeAsyncHandler doesn't create a new Promise object. This means that the finally is applied on the result itself. In makeButtonHandler, the then handler returns a new Promise that is different from result, but that will be rejected if result is rejected. This is why in this case we need to hide that extra rejection by swallowing it in the onRejected argument, instead of using a finally. Task-Id: None Forward-Port-Of: odoo/odoo#183894
Payments initiated by the customer from the payment form could sometimes lead to multiple charges if a webhook notification would arrive at the same time as the payment request's response. This is due to the webhook acquiring a lock in the database when updating the transaction's state, followed by the processing of the payment request's response trying to do the same and thus encountering a concurrent access error. The payment request is thus retried and a new charge is created on Adyen side.
Original PR description
Payments initiated by the customer from the payment form could sometimes lead to multiple charges if a webhook notification would arrive at the same time as the payment request's response. This is due to the webhook acquiring a lock in the database when updating the transaction's state, followed by the processing of the payment request's response trying to do the same and thus encountering a concurrent access error. The payment request is thus retried and a new charge is created on Adyen side. This commit fixes the issue by passing an idempotency key with the payment request. If a payment request is inadvertently retried, Adyen silently ignores it and returns the same response as for the initial request. The response is processed again in Odoo and the customer is smoothly redirected to the payment landing page. Forward-Port-Of: odoo/odoo#185720 Forward-Port-Of: odoo/odoo#184919
Steps to reproduce: 1. Go to a website page (in edit mode) > Switch the header template to `"Menu with Search Bar"`. 2. Set a highlight effect on the text element in the top section of the header. 3. The highlight keeps adapting itself infinitely. Technical details: After [1], two header navbars were added in the DOM (for the desktop view and mobile). Which means that the targeted text field is also duplicated and every change on it in Desktop will be reflected in the "invisib
Original PR description
Steps to reproduce: 1. Go to a website page (in edit mode) > Switch the header template to `"Menu with Search Bar"`. 2. Set a highlight effect on the text element in the top section of the header. 3.…
Steps to reproduce:
1. Go to a website page (in edit mode) > Switch the header template to
`"Menu with Search Bar"`.
2. Set a highlight effect on the text element in the top section of the header.
3. The highlight keeps adapting itself infinitely.
Technical details:
After [1], two header navbars were added in the DOM (for the desktop
view and mobile). Which means that the targeted text field is also
duplicated and every change on it in Desktop will be reflected in the
"invisible" mobile version.
When the text is highlighted, the highlight observers are also adapting
the content on both navbars... To understand the conflict, here is an
example of the behaviour causing the infinite loop:
**a.** DESKTOP TEMPLATE > Set a highlight on the text field:
```xml
<span class="o_text_highlight">
<span class="o_text_highlight_item">
Text content.
<svg.../> // SVG adapted to text dimensions.
</span>
```
**b.** MOBILE TEMPLATE > The "field observer" will set the same content on
the "invisible" mobile version:
```xml
<span class="o_text_highlight">
<span class="o_text_highlight_item">
Text content.
<svg.../> // SVG adapted to the desktop text dimensions.
</span>
```
**c.** MOBILE TEMPLATE > The "highlights adaptation system" detects the
changes on the hidden mobile field and adapts the highlight:
```xml
<span class="o_text_highlight">
<span class="o_text_highlight_item">
Text content.
<svg.../> // SVG adapted to the mobile text dimensions (0×0).
</span>
```
**d.** DESKTOP TEMPLATE > The "field observer" will set the same content on
the desktop version, which automatically triggers the highlight size adaptations...
**e.** Same as [**b**].
Infinitely...
In this very specific case, the text content is the same, only the
highlight path is different (because one of the field duplicates is
visible, and the other is hidden).
The goal of this commit is to fix this behaviour by preventing the
highlight's mutation observer from adapting invisible content.
This way, the field synchronization mechanism will always set the same
highlight SVG on the hidden duplicate too (*).
[1]: https://github.com/odoo/odoo/pull/119650
(*): Remarks:
- This won't have an impact on the saved content: We remove all size
related DOM (SVG paths, line breaks,...) before the "save" and we
only keep minimal information needed to rebuild the highlights.
- Also, having a non-adapted effect on the hidden copy of the field is
not an issue here since the "highlight resize observer" will immediately
fix it once displayed (e.g. when switching to mobile preview).
opw-4183587
task-4270159
Forward-Port-Of: odoo/odoo#183414Before this PR, pressing the `Escape` key in an open thread action within the chat window would close the entire chat window rather than just the thread action. This PR fixes the issue by ensuring `Escape` closes only the active thread action. task-4290661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185503
Original PR description
Before this PR, pressing the `Escape` key in an open thread action within the chat window would close the entire chat window rather than just the thread action. This PR fixes the issue by ensuring `Escape` closes only the active thread action. task-4290661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185503
Update branding logo and icon in windows installer. Old forgotten task Task-2862802 Forward-Port-Of: odoo/odoo#185650
Original PR description
Update branding logo and icon in windows installer. Old forgotten task Task-2862802 Forward-Port-Of: odoo/odoo#185650
Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification challenge` record 3) Create a new `goal` in the gamification challenge 4) Make sure the goal has the definition as `Automatic: sum on a field` 5) Select the model as `account` 6) Uninstall the invoicing module and start the `challenge` of that gamification. Error:- ``` KeyError: Fals
Original PR description
Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification…
Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification challenge` record 3) Create a new `goal` in the gamification challenge 4) Make sure the goal has the definition as `Automatic: sum on a field` 5) Select the model as `account` 6) Uninstall the invoicing module and start the `challenge` of that gamification. Error:- ``` KeyError: False ``` The value of the model_id became `False` when the user deletes a module used in goal. This leads to a traceback as model_id is used for the reference of obj https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165 We can resolve this issue by adding `ondelete='cascade'` in the field definition. Where the record will be deleted if the corresponding model is uninstalled. sentry-4089991441 Forward-Port-Of: odoo/odoo#180307
Currently, when the stock scheduler is run, a new cursor is created and the result is rolled back even if all tasks succeeded. Even though tasks themselves are not rolled back because they are run using new other cursors, rolling it back is not correct and it makes harder to test the scheduler feature. The rollback was introduced in da6bd90e by mistake. This commit makes the transaction to be rolled back only when the current transaction actually failed. --- I confirm I have signe
Original PR description
Currently, when the stock scheduler is run, a new cursor is created and the result is rolled back even if all tasks succeeded. Even though tasks themselves are not rolled back because they are run using new other cursors, rolling it back is not correct and it makes harder to test the scheduler feature. The rollback was introduced in da6bd90e by mistake. This commit makes the transaction to be rolled back only when the current transaction actually failed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175621
Problem: Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context. Solution: Prevent the selection of actions that include `active_id` in their context from being set as home actions. Steps to reproduce: 1. Enable debug mode. 2. Navigate to `Settings / Users & Companies / Users`. 3. Select the current user from the list. 4. Under Preferences / Menus Customization set "H
Original PR description
Problem: Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context. Solution: Prevent the selection of actions that include `active_id` in their context from being set as home actions. Steps to reproduce: 1. Enable debug mode. 2. Navigate to `Settings / Users & Companies / Users`. 3. Select the current user from the list. 4. Under Preferences / Menus Customization set "Home Action" to "Quotations and Sales." 5. After that: each time you go to backend homepage (/) you get a traceback error instead of the app dashboard opw-4283156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185815 Forward-Port-Of: odoo/odoo#185319
[IMP] l10n_es: Add new tax grid for es *Create a new tax grid mod390[110] *Add this tax grid to all taxes in l10n_es on Distribution lines that already have mod303[120] *Make the modelo 390 use that tax grid on the line 110 task-4058894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175354
Original PR description
[IMP] l10n_es: Add new tax grid for es *Create a new tax grid mod390[110] *Add this tax grid to all taxes in l10n_es on Distribution lines that already have mod303[120] *Make the modelo 390 use that tax grid on the line 110 task-4058894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175354
Steps to reproduce ================== - Open any list/kanban view - Add a custom filter - Select a datetime field, for example Created on => The default value is the current datetime If you click on the datetime field, the datetimepicker is opened but the minutes are set to 00. If you click on apply, 00 is not set. Cause of the issue ================== The DateTimeInput has a rounding props (by default 5). If we open it with a value that has the minutes not rounded by
Original PR description
Steps to reproduce ================== - Open any list/kanban view - Add a custom filter - Select a datetime field, for example Created on => The default value is the current datetime If you click on the datetime field, the datetimepicker is opened but the minutes are set to 00. If you click on apply, 00 is not set. Cause of the issue ================== The DateTimeInput has a rounding props (by default 5). If we open it with a value that has the minutes not rounded by that amount, 00 will be displayed instead because a <select/> is used, and only the rounded values are present. Solution ======== Round the default value to the nearest 5 minutes opw-4170906 Forward-Port-Of: odoo/odoo#183938
Use normalized emails for comparison to avoid issues linked to formatting. Task-4281171: [mail] {email/smtp}_from normalized comparison Forward-Port-Of: odoo/odoo#185766 Forward-Port-Of: odoo/odoo#185749
Original PR description
Use normalized emails for comparison to avoid issues linked to formatting.
Task-4281171: [mail] {email/smtp}_from normalized comparison
Forward-Port-Of: odoo/odoo#185766
Forward-Port-Of: odoo/odoo#185749opw-3971513 Forward-Port-Of: odoo/odoo#181103
Original PR description
opw-3971513 Forward-Port-Of: odoo/odoo#181103