**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

**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 reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due to the `isLast` check in `_goToNextStep()`. As a result, `_process_answer()` was not executed, and the user's final answer was not saved, which resulted in the `rawAnswer` field remaining empty and the answer not appearing in the side panel. The chat session was also not marked as closed since the backend route was never called.

**Current behavior before PR:**
---------------------------------

- The final chatbot answer is not visible in the side panel  
- The chat session remains open after the final step  

**Desired behavior after PR is merged:**
-----------------------------------------

- The final chatbot answer is saved and displayed in the side panel  
- The backend route is triggered for the last step  
- The chat session is properly marked as closed  

**Task:** 5172125

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

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

- for more then one records having same code it's raising an singleton error at fetching the name

- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```

- OPW-5450360

Forward-Port-Of: odoo/enterprise#103460