changes

fusion_login_audit/models/res_users.py

@@ -346,15 +346,30 @@ class ResUsers(models.Model):
         string='Login Audit Count',
         compute='_compute_x_fc_login_audit_count',
     )
+    # NON-STORED on purpose — do NOT re-add store=True.
+    #
+    # These were store=True computed-from-the-audit-One2many. That meant every
+    # successful-login audit row (written through an INDEPENDENT
+    # registry.cursor(), see _fc_record_login_event) forced a recompute that
+    # flushed a write-back onto THIS res_users row. During portal-invitation
+    # acceptance the request has already locked that row (auth_signup just set
+    # the password in the same transaction), so the audit cursor's write-back
+    # blocked on the request's own row lock while the request's Python blocked
+    # waiting for the audit cursor — a self-deadlock Postgres cannot detect
+    # (the holder shows 'idle in transaction', not lock-waiting). Workers
+    # wedged for up to limit_time_real (20 min) and odoo-westin went
+    # unresponsive every time an invite was accepted (issue 2026-06-03).
+    #
+    # Keeping them non-stored means creating an audit row never touches
+    # res_users. They compute on read (display-only on the user form). The
+    # regression guard is tests.test_last_login_fields_not_stored.
     x_fc_last_successful_login = fields.Datetime(
         string='Last Successful Login',
         compute='_compute_x_fc_last_successful_login',
-        store=True,
     )
     x_fc_last_login_ip = fields.Char(
         string='Last Login IP', size=45,
         compute='_compute_x_fc_last_successful_login',
-        store=True,
     )
 
     @api.depends('x_fc_login_audit_ids')