Steps to reproduce:
--------------------------------------------
1. Install Attendance module.
2. Enable `Device & Location Tracking` & `Attendance from Backend` in settings.
3. Block location access from the browser for this site (Site settings)
4. Try to checkIn/checkOut from the Dot in the systray
5. We'll have one confirmation pop-up asking to Proceed Anyway OR Discard

Observation:
--------------------------------------------
On clicking the discard button, Nothing happens.

Issue:
--------------------------------------------
In `confirmChecking()`, the `cancel` callback was defined as an arrow function using an expression body. In JavaScript, an assignment expression returns the assigned value. Since `this._attendanceInProgress` is set to `false`, the callback implicitly returns `false`.

`ConfirmationDialog.execButton()` treats a `false` return value as a signal to keep the dialog open (used intentionally to block closing on validation failure) This caused the dialog to never call `this.props.close()`, leaving it permanently open when Discard was clicked.

https://github.com/odoo/odoo/blob/5e84fdd99e34836a15cadc4fdf4b6bc449727e58/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js#L75-L89

Solution:
--------------------------------------------
Change the `cancel` callback from an expression body to a block body, A block body arrow function returns `undefined` by default. This ensures `execButton` does not interpret the return value as a 'keep dialog open' signal, and correctly calls `this.props.close()` to dismiss the dialog.

opw-6462439

Forward-Port-Of: odoo/odoo#281702

Current behaviour:
In the Calendar view (day/week/month scale), when the user's timezone observes a DST transition that starts exactly at local midnight (e.g. Africa/Cairo, since 2023), the day column right after the transition gets the wrong weekday name, duplicating the previous day's name. For ex. it renders "... THU THU FRI ..." instead of "... THU FRI SAT ...", for the week surrounding April 30th 2027.

To fix this we add 1 hour to the Date before reading its weekday/day from it, mirroring the workaround FullCalendar itself adopted for this same bug. It has no effect on any ordinary day (adding 1h to a correct local midnight stays within the same calendar day), and it cannot overshoot into the next day since no real-world DST gap exceeds that margin.

Note: This is a known bug (https://github.com/fullcalendar/fullcalendar/issues/7633), fixed in FullCalendar v6.1.17, a major version ahead of the v4.4.0, so the fix can't be applied directly without a full library upgrade.

opw-6370140

Forward-Port-Of: odoo/odoo#280253
Forward-Port-Of: odoo/odoo#279343

When updating mail notifications during `mail.mail._send()`,

a `SerializationFailure` raised while flushing the notification recordset leaves the current transaction in an aborted state.

As `_send()` continues handling the exception, accessing fields:
 - https://github.com/odoo/odoo/blob/127f1316540ec6cc6880ea3515e6923ba3903bc7/addons/mail/models/mail_mail.py#L816

So, any subsequent SQL query fails with

`InFailedSqlTransaction`, masking the original concurrency error.

Avoid accesing to `mail.message_id` with aborted cursor, preserving the original `SerializationFailure`.

A regression test is added to simulate a concurrency failure during

`flush_recordset()` and verify that the cursor is no longer used dirty

The logger for the unittest without the fix is the following:

```log
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/mail/models/mail_mail.py", line 719, in _send
    notifs.flush_recordset(['notification_status', 'failure_type', 'failure_reason'])
  File "<string>", line 3, in flush_recordset
  File "unittest/mock.py", line 1139, in __call__
    return self._mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1143, in _mock_call
    return self._execute_mock_call(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "unittest/mock.py", line 1204, in _execute_mock_call
    result = effect(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 93, in mocked_mail_notification_flush_recordset
    return original_flush_recordset(self, *vals, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 6788, in flush_recordset
    self._flush(fnames)
  File "odoo/odoo/models.py", line 6852, in _flush
    model.browse(some_ids)._write_multi(vals_list)
  File "odoo/odoo/models.py", line 4938, in _write_multi
    self.env.execute_query(SQL(
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "odoo/addons/test_mail/tests/test_message_post_concurrent.py", line 107, in test_mail_send_dirty_cursor
    mails.send()
  File "odoo/addons/mail/models/mail_mail.py", line 652, in send
    self.browse(batch_ids)._send(
  File "odoo/addons/mail/models/mail_mail.py", line 818, in _send
    mail.id, mail.message_id)
             ^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1309, in __get__
    self.compute_value(recs)
  File "odoo/odoo/fields.py", line 1491, in compute_value
    records._compute_field_value(self)
  File "odoo/odoo/models.py", line 5302, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/odoo/fields.py", line 113, in determine
    return needle(records, *args)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 710, in _compute_related
    record[self.name] = self._process_related(value[self.related_field.name], record.env)
                                              ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 7083, in __getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/fields.py", line 1272, in __get__
    recs._fetch_field(self)
  File "odoo/odoo/models.py", line 4120, in _fetch_field
    self.fetch(fnames)
  File "odoo/addons/mail/models/mail_message.py", line 756, in fetch
    return super().fetch(field_names)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4158, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/models.py", line 4245, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "odoo/odoo/api.py", line 993, in execute_query
    self.cr.execute(query)
  File "odoo/odoo/sql_db.py", line 371, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block
```

Real error in production:

```log
2023-04-15 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_notification" SET "failure_reason" = "__tmp"."failure_reason"::text, "failure_type" = "__tmp"."failure_type"::VARCHAR, "notification_status" = "__tmp"."notification_status"::VARCHAR FROM (VALUES (4426629, 'Error without exception. Probably due to concurrent access update of notification records. Please see with an administrator.', 'unknown', 'exception')) AS "__tmp"("id", "failure_reason", "failure_type", "notification_status") WHERE "mail_notification"."id" = "__tmp"."id" ERROR: could not serialize access due to concurrent update
```

```log
2023-04-14 10:43:14,978 106451 ERROR my_db odoo.sql_db: bad query: UPDATE "mail_mail" SET "failure_reason"='Error without exception. Probably due do sending an email without computed recipients.',"headers"='{''X-SMTPAPI'': ''{"ip_pool": "Transactional"}'', ''X-Odoo-Objects'': ''sale.order-1436960''}',"state"='exception',"write_uid"=1,"write_date"=(now() at time zone 'UTC') WHERE id IN (2548540)
ERROR: current transaction is aborted, commands ignored until end of transaction block
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


# UPDATE 2026-07-22

The reviewer requested to remove the large docstring

For record, the docstring was

```python
    """Reproduces a concurrency scenario where `mail_mail._send()` fails with a PSQL SerializationFailure after
        flushing `mail.notification` records. After such a failure, the cursor is left in an aborted
        (`InFailedSqlTransaction`) state, so any further SQL access (e.g. reading `mail.message_id` like
        https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
        would raise a new error masking the original SerializationFailure.

        Setup:
        - Uses a separate `cursor()` to create and commit a message with its `mail.mail` and `mail.notification`
        records, so they are visible to a second, concurrent transaction.

        Concurrency simulation:
        - `MailNotification.flush_recordset` is patched so that, right before the real flush runs, a second cursor
        updates the same `mail.notification` records (`failure_reason`). This forces PSQL to raise a
        SerializationFailure when the original transaction tries to flush those rows.

        Assertions:
        - `SerializationFailure` is raised confirming the concurrency conflict.
        - `mail_mail._send()` logs the expected error message containing the mail `id` and `message-id`

        Cleanup: created records are unlinked in `finally`
        """
```

# UPDATE 2026-07-23

The reviewer requested to remove the unittest

For record, the unittest was

```diff
diff --git a/addons/test_mail/tests/test_message_post.py b/addons/test_mail/tests/test_message_post.py
index 53dd5b9eec52..46a3958a5bff 100644
--- a/addons/test_mail/tests/test_message_post.py
+++ b/addons/test_mail/tests/test_message_post.py
@@ -7,17 +7,21 @@ from datetime import datetime, timedelta
 from freezegun import freeze_time
 from itertools import product
 from markupsafe import escape, Markup
+from psycopg2.errorcodes import SERIALIZATION_FAILURE as SERIALIZATION_FAILURE_CODE
+from psycopg2.errors import SerializationFailure
 from unittest.mock import patch
 
-from odoo import tools
+from odoo import SUPERUSER_ID, api, tools
 from odoo.addons.base.tests.test_ir_cron import CronMixinCase
-from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon
+from odoo.addons.mail.models.mail_notification import MailNotification
+from odoo.addons.mail.tests.common import mail_new_test_user, MailCommon, MockEmail
 from odoo.addons.test_mail.data.test_mail_data import MAIL_TEMPLATE_PLAINTEXT
 from odoo.addons.test_mail.models.test_mail_models import MailTestSimple
 from odoo.addons.test_mail.tests.common import TestRecipients
 from odoo.api import call_kw
 from odoo.exceptions import AccessError
-from odoo.tests import tagged
+from odoo.modules.registry import Registry
+from odoo.tests import TransactionCase, get_db_name, tagged
 from odoo.tools import mute_logger, formataddr
 from odoo.tests.common import users
 
@@ -2244,3 +2248,49 @@ class TestMessagePostLang(MailCommon, TestRecipients):
                                     self.assertIn('html lang="es_ES"', email['body'])
                                 else:
                                     self.assertIn('html lang="en_US"', email['body'])
+
+
+@tagged('database_breaking')
+class TestMessagePostConcurrent(MockEmail, TransactionCase):
+    """Mail concurrency edge cases that require real, separately committed transactions
+    instead of the usual rollback-based TransactionCase isolation.
+    """
+
+    def test_mail_send_dirty_cursor(self):
+        """Reproduces SerializationFailure `mail_mail._send()` fails,
+        the cursor is left in an aborted state, so any further SQL access would raise a new error
+        (e.g. reading `mail.message_id` like
+        https://github.com/odoo/odoo/blob/127f1316540ec6cc68/addons/mail/models/mail_mail.py#L816)
+        """
+        original_flush_recordset = MailNotification.flush_recordset
+
+        def mocked_mail_notification_flush_recordset(self, *args, **kwargs):
+            with Registry(get_db_name()).cursor() as cr:
+                cr.execute('UPDATE mail_notification SET failure_reason = %s WHERE id IN %s', ('Forced Concurrent Update', tuple(self.ids)))
+            return original_flush_recordset(self, *args, **kwargs)
+
+        recs2unlink = []
+        with Registry(get_db_name()).cursor() as cr:
+            env = api.Environment(cr, SUPERUSER_ID, {})
+            partner = env.ref('base.user_admin').partner_id
+            try:
+                message = partner.message_post(body='Hello', message_type='comment', partner_ids=[partner.id], mail_auto_delete=False, force_send=False)
+                notifs = env['mail.notification'].search([('notification_type', '=', 'email'), ('mail_mail_id', 'in', message.mail_ids.ids)])
+                self.assertTrue(notifs)
+                mails = message.mail_ids
+                recs2unlink.extend([notifs, mails, message])
+                cr.commit()
+
+                mails = self.env[mails._name].browse(mails.ids)
+                with (
+                    mute_logger('odoo.sql_db'), self.assertRaises(SerializationFailure) as exc, self.mock_mail_gateway(),
+                    patch(f'{MailNotification.__module__}.{MailNotification.__name__}.flush_recordset', autospec=True, side_effect=mocked_mail_notification_flush_recordset),
+                    self.assertLogs('odoo.addons.mail.models.mail_mail', level='ERROR') as log_capture,
+                ):
+                    mails.send()
+            finally:
+                for rec2unlink in recs2unlink:
+                    env[rec2unlink._name].browse(rec2unlink.ids).unlink()
+
+            self.assertEqual(exc.exception.pgcode, SERIALIZATION_FAILURE_CODE)
+            self.assertIn(f'Exception while processing mail with ID {mails.id} and Msg-Id \'{mails.message_id}\'.', [record.message for record in log_capture.records])

```

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

Forward-Port-Of: odoo/odoo#279897
Forward-Port-Of: odoo/odoo#274089

Currently, an error occurs when orders are being fetched from shops with pending authorization.

Steps to replicate:
- Install `sale_tiktok`.
- Open Sales > Configuration > Shops (Under the title tiktok shops).
- Click `Connect New Shop` > Give values for `App key, App secret, Service ID`.
- Click `Connect Shop & Authorize` and then Return back to Odoo.
- Run the Scheduled Action `TikTok Shop: sync orders`.

Error:
```
File '/home/odoo/src/enterprise/saas-19.4/sale_tiktok/utils.py', line 171, in make_tiktok_api_request
    if now > shop.access_token_expire_datetime - timedelta(minutes=5):
TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'

ValueError: TypeError('unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'') while evaluating
'model._sync_orders()'
```

Cause:
- Since the shop has not yet been authorized with TikTok, the `access_token_expire_datetime` field is not set. This field is only populated after the shop is successfully authorized (see [this]).

- Later, when the `TikTok Shop: sync orders` cron runs, the flow reaches [here], where we checks whether the access token is expired and needs to be refreshed. At this point, `access_token_expire_datetime` is still False because the shop has not been authorized yet.

Solution:
- The orders should only be fetched from those shops that are authorized with TikTok.
- Used the `access_token` field to determine whether a shop is authorized, as it is only populated after the authorization flow is successfully completed.

[this]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/controllers/onboarding.py#L52-L54

[here]: https://github.com/odoo/enterprise/blob/593409ca160863d3e985f3cf5e2aadda1d450b41/sale_tiktok/utils.py#L171

sentry-7631179329

Forward-Port-Of: odoo/enterprise#127148