Skip to content

Username case-sensitivity → duplicate accounts (Aareon defect)

A platform-level Aareon Mobile defect: the app treats the same user as multiple separate accounts when their username arrives in different letter-case. One AD identity fragments into several "phantom" accounts, so tasks scatter and completed forms can fail to save.

Diagnosed from Halo ticket 20472 (Fire Risk Assessments completed then "returned blank", intermittently — a statutory-compliance impact). Root cause confirmed against 1stTouch_PrtyLive.

Symptoms

  • "Jobs not showing" — a user only sees the tasks assigned to the exact username casing they're logged in under (Dom Carpenter: "when an account is logged in, it only shows the jobs on that account rather than all of them").
  • Completed forms disappear / re-issue blank — a form completed under one casing does not reconcile to a task owned by a different casing, so the submission isn't persisted.
  • Related tickets share the theme: 0022472 (jobs not auto-dispatching), 0022339, 0022317.

Root cause

The app keys identity on the exact, case-preserved username string, but the SQL collation is case-insensitive — so case-variants are distinct to the app yet identical to the DB. The split is mostly in the domain prefix and tracks the client platform:

  • Windows client transmits LINCOLNSHIREHP\<user> (upper-case domain)
  • Android / tablet client transmits lincolnshirehp\<user> (lower-case domain)

So the same person becomes two accounts depending on the device used. Proven for Anthony Walker via ClientManagement.UserConnectionRecord: his Windows client = LINCOLNSHIREHP\WalkeA, his Samsung SM-T865 tablet = lincolnshirehp\Walkea. His FRA tasks are owned by …\WalkeA but completed on the tablet (…\Walkea) → the completion is lost.

Scale (Live, 29/06/2026)

  • 472 distinct case-sensitive usernames for 354 real users in Task.Task.
  • 107 users hold 2–3 case-variants each = 118 duplicate phantom accounts.
  • Accounts are AD-backed: Profile.Users is empty for these; identities live in Profile.ExternalUser, and fragmented identity is tracked in Task.Task.UserName, ClientManagement.UserConnectionRecord, Tokens.DeviceCodes, DeviceSettings.

How to diagnose (read-only SQL)

Run via the SQL admin launcher (see platform/management-studio-api.md §7): 

-- Case-sensitive casings for one user (default collation hides this — force a CS collation):
SELECT UserName COLLATE Latin1_General_CS_AS AS casing, COUNT(*)
FROM [1stTouch_PrtyLive].[Task].[Task] WHERE UserName LIKE '%<user>%'
GROUP BY UserName COLLATE Latin1_General_CS_AS;

-- Which casing each device logs in under:
SELECT UserName COLLATE Latin1_General_CS_AS AS casing, DeviceName, ClientVersion, ConnectedAt
FROM [1stTouch_PrtyLive].[ClientManagement].[UserConnectionRecord]
WHERE UserName LIKE '%<user>%' ORDER BY ConnectedAt DESC;
The full duplicate list is generated by scratch/dup_accounts_list.sql (→ dup_accounts.csv). Gotcha: a plain GROUP BY UserName hides the duplication because the DB collation folds case — you must COLLATE Latin1_General_CS_AS to see it.

Workaround (LHP) & permanent fix (Aareon)

  • Per-user workaround: standardise the user's login to one canonical casing on all devices (especially the Android tablet, which sends the lower-case domain), then remove the duplicate case-variant credential/device records so tasks consolidate. (Dom's "delete the accounts in credentials and sign back in as the correct-case account".)
  • Permanent fix (raised with Aareon): normalise username case (domain prefix in particular) at authentication, task allocation/visibility, and completion reconciliation; one-off merge of the 118 existing duplicates. Bug report: scratch/halo_tickets/ticket_20472/aareon_bug_report_20472.md.
  • Lost FRAs are unrecoverable (never persisted) — re-do after the casing is corrected.