Point of Sale users now have a clear discard button when entering numbers in popup dialogs. This makes it easier to cancel unwanted input and reduces the chance of applying accidental changes during POS workflows.

In this commit:
===============
A discard button for the NumberPopup Dialogue is added in the footer.

Task- 4210911

The Point of Sale closing popup now arranges its action buttons in a clearer two-line layout on mobile screens. This makes the closing workflow easier to use on smaller devices and reduces cramped or awkward button wrapping.

Changed the buttons in the closing_popup for mobile view to be in two lines with container grid view instead of flex-wrap



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

On smaller point of sale screens, opening the cart now keeps the on-screen numpad hidden by default. This gives cashiers more room to review the cart and reduces visual clutter during checkout.

-When the UI is small and we open the cart, deselect the orderline so that the numpad remain down

task-id: 4167563

This change makes the delete action in Planning’s Gantt popover easier to customize, enabling better handling of recurring planning entries. It supports a smoother user experience when deleting repeated shifts or slots, especially in planning workflows connected to sales.

As of now the gantt popover delete button is added through gantt-popover template which is making it harder to extend its functionality.

In this PR we move the button to the ganttPopoverProps. We can pass the button through JS side, thus being to extend it's functionality of reccurence deletion.

task-4224792

The UrbanPiper integration now shows the meal type field in the product list by default after installation. Users can still hide this option if it is not needed, making product setup clearer while keeping the view flexible.

In this commit:
-------------------
- We have added meal type option in product template list view, by default shown when we install urban_piper but we will be able to hide from options.

task- 4075159

Creating an employee from a candidate with recorded skills no longer fails because the same skill information was being copied twice. This ensures recruiters can smoothly convert candidates into employees without hitting a duplicate-skill error.

Steps
---
* Create a candidate
* Give them a skill
* *Create Employee*
* => Traceback -> "Two levels for the same skill is not allowed"

Cause
---
* on `hr.employee.skill` we have a unique constraint on the skill
  employee pair
* but when creating an employee we would attepmt to create the skills
  twice, once through regualr create and once from the override of
  `_update_employee_from_candidate` call in the write

Fix
---
Remove the `_update_employee_from_candidate` method, which seems
unnecessary.

task-4207776

Paid point-of-sale orders can no longer be deleted before they have been synced to the backend. This helps prevent lost sales records and reduces the risk of discrepancies between the register and central system.

Before this commit it was possible to delete a paid order that wasn't yet synced to the backend. This commit adds a check to prevent this behavior.

taskId: 4250522

This fixes an issue that prevented users from printing quotations when working with a Brazilian company. The Brazilian sales tax totals template now receives the needed quotation values correctly, avoiding the error during report generation.

Currently, you can't print quotations with a Brazilian company.

### Steps to reproduce

* install `l10n_br_sales`
* switch to a Brazilian company
* attempt to print a quotation

You should be met with the following traceback:
```
TypeError: 'NoneType' object is not subscriptable
Template: l10n_br_sales.document_tax_totals_brazil
Path: /t/tr[1]
Node: <tr t-if="\'cash_rounding_base_amount_currency\' in tax_totals"/>
```

### Cause

The `l10n_br_sales.document_tax_totals_brazil` currently overrides `sale.document_tax_totals` using the following code:

```xml
<xpath expr="//t[@t-call='sale.document_tax_totals']" position="replace">
    <t t-call="l10n_br_sales.document_tax_totals_brazil"/>
</xpath>
```

However, there was a recent update (d0e7be7832672d476f1b289af52d3a425990d719) to the `sale.document_tax_totals` call, as shown below:

```diff
-    <t t-set="tax_totals" t-value="doc.tax_totals"/>
-    <t t-call="sale.document_tax_totals"/>
+    <t t-call="sale.document_tax_totals">
+        <t t-set="tax_totals" t-value="doc.tax_totals"/>
+        <t t-set="currency" t-value="doc.currency_id"/>
+    </t>
```

With this change, the override in `l10n_br_sales.document_tax_totals_brazil` will no longer have access to the `tax_totals` and `currency` values because they are now passed inside the `t-call` block of `sale.document_tax_totals`.

opw-4239563

Repair order confirmations no longer show an unnecessary warning when no parts have been picked yet. This makes repair behavior more consistent with stock operations and reduces confusion for users during validation.

This commit makes the behavior of the warning on repair order confirmation more similar to stock pickings. The warning now doesn't show if all the moves are not picked, since they'll be all picked during the validation process.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This fixes an automated live chat test so it works correctly in Odoo Community, where the Enterprise home menu is not available. It helps keep live chat quality checks reliable across both Community and Enterprise editions without changing the customer-facing live chat feature.

Bug: In community, there is no home_menu.
Fix: We create a specific step for community and keep the current for enterprise.

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

Fixes an issue where the “See record” menu option did not appear when users right-clicked certain cells in spreadsheet lists using generated sequences. This makes it easier for users to open the related record from any relevant list cell, improving navigation consistency.

Steps to reproduce:

- insert a list in a spreadsheet
- in a cell, write =ODOO.LIST(1, sequence(4), "foo")
- right click any cell but the top-left cell

=> the "See record" menu item is missing

Task: 4220373


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Kiosk ordering now stops gracefully when an order cannot be created, such as during an offline connection. Instead of showing a technical error, users see an appropriate message, improving the self-ordering experience.

Traceback is shown when making an order in kiosk because we try to proceed even if no order is created in the backend. In this fix, we return early in the `confirmOrder` procedure when no order is created (e.g. when offline).

The following is shown instead of the traceback:

![Screenshot 2024-09-25 at 13 17 42](https://github.com/user-attachments/assets/c87d241b-2878-444b-a2cf-96cf8ce5ba27)

This fixes a form validation issue where fields that were no longer required could remain marked as invalid after a related field was filled in. Users can now save records normally without entering and removing temporary values, improving reliability in forms such as approval rules.

Have a form view with two fields A and B, which are both required if the other one is unset:
```xml
<form>
    <field name="A" required="not B"/>
    <field name="B" required="not A"/>
</form>
```

Open a form view and unset A and B. Try to save: both fields are marked as invalid (highlighted in red). Fill one of them and click out.

Before this commit, the other field was still marked as invalid. Worse: the save button was still disabled. One thus had to fake a value in that field, then remove it, to be able to save the record.

The issue occurred because when a field changed, we only removed that field from the list of invalid field. We didn't considerer other invalid fields (unset, but required) that could become valid with the change because they are no longer required. With this commit, we remove from the list of invalid fields those that were unset and required, but are no longer required now.

The issue could be reproduced in the `studio.approval.rule` form view with fields `approver_ids` and `approval_group_id`.

Followup of task~4122644

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

This fix restores invoice printing for Saudi companies after a recent internal tax calculation change caused an error. Businesses using Saudi e-invoicing can generate and print invoices again without hitting a traceback.

### Steps to reproduce

* install `l10n_sa_edi`
* switch to a Saudi company
* create an invoice and attempt to print it

You should be met with a traceback:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
KeyError: 'id'
Template: l10n_gcc_invoice.arabic_english_invoice
Path: /t/t/div/table/tbody/t[3]/tr/t[1]/td[2]/span
Node: <span class="text-nowrap" t-field="line.l10n_gcc_invoice_tax_amount"/>
```

### Cause

The calculation of `l10n_gcc_invoice_tax_amount` relies on code that was recently refactored, and therefore doesn't work anymore

opw-4243831

The Ecuadorian electronic invoicing module temporarily hides the withholding subtotal widget in the withholding wizard and form view. This prevents users from encountering a JavaScript error while working with withholding documents until the widget issue can be resolved.

Hide temporarily withhold subtotals widget in withhold wizard and form view
 There is an JS error about account-tax-totals-field-for-withhold widget

This fix ensures additional Ecuadorian companies can be created without running into journal access errors. It also sets up default withholding accounts automatically, reducing manual configuration and setup issues for new companies.

In v18 I installed the EC localization and the first EC company was created.
I try to create the second  EC company. 
Cannot create and I get the following error

Solution
Use `@template` annotation to create journals in l10n_ec_edi
Additionally, we call the method `_l10n_ec_configure_default_withhold_accounts` in load() to set accounts by default

![image](https://github.com/user-attachments/assets/a4060cd9-0bb9-406a-adce-fd2bee17a39d)

This fix prevents an error when saving Ecuadorian vendor bills that include reimbursement lines. It helps accounting users complete reimbursement-related bills reliably without interruption.

- Replicate error in runbot v18:
 1. Create a Vendor Bill with partner 'Instituto Ecuatoriano de Seguridad Social'
 2. Add a reimbursement line with all the fields set up
 3. Press the save button

- Solution: Call the method _round_base_lines_tax_details before the _get_tax_totals_summary method to add the raw base amount in the base lines dictionary

- Screenshot 18.0 runbot

![image](https://github.com/user-attachments/assets/3237f7ba-3c6b-4c30-bb03-e68a07e23fe4)

Creating an employee from a candidate with skills no longer triggers an error caused by duplicate skill records. This ensures recruiters can complete the candidate-to-employee conversion smoothly without manual workarounds.

Steps
---
* Create a candidate
* Give them a skill
* *Create Employee*
* => Traceback -> "Two levels for the same skill is not allowed"

Cause
---
* on `hr.employee.skill` we have a unique constraint on the skill employee pair
* but when creating an employee we would attepmt to create the skills twice, once through regualr create and once from the override of `_update_employee_from_candidate` call in the write

Fix
---
Remove the `_update_employee_from_candidate` method, which seems unnecessary.

task-4207776

The guided tour now clearly highlights the step for going back to edit mode from a Field Service report. This helps users understand the navigation step instead of seeing an unexplained click action.

**Before this PR:**
- The tour included a step that was supposed to display a tooltip with the message and position it to the right, but it did not include a click action.
- The subsequent step triggered by `.alert-info a.alert-link:contains(Back to edit mode)` only performed
 a click action without displaying any tooltip or additional content.
- So, the navigating back step was not properly highlighted .

**After this PR:**
- Updated the step triggered by `.alert-info a.alert-link:contains(Back to edit mode)` to include `content` and `tooltipPosition`.

task-4159812

Subscription invoice tracking has been cleaned up so the latest invoiced date is recalculated when invoices change, such as being reset or refunded. This helps keep subscription billing information accurate and reduces ambiguity in the underlying process.

In this commit we try to clean some ambiguity to improve the code readability.

The mobile web interface now avoids triggering native mobile app communication and related permission prompts unless the feature is actually used. This reduces unnecessary Bluetooth permission requests and prevents startup error noise in the mobile app, improving the first-use experience.

This commit adds a system to enable the loop communication with the native Odoo Mobile App only when the bus is actually used.

Editing comments in spreadsheets now works without causing an error. Cells with comments also correctly show their visual triangle marker again, making comments easier to spot.

This update tightens automated checks for spreadsheet list records so they verify true/false results precisely. It helps prevent incorrect behavior from slipping through when users open or inspect records from spreadsheet-backed lists.

Adapt some test to strictly check against boolean values.

Task: 4220373

This change corrects how document-related email templates identify recipients. It helps ensure emails are sent to the intended contacts reliably, reducing the risk of delivery issues caused by incorrectly configured templates.

Do not use a partner ID in email_to. And use partner_to when using partners.

Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request. This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the se

Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request.

This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the second attempt was working thanks to the change of transaction state on the provider side.

This commit allows Authorize.net transactions to move from the `done` state to the `cancel` state. It is not necessary to ensure we are in the context of a refund because we always check that a transaction is in the `authorized` state before attempting to void it.

opw-4201355

Forward-Port-Of: odoo/odoo#183184

Steps to reproduce the bug: - Enter edit mode. - Drag and drop 2 "Table of Content" snippets onto the page. - For both snippets, enable the "Hide on mobile" option. - Save the page. - Click on "switch to mobile view" button. - Enter edit mode again. - Bug: there is a traceback. or also - Drop a "Table of Content" snippet. - Hide it on desktop. - Display the snippet by clicking on it in the "Invisible Elements" section. - Click again on hide on desktop. The bug occurs starti

Steps to reproduce the bug:

- Enter edit mode.
- Drag and drop 2 "Table of Content" snippets onto the page.
- For both snippets, enable the "Hide on mobile" option.
- Save the page.
- Click on "switch to mobile view" button.
- Enter edit mode again.
- Bug: there is a traceback.

or also

- Drop a "Table of Content" snippet.
- Hide it on desktop.
- Display the snippet by clicking on it in the "Invisible Elements"
section.
- Click again on hide on desktop.

The bug occurs starting from commit [1], where a listener was added to
the scroll element in the "Table of Contents" public widget. When this
listener is removed in the destroy function, a traceback occurs if
multiple "Table of Contents" widgets are hidden. This happens because we
try to remove the listener while the widget's start function has not
finished yet, which means the listener we try to remove has not been
instantiated.

To fix this, we now await properly for the end of the start function.

[1]: https://github.com/odoo/odoo/commit/178825649fdb6fdd66ebc65732b5e903c2fca694

task-4160033
opw-4228666
opw-4226783

Forward-Port-Of: odoo/odoo#182936

Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks, the `sendDraftToServer` function can be called from different places, some of which lack this guard. For example, the `setTable` function triggers order syncing but does not have the duplicate protection. Steps to reproduce: 1. Create an order in a table 2. Block the internet connection to preven

Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks, the `sendDraftToServer` function can be called from different places, some of which lack this guard. For example, the `setTable` function triggers order syncing but does not have the duplicate protection.

Steps to reproduce:
1. Create an order in a table
2. Block the internet connection to prevent the order from syncing
2. Go to the floor screen
3. Re-enable a slow internet connection
4. Quickly click on two different tables without orders

This behavior results in duplicate order creation.

Since it's not possible to enforce uniqueness on the server side via a constraint, this commit introduces a debouncing mechanism in the `_save_to_server` function. This ensures that an order cannot be sent to the server more than once concurrently, preventing duplicate creation.

opw-4136101

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#181881
Forward-Port-Of: odoo/odoo#180278

Before this commit, loading 20,000 products into the PoS and adding a product to an order was slow due to multiple writes to the IndexedDb. This commit optimizes the process by not saving ongoing order's products in the IndexedDb, as they can be loaded as needed. Missing products are loaded when loading the orderlines. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183189

Before this commit, loading 20,000 products into the PoS and adding a product to an order was slow due to multiple writes to the IndexedDb. This commit optimizes the process by not saving ongoing order's products in the IndexedDb, as they can be loaded as needed. Missing products are loaded when loading the orderlines.

opw-4200540

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#183189

Before this commit, attribute values marked as "Free text" would not appear on the orderline unless text was added to them. This behavior was inconsistent with the Sale module, where such attributes are displayed regardless. opw-4218992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182972

Before this commit, attribute values marked as "Free text" would not appear on the orderline unless text was added to them. This behavior was inconsistent with the Sale module, where such attributes are displayed regardless.

opw-4218992

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182972

Before this commit, adding a product to the cart with 20,000 products was slow due to the time taken to render the screen and execute the productsToDisplay function. This commit optimizes the productsToDisplay function, making it 10 times faster with large product counts. opw-4247716 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183193

Before this commit, adding a product to the cart with 20,000 products was slow due to the time taken to render the screen and execute the productsToDisplay function. This commit optimizes the productsToDisplay function, making it 10 times faster with large product counts.

opw-4247716

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#183193

Fix the code at [1], Where the system tries to update the payment method, Modify the code to handle this issue where the network value might not exist. This can be done by providing a default value for ```payment_method_type``` if the network value is not present. Link [1]: https://github.com/odoo/odoo/blob/d30f41a49f614456c71a0a6974325030f552a0db/addons/payment_razorpay/models/payment_transaction.py#L391-L392 Sentry-5950544641 --- I confirm I have signed the CLA and read the PR guidel

Fix the code at [1], Where the system tries to update the payment method, Modify the code to handle this issue where the network value might not exist. This can be done by providing a default value for ```payment_method_type``` if the network value is not present.

Link [1]: https://github.com/odoo/odoo/blob/d30f41a49f614456c71a0a6974325030f552a0db/addons/payment_razorpay/models/payment_transaction.py#L391-L392

Sentry-5950544641

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182617

This commit ensures that event listeners are removed using their prototype's `removeEventListener` method, as to ensure that any override will not be called during the cleanup. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183099

This commit ensures that event listeners are removed using their prototype's `removeEventListener` method, as to ensure that any override will not be called during the cleanup.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#183099

Community-side fix for creating move lines instead of moves for production backorders. This change ensures that product quantity which was *intended* to be used by one production will rightly get reserved by that production's backorder. Additionally, we now use more care when marking moves as picked because this field has an inverse which will mark all of the move's move lines as consumed / done, despite them being incomplete. opw-4148050 Forward-Port-Of: odoo/odoo#182960 Forward-Po

Community-side fix for creating move lines instead of moves for
production backorders. This change ensures that product quantity
which was *intended* to be used by one production will rightly
get reserved by that production's backorder.

Additionally, we now use more care when marking moves as picked
because this field has an inverse which will mark all of the
move's move lines as consumed / done, despite them being
incomplete.

opw-4148050

Forward-Port-Of: odoo/odoo#182960
Forward-Port-Of: odoo/odoo#180617

Product with long names where not shown completely on the kitchen receipt Steps to reproduce: ------------------- * Add a kitchen printer to your PoS setup * Create a product with a really long name * Open PoS and complete an order with the product > Observation: The kithen receipt doesn't show the full name opw-4221336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182666

Product with long names where not shown completely on the kitchen receipt

Steps to reproduce:
-------------------
* Add a kitchen printer to your PoS setup
* Create a product with a really long name
* Open PoS and complete an order with the product
> Observation: The kithen receipt doesn't show the full name

opw-4221336
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182666

Steps to reproduce the bug: - In Website edit mode. - click on the navbar. - For the "Format" option of the navbar, open the color picker. - Select any colors of the theme colors or any grayscale color. - Bug: the color is not applied to the navbar links. The bug has existed since commit [1], which added the feature to set a custom text color for the header. Two problems were there from the start: - First, the variable wasn't saved inside quotes like it should have been. - Seco

Steps to reproduce the bug:

- In Website edit mode.
- click on the navbar.
- For the "Format" option of the navbar, open the
color picker.
- Select any colors of the theme colors or any grayscale color.
- Bug: the color is not applied to the navbar links.

The bug has existed since commit [1], which added the feature to set a
custom text color for the header. Two problems were there from the
start:

- First, the variable wasn't saved inside quotes like it should have
been.
- Second, there was no function to convert theme colors (e.g.,
"o-color-1") into hexadecimal values when generating the CSS.

Because of this, only non-theme colors worked with this option. This
commit fixes the issue but ensures that it doesn't change anything for
users who already applied a color that didn’t work before. This way,
their navbar text color won't suddenly change after the fix without
them understanding why.

[1]: https://github.com/odoo/odoo/commit/d54028e5ed33a0258d3f2aeeaea338ac04f8d402

opw-4065019

Forward-Port-Of: odoo/odoo#182570

**Description of the issue/feature this PR addresses:** When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App. **Steps to Reproduce:** - Install the `lunch` module - Go to Lunch > Configuration > Locations - Delete all records - Access the Lunch App again **Traceback:** OwlError ``` Invalid props for component 'AutoComplete': 'value' is not a string ``` This error occurs at [1], where the given p

**Description of the issue/feature this PR addresses:**

When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App.

**Steps to Reproduce:**
- Install the `lunch` module
- Go to Lunch > Configuration > Locations
- Delete all records
- Access the Lunch App again

**Traceback:** OwlError
```
Invalid props for component 'AutoComplete': 'value' is not a string
```
This error occurs at [1], where the given props are empty.

This commit will resolve the above error by displaying a text message instead of trying to build a `Many2XAutocomplete` with empty values.

opw-4104561

[1]- https://github.com/odoo/odoo/blob/503c0d6f8fad09f5de678d8692fc283feac1b061/addons/lunch/static/src/components/lunch_dashboard.xml#L61

**Current behavior before PR:**
Without any record in the `lunch.location` model, the Lunch App cannot be accessed

**Desired behavior after PR is merged:**
Without any record in the `lunch.location` model, the Lunch App can be accessed, but a message "_No lunch locations available._" will be displayed in spite of the location.

**Screenshots**
Behavior without fix, with locations not yet deleted:
![lunch locations](https://github.com/user-attachments/assets/637eb09e-0bad-4034-acb9-21bcb337ad32)
Behavior with fix, with all locations deleted:
![No locations](https://github.com/user-attachments/assets/920f1c3e-2600-4e60-9968-1f5045517502)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182763
Forward-Port-Of: odoo/odoo#176135

Before this commit, special products, such as discount, could appear in the self-order menu. This commit ensures that such special products are not displayed, maintaining a cleaner and more relevant product selection for customers. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182981

Before this commit, special products, such as discount, could appear in the self-order menu. This commit ensures that such special products are not displayed, maintaining a cleaner and more relevant product selection for customers.

opw-4200540

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182981

**Before this commit:** - The existing selector fails due to the change in the the text of the `<a>` tag redirecting us to the survey. ref. to where it was changed--- https://github.com/odoo/odoo/pull/131710/files#diff-134fd6929e7c8db7a39038879bf9a01c9f4525ca8db1475974c74576ffd7e3fb --- **After this commit:** - The new selector ensures we get the tour pointer as desired. Task-**4207478** Forward-Port-Of: odoo/odoo#181837

**Before this commit:**
- The existing selector fails due to the change in the the text of the `<a>` tag
  redirecting us to the survey.

ref. to where it was changed---
https://github.com/odoo/odoo/pull/131710/files#diff-134fd6929e7c8db7a39038879bf9a01c9f4525ca8db1475974c74576ffd7e3fb

---

**After this commit:**
- The new selector ensures we get the tour pointer as desired.

Task-**4207478**

Forward-Port-Of: odoo/odoo#181837

Steps to reproduce: 1. Create a live session for a 'Quiz about your company' survey 2. Add images to your answers 2. Complete it with one user 3. Review your answer in the last 4. The images are getting overlap Technical Reason: on the user-side results page, images that were not properly handled were displayed at their default size. After this commit: it should be perfectly aligned. Task-4208130 Forward-Port-Of: odoo/odoo#181386

Steps to reproduce:
1. Create a live session for a 'Quiz about your company' survey
2. Add images to your answers
2. Complete it with one user
3. Review your answer in the last
4. The images are getting overlap

Technical Reason:
on the user-side results page, images that were not properly handled were displayed at their default size.

After this commit:
it should be perfectly aligned.

Task-4208130

Forward-Port-Of: odoo/odoo#181386

### Context : The changes introduced in https://github.com/odoo/odoo/pull/111575 seems to not have accounted for two things: 1) Running `.copy()` on the domain list object will create a shallow copy of the object. Thus, the sub-lists in the domain list are still assigned by reference. This means that when `id` gets replaced by `product_tmpl_id` (https://github.com/odoo/odoo/blob/ffcff5a784f40522ef9e3051ca3605465b99c718/addons/product/models/product_template.py#L543-L546), it actually also mu

### Context :
The changes introduced in https://github.com/odoo/odoo/pull/111575 seems to not have accounted for two things:

1) Running `.copy()` on the domain list object will create a shallow copy of the object. Thus, the sub-lists in the domain list are still assigned by reference. This means that when `id` gets replaced by `product_tmpl_id` (https://github.com/odoo/odoo/blob/ffcff5a784f40522ef9e3051ca3605465b99c718/addons/product/models/product_template.py#L543-L546), it actually also mutates the original `domain` variable.

2) Downstream when the conditional logic from https://github.com/odoo/odoo/pull/143543/files, i.e. https://github.com/odoo/odoo/blob/ffcff5a784f40522ef9e3051ca3605465b99c718/addons/product/models/product_template.py#L579C1-L580C93 gets triggered, it will create an invalid domain for the `product.template` model, because it tries to search based on `product_tmpl_id` instead of `id`.

In practice, when a DB is in a state that triggers the conditional logic, the user will face a non-descript traceback about an unresolved promise when trying to search for alternative products in the  product From view (“Sales” tab).
Checking the back-end, we will actually find a traceback similar to:
```
Invalid field product.template.product_tmpl_id in leaf ('product_tmpl_id', '!=', 215)
```

### Proposed solution:
Since the original intent seems to be to create a deep copy of the original domain, as to not mutate it, we explicitly import the `copy` library and run the `deepcopy` method to achieve the original intent.

OPW-4232858

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182750

Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Popup" into the page. - Drag and drop a "Text" block into the page (note that the "Text" block must be dropped after the "Popup" for the bug to occur). - Enable the "Hide on desktop" option for the "Text" block. - There are now 2 elements in the "Invisible Elements" list of the snippet menu. They should be ordered as follows: "Popup" and below "Text". - Save the page. - Enter edit mode. - Click on "Popup" in the "In

Steps to reproduce the bug:

- In Website edit mode.
- Drag and drop a "Popup" into the page.
- Drag and drop a "Text" block into the page (note that the "Text" block must be dropped after the "Popup" for the bug to occur).
- Enable the "Hide on desktop" option for the "Text" block.
- There are now 2 elements in the "Invisible Elements" list of the snippet menu. They should be ordered as follows: "Popup" and below "Text".
- Save the page.
- Enter edit mode.
- Click on "Popup" in the "Invisible Elements" list of the snippet menu.
- Bug: a traceback occurs.

When we add options for a snippet, we also add the options of its parent snippets. But for "Popup" snippets, since commit [2], we don’t want to add their parent options. So, we don’t create an editor for the parents of a "Popup."

However, when adding the "Popup" options to the snippet menu, we still check if an editor exists for its parents to decide whether to add parent options. The problem is that an editor for one of the parents might have started being created for another snippet that shares the same parent, but the creation is not finished yet, which causes the bug.

To fix this, this commit stops adding parent options for snippets that shouldn’t have a parent editor (as required by commit [2]).

Note that commit [2] was introduced in version 15, but the bug only appears in version 17.4, following commit [1], which converted the snippet menu to OWL.

[1]: https://github.com/odoo/odoo/commit/91293fe4a8125f65cd7e5f487aacbc62c35c0f74
[2]: https://github.com/odoo/odoo/commit/1acc2420d839b443d31ba63b546bcce9ea5dc237

opw-4217635
opw-4217256
opw-4190303
opw-4151866
opw-4221894
opw-4206875
opw-4127338

Forward-Port-Of: odoo/odoo#182768

Steps to reproduce: - Payroll > Configuration > Working Schedules - Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days -- 10:00-12:00, Attendance type, 0.25 days - Employees > Any with that schedule > Time Off - Take a day off on a Monday (Full day) - Time Off app > Management > Time Off - Try to validate this time off An error occurs when trying to read the morning's work entry type because both shifts have been merged (and thus the resulting s

Steps to reproduce:
- Payroll > Configuration > Working Schedules
- Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days
-- 10:00-12:00, Attendance type, 0.25 days
- Employees > Any with that schedule > Time Off
- Take a day off on a Monday (Full day)
- Time Off app > Management > Time Off
- Try to validate this time off

An error occurs when trying to read the morning's work entry type because both shifts have been merged (and thus the resulting shift has 2 entry types). This happens because of the use of Intervals in resource_calendar's '_attendance_intervals_batch' method.

When dealing with attendances we prefer using WorkIntervals which, unlike Intervals, keeps adjacent shifts separate. This is necessary to properly handle the entry type of leaves and attendances over contiguous periods.

This also removes the need for fdd9247cb86a01cc8c0903e69b85aae311e7c1ad, as the attendances have already been separated (Shifts cannot overlap any more than at their bounds) according to their type.

opw-4193334

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182574

Before this commit: == - When we have open orders, and pressing the "close" (cross) button while closing a session currently closes the session. After this commit: == - The session should not be closed when the cross button is pressed. it only dismiss the current dialog. Task-4243380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182905

Before this commit:
==
- When we have open orders, and pressing the "close" (cross) button while closing a session currently closes the session.

After this commit:
==
- The session should not be closed when the cross button is pressed. it only dismiss the current dialog.

Task-4243380


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182905

Earlier next button in the live session was not visible for some backgrounds. This pr addresses the issue and adds a separate background color for the start button so it can be compatible with any background. Task-4210804 Forward-Port-Of: odoo/odoo#182074

Earlier next button in the live session was not visible for some backgrounds.

This pr addresses the issue and adds a separate background color for the start button so it can be compatible with any background.

Task-4210804

Forward-Port-Of: odoo/odoo#182074

Currently, a traceback occurs when the user creates a link tracker having no scheme in the URL. To reproduce this issue: 1) Install website_link, email marketing 2) Create a new link tracker with a target URL from email marketing/configuration 3) Now remove the `http://` from the target URL 4) Navigate to website/site/link tracker Error:- ``` AttributeError: 'str' object has no attribute 'to_url' ``` This is because when the target URL has no `http://` the URL scheme will be

Currently, a traceback occurs when the user creates a link tracker having no scheme in the URL.

To reproduce this issue:

1) Install website_link, email marketing
2) Create a new link tracker with a target URL from email marketing/configuration
3) Now remove the `http://` from the target URL
4) Navigate to  website/site/link tracker

Error:- 
```
AttributeError: 'str' object has no attribute 'to_url'
```

This is because when the target URL has no `http://` the URL scheme will be an empty string. 
So it executes the else block in the below line.

https://github.com/odoo/odoo/blob/8a1e6bef82fdaa98c60ef1e3fa519a03206a6788/addons/link_tracker/models/link_tracker.py#L54-L58

Clearly in the else block the value of `tracker.get_base_url()` is the string, when joining the `url` and `tracker.get_base_url()` it becomes a string.

which leads to a traceback when `to_url()` is accessed from the string.

sentry-5925121505

Forward-Port-Of: odoo/odoo#182556

…le split Currently, when auditing a DNA category with the vehicle split option leads to incorrect values. All the lines from the account being audited are displayed, including those with a 'vehicle_id'. That is wrong, since these lines will be grouped with the corresponding vehicle inside said category. They will appear both when auditing the category as well as when auditing each vehicle from this category. The solution is simply to exclude lines related to a vehicle when auditing a

…le split

Currently, when auditing a DNA category with the vehicle split option leads to incorrect values. All the lines from the account being audited are displayed, including those with a 'vehicle_id'.

That is wrong, since these lines will be grouped with the corresponding vehicle inside said category. They will appear both when auditing the category as well as when auditing each vehicle from  this category.

The solution is simply to exclude lines related to a vehicle when auditing a category while the vehicle split is active.

task-4023543

Forward-Port-Of: odoo/enterprise#71382

The popover was set to bg-100 during darkmode redesign but it creates more issue than having it at 300. The initial issue was the button light behavior inside popover, but setting it to 100 doesn't solve the button light and breaks the elevation. Steps to reproduce (any popover): - Apply the Dark Mode - Go in CRM app - Open a lead - Clic the cog in the control panel next to the breadcrumb - Select "Add Properties" (it opens the popover) task-3593302 Forward-Port-Of: odoo/enterpris

The popover was set to bg-100 during darkmode redesign but it creates
more issue than having it at 300. The initial issue was the button light
behavior inside popover, but setting it to 100 doesn't solve the button
light and breaks the elevation.

Steps to reproduce (any popover):
- Apply the Dark Mode
- Go in CRM app
- Open a lead
- Clic the cog in the control panel next to the breadcrumb
- Select "Add Properties" (it opens the popover)

task-3593302

Forward-Port-Of: odoo/enterprise#51664

There's no refresh when closing a MO on the 'All MO' tab of the shopfloor. Because of that, the MO fades away but the total count is still the same. This PR forces a refresh to make sure that the count is corresponding to the number of MOs shown. When marking a workorder as done with the timer running, the timer doesn't stop and the value registered contains the time it takes to fade away. E.g. if you mark a WO as done at 1 min 33 sec, the real duration registered will be around 1 min

There's no refresh when closing a MO on the 'All MO' tab of the shopfloor.
Because of that, the MO fades away but the total count is still the same.
This PR forces a refresh to make sure that the count is corresponding to
the number of MOs shown.

When marking a workorder as done with the timer running, the timer
doesn't stop and the value registered contains the time it takes to
fade away.
E.g. if you mark a WO as done at 1 min 33 sec, the real duration
registered will be around 1 min 36-37 sec.
This fix ensures the timer stop effectively and visually when closing
a WO.

Forward-Port-Of: odoo/enterprise#71548

1) Navigate to ‘Accounting Reports’ 2) Duplicate ‘Unrealized Currency Gains/Losses’ 3) Set the ‘Root Report’ to ‘Aged Receivable’ 4) Navigate to ‘Accounting/Aged Receivable’ report 5) In the header change current report to ‘Unrealized Currency Gains/Losses (copy)’ 6) Print PDF Issue: Traceback will raise with error "cannot access free variable 'column_index' where it is not associated with a value in enclosing scope" opw-4177428 Forward-Port-Of: odoo/enterprise#71467

1) Navigate to ‘Accounting Reports’
2) Duplicate ‘Unrealized Currency Gains/Losses’
3) Set the ‘Root Report’ to ‘Aged Receivable’
4) Navigate to ‘Accounting/Aged Receivable’ report 
5) In the header change current report to ‘Unrealized Currency Gains/Losses (copy)’ 
6) Print PDF

Issue: Traceback will raise with error
"cannot access free variable 'column_index' where it is not associated with a value in enclosing scope"

opw-4177428

Forward-Port-Of: odoo/enterprise#71467

Problem: When the user enables allow_material on a project, they encounter a ValidationError when adding products on a task that has no sale order. Odoo tries to create a sale order for the task, but there is no company_id passed into the values. Solution: The company_id should be required when allow_material is enabled and the company should be computed once enabled. Steps to Reproduce on Runbot: 1. Install Sales, Field Service, Projects 2. Create a project and enable "Products on Task"

Problem: When the user enables allow_material on a project, they encounter a ValidationError when adding products on a task that has no sale order. Odoo tries to create a sale order for the task, but there is no company_id passed into the values.

Solution: The company_id should be required when allow_material is enabled and the company should be computed once enabled.

Steps to Reproduce on Runbot:
1. Install Sales, Field Service, Projects
2. Create a project and enable "Products on Task"
3. Create a task and assign a customer that has no sales order
4. Add products on the task and the ValidationError occurs

opw-4000580

Forward-Port-Of: odoo/enterprise#68493

- Set up Avatax Credentials - In Fiscal Position "Automatic Tax Mapping (AvaTax)" enable "Automatic Detection" - Create an invoice with avatax product and register payment - Open payment entry and duplicate it Issue: Validation Error will raise "The following customer(s) need to have a zip, state and country when using Avatax:" This occurs because the system checks for customer data validity when duplicating the payment record but it should not occur opw-4119958 Forward-Port-Of: od

- Set up Avatax Credentials
- In Fiscal Position "Automatic Tax Mapping (AvaTax)" enable "Automatic Detection"
- Create an invoice with avatax product and register payment
- Open payment entry and duplicate it

Issue: Validation Error will raise
"The following customer(s) need to have a zip, state and country when using Avatax:"

This occurs because the system checks for customer data validity when duplicating the payment record but it should not occur

opw-4119958

Forward-Port-Of: odoo/enterprise#69757

Added base localization package for Iraq 🇮🇶. It inludes the following: - Chart of Accounts - Taxes [task-3927924](https://www.odoo.com/web#model=project.task&id=3927924) Forward-Port-Of: odoo/enterprise#70457

Added base localization package for Iraq 🇮🇶. It inludes the following:
- Chart of Accounts
- Taxes

[task-3927924](https://www.odoo.com/web#model=project.task&id=3927924)

Forward-Port-Of: odoo/enterprise#70457

**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create the backorder, the resulting backorder will have split the remaining raw moves in an unintuitive manner. **Expected behavior:** The backorder should have one move for the remaining component quantity. **Steps to reproduce:** 1. Create a production for 10 of some final product consuming 1

**Current behavior:**
If you have a production opened in barcode and consume part of a
component line to produce part of the final product, leave the
transfer, then re-open it and confirm -> create the backorder,
the resulting backorder will have split the remaining raw moves
in an unintuitive manner.

**Expected behavior:**
The backorder should have one move for the remaining component
quantity.

**Steps to reproduce:**
1. Create a production for 10 of some final product consuming 10
     some component -> Confirm

2. Open the production in barcode, add 5 of the final product to
     its line and 5 of the component to its line -> exit the
     transfer view

3. Reopen the production and validate it -> create backorder

4. Open the backorder to see the odd split of the component
     product's moves

**Cause of the issue:**
When creating the backorder we normally expect each component
product to be encapsulated by a single line- so the split that
occurs when we leave the transfer initially without validating
which creates 2 moves for the same product means we get 2 moves
for the component for half of the remaining quantity for that
component.

**Fix:**
Incomplete barcode lines for production transfers should get
split into additional move lines as opposed to moves.

opw-4148050

Forward-Port-Of: odoo/enterprise#71558
Forward-Port-Of: odoo/enterprise#69149

This commit adds support for the Bank of Italy currency rates. The Bank of Italy publishes the currency rates on its APIs, of which the most recent one is available at https://tassidicambio.bancaditalia.it/terzevalute-wf-web/rest/v1.0/latestRates. Documentation can be found at https://tassidicambio.bancaditalia.it/terzevalute-wf-ui-web/assets/files/Istruzioni_tecnico-operative.pdf. This is necessary for Italian law compliance, as the Bank of Italy is the only institution allowed to publis

This commit adds support for the Bank of Italy currency rates. The Bank of Italy publishes the currency rates on its APIs, of which the most recent one is available at https://tassidicambio.bancaditalia.it/terzevalute-wf-web/rest/v1.0/latestRates.

Documentation can be found at https://tassidicambio.bancaditalia.it/terzevalute-wf-ui-web/assets/files/Istruzioni_tecnico-operative.pdf. 

This is necessary for Italian law compliance, as the Bank of Italy is the only institution allowed to publish currency rates in Italy.

Forward-Port-Of: odoo/enterprise#55502

Reproduce the issue: - Turn on inter-company transactions to sync Sales and Purchases - Create an SO in one company for the second company - Chatter displays an incorrect message noting the record was created from the current company instead of the triggering company The issue: In the sale_order.py model of sale_purchase_inter_company_rules.py, the field of the current company was used instead of the field of the order's company. opw-4199979 Forward-Port-Of: odoo/enterprise#71624

Reproduce the issue:
- Turn on inter-company transactions to sync Sales and Purchases
- Create an SO in one company for the second company
- Chatter displays an incorrect message noting the record was created from the current company instead of the triggering company

The issue:
In the sale_order.py model of sale_purchase_inter_company_rules.py, the field of the current company was used instead of the field of the order's company.

opw-4199979

Forward-Port-Of: odoo/enterprise#71624

The manual fw-port of - https://github.com/odoo/enterprise/pull/71315 This PR https://github.com/odoo/enterprise/commit/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds 'move_type = entry' on the '3.1 a,b,c,e' report lines, but only misc entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't. To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inhe

The manual fw-port of

- https://github.com/odoo/enterprise/pull/71315

This PR https://github.com/odoo/enterprise/commit/ed431cd78dea4ad40e0e6a82eb3ffd9f44026d71 adds 'move_type = entry' on the '3.1 a,b,c,e' report lines, but only misc entries coming from the POS should impact the line. PoS entries are also considered in section 4, but they shouldn't.

To determine which moves are from the PoS we use the l10n_in_pos_session_ids field from module l10n_in_reports_gstr_pos, so we had to inherit the report in that module to add the condition.

[Task link](https://www.odoo.com/odoo/project/69/tasks/4224066)
**task**-4224066

Forward-Port-Of: odoo/enterprise#71533

Open General Ledger Search for a non existing account/aline (ex. "1111111111111") Issue: All lines are shown This occurs because we update matched lines only if there is a match, otherwise we reset the filter opw-4160605 Forward-Port-Of: odoo/enterprise#69424

Open General Ledger
Search for a non existing account/aline (ex. "1111111111111")

Issue: All lines are shown
This occurs because we update matched lines only if there is a match, otherwise we reset the filter

opw-4160605

Forward-Port-Of: odoo/enterprise#69424

This commit aims to fix the following issue: When we send a sign request, an email is sent containing some link for canceling the sign request, that is when clicked the sign request is canceled instantly. The issue is that some spam detectors is going to click every link in the email while validating it. Resulting in the sign request being canceled without the partner knowing about it. The commit changes the action of the email cancel link to displaying a form and asking the user to

This commit aims to fix the following issue:
When we send a sign request, an email is sent containing some link
for canceling the sign request, that is when clicked
the sign request is canceled instantly.

The issue is that some spam detectors is going to click every
link in the email while validating it. Resulting in the sign
request being canceled without the partner knowing about it.

The commit changes the action of the email cancel link to
displaying a form and asking the user to submit it to
confirm the sign request cancel.

Task: 4149784

Forward-Port-Of: odoo/enterprise#69205