Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.

**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.

**Error:**
`ValueError: Domain() invalid item in domain: ')'`

**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]: 
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|', 
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```

This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example: 
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', 
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```

Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.

**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.

[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109

sentry-6916986959

Forward-Port-Of: odoo/odoo#238825

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and try to scan it, this will trigger the traceback.

### Cause of the issue:
Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data:
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91
_get_stock_barcode_data will obtain the packaging methode for the products.
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16
since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information.

### Fix:
We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids:
https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441
our fix will allow for packaging in the variant to be considered when there is more than only one variant.

opw-4852875

Forward-Port-Of: odoo/enterprise#103860
Forward-Port-Of: odoo/enterprise#87867

**Description of the issue this PR addresses:**
------------------------------------------------
When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users.

For portal users, this resulted in unnecessary toast notifications and chat window pop-ups.

**Current behavior before PR:**
---------------------------------
- The inviter is notified when any invited user connects for the first time.
- This includes portal users.
- Unnecessary notifications and chat pop-ups are shown for portal user connections.

**Desired behavior after PR is merged:**
-----------------------------------------
- The inviter is notified **only when an internal user** connects for the first time.
- Portal users no longer trigger first-connection notifications.
- The notification message is updated to:  “[Username] just connected for the first time. Wish them luck!”

**Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780)

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

Forward-Port-Of: odoo/odoo#242235

**Description of the issue this PR addresses:**
------------------------------------------------
When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users.

For portal users, this resulted in unnecessary toast notifications and chat window pop-ups.

**Current behavior before PR:**
---------------------------------
- The inviter is notified when any invited user connects for the first time.
- This includes portal users.
- Unnecessary notifications and chat pop-ups are shown for portal user connections.

**Desired behavior after PR is merged:**
-----------------------------------------
- The inviter is notified **only when an internal user** connects for the first time.
- Portal users no longer trigger first-connection notifications.
- The notification message is updated to:  “[Username] just connected for the first time. Wish them luck!”

**Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780)

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

Forward-Port-Of: odoo/odoo#242235

Currently, an error occurs when user sets the resource on a resource leave.

**Steps to Reproduce:**

 - Install `hr_contract` with demo data.
 - Go to `Resource Time Off`.
 - Create a new record and remove the `start date` value.
 - Select the `Anita Oliver` resource `(employee record with running contract)`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause:**
This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error.

Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract.

**Fix:**
This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly.

[1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17

[2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29

**No Task ID**


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

Forward-Port-Of: odoo/odoo#241638

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert:
```python
self.assertEqual(self.product1.qty_available, 15.0)
```
The error message is: `AssertionError: 16.0 != 15.0`

In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15.
Now, the assert sometime fails because in the tour, the last step check the success message is visible:
```javascript
trigger: ".o_notification_bar.bg-success",
```
The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition.

To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it.

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

runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692)

Forward-Port-Of: odoo/enterprise#104481

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

note: the same bug exists for the employee tolerance time, which
is corrected in this commit.
__
opw-5136861

---

Forward-Port-Of: odoo/odoo#244186
Forward-Port-Of: odoo/odoo#242517

**Description of the issue this PR addresses:**
------------------------------------------------
When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users.

For portal users, this resulted in unnecessary toast notifications and chat window pop-ups.

**Current behavior before PR:**
---------------------------------
- The inviter is notified when any invited user connects for the first time.
- This includes portal users.
- Unnecessary notifications and chat pop-ups are shown for portal user connections.

**Desired behavior after PR is merged:**
-----------------------------------------
- The inviter is notified **only when an internal user** connects for the first time.
- Portal users no longer trigger first-connection notifications.
- The notification message is updated to:  “[Username] just connected for the first time. Wish them luck!”

**Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780)

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

Forward-Port-Of: odoo/odoo#242235

Currently, an error occurs when user sets the resource on a resource leave.

**Steps to Reproduce:**

 - Install `hr_contract` with demo data.
 - Go to `Resource Time Off`.
 - Create a new record and remove the `start date` value.
 - Select the `Anita Oliver` resource `(employee record with running contract)`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause:**
This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error.

Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract.

**Fix:**
This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly.

[1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17

[2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29

**No Task ID**


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

Forward-Port-Of: odoo/odoo#241638

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

note: the same bug exists for the employee tolerance time, which
is corrected in this commit.
__
opw-5136861

---

Forward-Port-Of: odoo/odoo#244186
Forward-Port-Of: odoo/odoo#242517

Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.

Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets.

This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`:
1. Matches where `company_id` is explicitly equal.
2. Matches where `company_id` is NULL.

By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time.

References:
- Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955
- Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan
- Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan

opw-5460862

Forward-Port-Of: odoo/enterprise#104663
Forward-Port-Of: odoo/enterprise#104299

Currently, editing the address or organizer on an event page in website editor triggers an error due to an invalid, unevaluated domain being passed.

**Steps to reproduce:**
1. Install `website_event` module with demo data.
2. Open any event page and activate the website editor.
3. Click on My Company under **Organizers** (also works with **Location**).
4. On the right sidebar click on "**Contact**" drop-down.

**Error:**
`ValueError: Domain() invalid item in domain: ')'`

**Cause:**
The fields `event.event.address_id` and `event.event.organizer_id` have `check_company=True`, which generates in a domain expression like this at [1]: 
```
(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of', [company_id])] or ['|', 
('company_id', '=', False), ('company_id', 'parent_of', '')]) + []
```

This domain is not evaluated on the back-end; instead serialized as JSON string. When the website editor opens the many2one dropdown, the JS code (ref 2) incorrectly splits this string into a list of individual characters, for example: 
```
['(', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ' ', 'a', 'n', 'd', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', 
"'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 
'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', '[', 'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', ']', ')', ']', ' ', 'o', 'r', ' ', '[', "'", '|', "'", ',', ' ', '(', "'", 
'c', 'o', 'm', 'p', 'a', 'n', 'y', '_', 'i', 'd', "'", ',', ' ', "'", '=', "'", ',', ' ', 'F', 'a', 'l', 's', 'e', ')', ',', ' ', '(', "'", 'c', 'o', 'm', 'p', 'a', 'n', 
'y', '_', 'i', 'd', "'", ',', ' ', "'", 'p', 'a', 'r', 'e', 'n', 't', '_', 'o', 'f', "'", ',', ' ', "'", "'", ')', ']', ')', ' ', '+', ' ', '(', '[', ']', ')', ['id', 'not in', [1]]]
```

Such a malformed domain passed directly to `name_search()` method, where **Domain()** fails to validate it, raising the error.

**Fix:**
This commit checks for unevaluated domains (returned as strings) and ignores them when rendering many2one fields in the website editor.

[1] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_editor/models/ir_qweb_fields.py#L255
[2] - https://github.com/odoo/odoo/blob/9bf7a6511711cbd4866bec03dce5cd08d7580065/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L102-L109

sentry-6916986959

Forward-Port-Of: odoo/odoo#238825

**Description of the issue this PR addresses:**
------------------------------------------------
When a user was invited to Odoo, the inviter received a first-connection notification when the invited user connected for the first time. This notification was triggered for **all user types**, including portal users.

For portal users, this resulted in unnecessary toast notifications and chat window pop-ups.

**Current behavior before PR:**
---------------------------------
- The inviter is notified when any invited user connects for the first time.
- This includes portal users.
- Unnecessary notifications and chat pop-ups are shown for portal user connections.

**Desired behavior after PR is merged:**
-----------------------------------------
- The inviter is notified **only when an internal user** connects for the first time.
- Portal users no longer trigger first-connection notifications.
- The notification message is updated to:  “[Username] just connected for the first time. Wish them luck!”

**Task:** [4105780](https://www.odoo.com/odoo/project/1519/tasks/4105780)

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

Forward-Port-Of: odoo/odoo#242235

**PROBLEM**
You can't import a bank stamement from the document app in some languages (ie. fr_FR).

**STEP TO REPRODUCE**
1. install account_document
2. upload a camt file to the Finance/ folder (you can find them in account_bank_statement_import_camt)
3. switch the user language to french.
4. try importing the camt file, it will fail saying you have no right to execute this action in the folder.

**CAUSE**
In the data of document_account, the children actions of the import bank statement action don't have any sequence defined.
This means there sequence will have a default value (5). Because they have the same sequence, their order of execution depend on their name, and it could changes depending on the language loaded. In English, the order is :
1. import the bank statement
2. move the file to some folder

In French, the order is :
1. move the file to some folder
2. import the bank statement 

The import action doesn't work, because the action can't be executed in the folder we moved the file into.

opw-5413409

When using QR code self-ordering with "service at table" and "payment at the end of the meal", self-orders were only visible individually on the POS terminal when clicking on the table, even though multiple orders existed for the same table. Only the last order made was visible.

Steps to reproduce:
-------------------
* Configure POS with self-ordering mode 'mobile', pay_after='meal', service_mode='table'
* Open POS session
* Scan QR code from table and create a self-order
* Create another order from POS terminal on the same table
* Click on the table from the floor plan

> Observation:
Only the last order was visible when clicking on the table, even though both orders appeared in the Orders tab with the same table tag.

Why the fix:
------------
Self-orders created via QR scan initially only had `self_ordering_table_id` set, but not `table_id`. The existing `DevicesSynchronisation` merge logic only merges orders that have the same `table_id`. By setting `table_id` on self-orders when the conditions are met (pay_after='meal' and preset.service_at='table') self-orders can now be automatically merged with regular POS orders on the same table during sync, ensuring all orders are visible when clicking on a table.

opw-5250653

When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported.

Steps to reproduce:

1. Create a CSV file with enough records to trigger at least 2 batches
2. Go to any list view and select "Import records".
3. Upload the file and click "Import".
4. Wait for the import to complete.
5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears.

The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes.

* In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated.
* If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch.
* `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value.

This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`).

opw-5343837

Steps to reproduce:
1. Install the Sale app.
2. Enable developer mode and go to Decimal Accuracy.
3. Set the "Product Price" precision to 3 digits.
4. Create a quotation and print the report.

Issue:
The decimal precision of the unit price is not respected in the report.

Cause:
The unit price field in the report uses the `monetary` widget, which ignores the Decimal Accuracy configuration and enforces currency precision instead.

Solution:
Remove the `monetary` widget from the unit price field in the report so that Decimal Accuracy is applied correctly.

Before:
<img width="570" height="97" alt="image" src="https://github.com/user-attachments/assets/dda22b25-0ade-40ae-b585-c6251ba89c89" />


After :
<img width="584" height="87" alt="image" src="https://github.com/user-attachments/assets/b51d3040-e7b5-41d6-bdd9-7ec799b8005d" />

opw-5418665

Revert [PR #224219](https://github.com/odoo/odoo/pull/224219/files#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bR201) to the original implementation so that the configured Decimal Accuracy is correctly applied in reports as other apps i.e. Purchase or Account

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

Description of the issue/feature this PR addresses:
German regulations specify that the LeitwegID appears in the field BT-10. However, this field is usually filled with the value of the "ref" field of the customer, potentially creating a situation where the Odoo user thinks they have entered the data into Odoo correctly (Having set the Peppol Endpoint Type to "Leitweg ID" and entered the Leitweg-ID into the Peppol Endpoint field), but their invoice is still rejected because the Leiweg ID does not appear in the correct spot.

Current behavior before PR:
To generate a valid X-Rechnung to a German government office, the Leitweg-ID has to be put into the "Reference" field of the contact, conflicting with other potential uses for that field.

Desired behavior after PR is merged:
If the Peppol Endpoint is set to be a LeitwegID, the X-Rechnung also fills it into the BT-10 Field to ensure conformity to the German regulations.


References:
[German FAQ regarding Leitweg-ID](https://e-rechnung-bund.de/faq/#leitweg-id)
[Specification of the LeitwegID](https://xeinkauf.de/app/uploads/2022/11/Leitweg-ID-Formatspezifikation-v2-0-2-1.pdf)

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

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Problem:
- In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant.

Current behaviour:
- Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient.

Expected behaviour:
- Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided.

Solution:
- Do not set ‘state=“open”’ for payment records created from a sale involving
  the data wizard for records. Ensure they remain in “draft”.
- Confirm registrations once attendee details are present.

Advantages:
- Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner.
- Meets functional expectations for administrative control and proper recipient targeting.

Tests to reproduce the error:
- Create quote with payment entry
- Confirm SO
- Enter attendee details and confirm
- Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee.

@Tecnativa TT58160

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

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

Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time.

Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events.

**Current behavior before PR:**

Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer:
	•	the synchronization fails,
	•	and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo.

**Desired behavior after PR is merged:**

The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`.

If the parameter is not set, the behavior remains unchanged (default 3 seconds).
Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs.


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