PhoenixKit.Mentions.Users (phoenix_kit v2.3.0)

The @ side of mentions: finding a person to ping.

Separate from the # fan-out because a ping is always a person, and people are core's — there is no module to ask and no permission model to federate. What there IS is a decision about who may be pinged at all, and the rule shipped here is deliberately narrow:

only active, confirmed accounts (a pending invite cannot be pinged into existence, and a deactivated account is not a colleague);
only accounts that can reach the admin area at all, since every surface a mention currently appears on lives there — pinging a customer about an internal note would be the leak, not the feature.

Matching is on username, then name, then email — email last and only on a prefix, so the typeahead cannot be used to confirm whether an address has an account by pasting it in.

Summary

Functions

display_name(user)

The label a mention of this user carries — what the author saw when they picked, and the fallback when the account is later deleted.

search(query, opts \\ [])

People matching query, shaped for the typeahead.

Functions

display_name(user)

@spec display_name(PhoenixKit.Users.Auth.User.t()) :: String.t()

The label a mention of this user carries — what the author saw when they picked, and the fallback when the account is later deleted.

search(query, opts \\ [])

@spec search(
  String.t(),
  keyword()
) :: [map()]

People matching query, shaped for the typeahead.

An empty query returns a short list of candidates rather than nothing: opening the picker with @ and seeing who is around beats a blank box.

The admin-area rule is evaluated in SQL (Owner/Admin role, or any phoenix_kit_role_permissions grant), not per-row after fetch. The earlier over-fetch + Scope.for_user/1 filter issued two queries per candidate — up to ~128 round trips per keystroke on a full page of results.