Pinning messages in Discuss now works even when the message has no linked thread available. This prevents a user-facing error and makes the message pinning action more reliable.

**Before this PR:**

Pinning a message would throw an error if the associated thread was not present on the message.

**After this PR:**

This commit ensures that pinning a message works properly.

**Task**-4805076

The IoT box setup flow no longer asks users to configure a Point of Sale when no active Point of Sale is available. This removes a confusing popup that could not be completed and makes the pairing process smoother for businesses without Point of Sale configurations.

Before this commit, if you paired an IoT box with no Points of Sale configured, you would still get the popup prompting you to autoconfigure your IoT box with a PoS. However, since you have no PoS you cannot fill in the required field and have to dismiss the popup.

After this commit, we only open the autoconfigure popup if there is at least one active PoS available.

task-4797331

Otherwise, there's no other way for users to verify if the charged taxes are correct. task-4688950 Forward-Port-Of: odoo/enterprise#85100 Forward-Port-Of: odoo/enterprise#83464

Otherwise, there's no other way for users to verify if the charged taxes are correct.

task-4688950

Forward-Port-Of: odoo/enterprise#85100
Forward-Port-Of: odoo/enterprise#83464

This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval. Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:

This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval.

Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6.

This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval.

opw-4790119

Forward-Port-Of: odoo/enterprise#85967
Forward-Port-Of: odoo/enterprise#85548

The redesign of the spreadsheet layout did not account for the small screen mode. Mor specifically, the breadcrumbs can be reduded to a "previous arrow" to spare some space to display the spreadsheet name. task-4774806 Forward-Port-Of: odoo/enterprise#84732

The redesign of the spreadsheet layout did not account for the small screen mode. Mor specifically, the breadcrumbs can be reduded to a "previous arrow" to spare some space to display the spreadsheet name.

task-4774806

Forward-Port-Of: odoo/enterprise#84732

### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now, add the portal user as a follower on a task. 4. Change the state of a task to execute an automation rule. 5. Email will be received by a portal user but it will not be visible on the messaging history on the portal. ### Cause: This is happening because when running an automation rule that

### Steps to reproduce:
	1. Create a portal user.
	2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view
	3. Now, add the portal user as a follower on a task.
	4. Change the state of a task to execute an automation rule.
	5. Email will be received by a portal user but it will not be visible on the messaging history on the portal.

### Cause:
This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages.

### Fix:
Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view

opw-4459754

Forward-Port-Of: odoo/enterprise#85969
Forward-Port-Of: odoo/enterprise#82352

This reverts the commit https://github.com/odoo/enterprise/commit/fbfa23e4ee86666e6c0903206ff49a918f281c67. Indeed, for security reasons, it is preferable to avoid calling safe_eval whenever possible. Note that in https://github.com/odoo/odoo/pull/208876 a new mechanism is introduced in order to block the creation of expressions in domain fields where we only want domains with litterals because they are evaluated with literal_eval. Forward-Port-Of: odoo/enterprise#85872 Forward-Port-Of: odo

This reverts the commit https://github.com/odoo/enterprise/commit/fbfa23e4ee86666e6c0903206ff49a918f281c67. Indeed, for security reasons, it is preferable to avoid calling safe_eval whenever possible.
Note that in https://github.com/odoo/odoo/pull/208876 a new mechanism is introduced in order to block the creation of expressions in domain fields where we only want domains with litterals because they are evaluated with literal_eval.

Forward-Port-Of: odoo/enterprise#85872
Forward-Port-Of: odoo/enterprise#85298

**Issue:** A traceback error is raised when the assignee of a Field Service task has no calendar **Steps to reproduce:** - Make sure admin (Michel Admin) has no calendar in the Employee module - Field Service > New - Create a new task with Michel Admin as assignee and click save without choosing Planned Date and leave Allocated Hours at 0 - Choose Planned Date then click save again A traceback error is raised opw-4672980 Forward-Port-Of: odoo/enterprise#83839

**Issue:**
A traceback error is raised when the assignee of a Field Service task has no calendar

**Steps to reproduce:**
- Make sure admin (Michel Admin) has no calendar in the Employee module
- Field Service > New
- Create a new task with Michel Admin as assignee and click save without choosing Planned Date and leave Allocated Hours at 0
- Choose Planned Date then click save again

A traceback error is raised

opw-4672980

Forward-Port-Of: odoo/enterprise#83839

…vailability ### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. ####

…vailability

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The `preparation_time` (`Security Time`) field is used at the sale order line creation to modify the `reservation_begin` value: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L447-L453 In particular, the `preparation_time` of the product creates a difference between the `order_id.rental_start_date` and the `reservation_begin`. This is porblematic since the `rental_start_date` is used to generate the dates of the deliveries taken into account by the forecast:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L354-L362 but the quantity considered as rented does not and is purely based on the `reservation_begin` of the line:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/product_product.py#L113-L117 In particular, the qunaities are not yet accounted ithe stock forecast by the `virtual_available` value of the product:
https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L129-L132 But will incorrectly be found and read by the rental forecast: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L133-L140

opw-4552760

Forward-Port-Of: odoo/enterprise#85949

Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly

Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error:

```
Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')
at ActivityListPopoverItem.template
```

This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly on returned RPCs. The code of VOIP returns activity data with a custom formatter, which omits `persona` that is important for the good templating of an activity in Chatter otherwise there's the crash above.

A recent PR [1] attempted to fix this issue, but the syntax for Store was wrong: it used the syntax for an item in field list (e.g. in `_to_store_defaults`) instead of pure store data from a specific record. This bad use of Store.One() resulted in actually returning `False`.

[1]: https://github.com/odoo/enterprise/pull/84970

opw-4586756

Forward-Port-Of: odoo/enterprise#85907

**[FIX] l10_ke_edi_oscu: Handle None name of fresh unposted credit notes.** To reproduce the issue: - Create an invoice with some lines - Create the first credit note and change the product set on one of the lines or its quantity to trigger the fix piece of the code (do not confirm the credit note) - Create another credit note and try to post it -> Traceback The issue is caused by the fact that newly created moves generally have `None` in the `name` field, which is only populated after

**[FIX] l10_ke_edi_oscu: Handle None name of fresh unposted credit notes.**

To reproduce the issue:
- Create an invoice with some lines
- Create the first credit note and change the product set on one of the lines or its quantity to trigger the fix piece of the code (do not confirm the credit note)
- Create another credit note and try to post it -> Traceback

The issue is caused by the fact that newly created moves generally have `None` in the `name` field, which is only populated after posting. This fix resolve this by replacing the string shown when the name field is None.

opw-4779976

Forward-Port-Of: odoo/enterprise#85345

compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84867 Forward-Port-Of: odoo/enterprise#84842

compute imp & assert deduplicate

Forward-Port-Of: odoo/enterprise#84867
Forward-Port-Of: odoo/enterprise#84842

…ve and reload sources In the reportEditor edit the xml, modify a view's arch and save. Before this commit, the cursor position in the XMLEditor was reset to [0,0]. After this commit, we restore the position of the cursor according to the start position of the last edition. opw-4745895 Forward-Port-Of: odoo/enterprise#85984 Forward-Port-Of: odoo/enterprise#84877

…ve and reload sources

In the reportEditor edit the xml, modify a view's arch and save. Before this commit, the cursor position in the XMLEditor was reset to [0,0].

After this commit, we restore the position of the cursor according to the start position of the last edition.

opw-4745895

Forward-Port-Of: odoo/enterprise#85984
Forward-Port-Of: odoo/enterprise#84877

Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum or SwSapien 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3. Create a USD invoice for `13220.00 USD` and send CFDI 4. Reconcile transaction and invoice 5. Click "Update payments" on the invoice => CRP20211 Looks like it comes from this rounding difference Rate is computed by odoo using `305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

Steps to reproduce:
(thanks to TBS for investigating + writing the test)

1. Have a MX company with Quadrum or SwSapien
2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN`
3. Create a USD invoice for `13220.00 USD` and send CFDI
4. Reconcile transaction and invoice
5. Click "Update payments" on the invoice => CRP20211

Looks like it comes from this rounding difference

Rate is computed by odoo using
`305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

PAC verify the amount paid using
`13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN`

Solution:
There is no solution by adapting the rate:
- quadrum restricts the rate to 6 decimals;
- rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`.

So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly
`round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`.

In tests, both Quadrum and SwSapien seem to accept this.

We don't perform the modification for Solucion Factible (the other PAC).

opw-4222310

Forward-Port-Of: odoo/enterprise#85602
Forward-Port-Of: odoo/enterprise#83499

…line are postpaid Forward-Port-Of: odoo/enterprise#85644 Forward-Port-Of: odoo/enterprise#73731

…line are postpaid

Forward-Port-Of: odoo/enterprise#85644
Forward-Port-Of: odoo/enterprise#73731

NSSF report columns "NSSF Amount Employee" and "NSSF Amount Employer" display pre-computation values which is the amount of payslip lines instead of total amount after the computation of 6% rate. task-4724292 Forward-Port-Of: odoo/enterprise#83613

NSSF report columns "NSSF Amount Employee" and "NSSF Amount Employer"
display pre-computation values which is the amount of payslip lines instead of
total amount after the computation of 6% rate.

task-4724292

Forward-Port-Of: odoo/enterprise#83613

Prior to this change, if the demo data were loaded for account but couldn't be for account_loans, its installation would simply crash trying to reference an unknown xml_id 'account_loans_loan_demo1'. opw-4790398 upg-2793930 Forward-Port-Of: odoo/enterprise#85853

Prior to this change, if the demo data were loaded for account but couldn't be for account_loans, its installation would simply crash trying to reference an unknown xml_id 'account_loans_loan_demo1'.

opw-4790398
upg-2793930

Forward-Port-Of: odoo/enterprise#85853

- Generate a new invoice in the menu ‘Accounting > Customers > Invoices’. - Add any product line. - Additionally, add a line of a Note and a line of Section - Confirm the invoicea and send it to CFDI - Click on the option ‘Cancellation request’ and select the reason ‘01’. Click on ‘Create corrective invoice’. The section and note lines disappear from the newly created invoice. In the action_create_replacement_invoice only the lines with display type product are carried over. After this

- Generate a new invoice in the menu ‘Accounting > Customers > Invoices’.
- Add any product line.
- Additionally, add a line of a Note and a line of Section
- Confirm the invoicea and send it to CFDI
- Click on the option ‘Cancellation request’ and select the reason ‘01’. Click on ‘Create corrective invoice’.

The section and note lines disappear from the newly created invoice.

In the action_create_replacement_invoice only the lines with display type product are carried over. After this commit we also include the notes and the sections.

opw-4726350

Forward-Port-Of: odoo/enterprise#83578

## Pull Request HOOT (PRHOOT) 31 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/205405 --- I confirm I have signed

## Pull Request HOOT (PRHOOT) 31

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

Community: https://github.com/odoo/odoo/pull/205405

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

Forward-Port-Of: odoo/enterprise#85664
Forward-Port-Of: odoo/enterprise#83169

The xsd changed. Now the rounding needs to be to 2 decimals everywhere. The official xsd does not mention it, but the field submit_more must appear on the xml. Also, while it's not blocking directly, the declaration will be rejected if the special deduction is filled without specifying the special %age. So we add a banner warning the user of it. opw-4789154 Forward-Port-Of: odoo/enterprise#85593 Forward-Port-Of: odoo/enterprise#85464

The xsd changed. Now the rounding needs to be to 2 decimals everywhere. 
The official xsd does not mention it, but the field submit_more must appear on the xml.

Also, while it's not blocking directly, the declaration will be rejected if the special deduction is filled without specifying the special %age. So we add a banner warning the user of it.

opw-4789154

Forward-Port-Of: odoo/enterprise#85593
Forward-Port-Of: odoo/enterprise#85464

**Steps to reproduce:** 1. Install `website_sale_renting` 2. Go to the website editor. 3. Drag and drop the `rental search` snippet. 4. Set the rental timing to `hour` **Issue:** - The default date was always set to the next day with the current time, making it impossible for users to select the current date without adjusting the time manually. https://github.com/odoo/enterprise/blob/a6ec35e94bdd4f721982c32716f716948f74c875/website_sale_renting/static/src/js/website_sale_renting_dateran

**Steps to reproduce:**
1. Install `website_sale_renting`
2. Go to the website editor.
3. Drag and drop the `rental search` snippet.
4. Set the rental timing to `hour`

**Issue:**
- The default date was always set to the next day with the current time, making it impossible for users to select the current date without adjusting the time manually.
https://github.com/odoo/enterprise/blob/a6ec35e94bdd4f721982c32716f716948f74c875/website_sale_renting/static/src/js/website_sale_renting_daterangepicker.js#L147-L148

**Solution:**
- Updated the logic for hourly rentals to set the default date next day with
  adding one hour from the current time,  to allow customers to select the
  current date.
- For daily rentals, the logic remains unchanged and defaults to the next day.

opw-4770823

Forward-Port-Of: odoo/enterprise#85613