A user changeset for updating account type and organization fields.

Checks if a user is an admin or owner.

Examples

iex> admin?(user)
true

Confirms the account by setting confirmed_at.

A user changeset for updating custom fields.

Custom fields are stored as JSONB and can contain arbitrary key-value pairs.

Examples

iex> custom_fields_changeset(user, %{custom_fields: %{"phone" => "555-1234"}})
%Ecto.Changeset{valid?: true}

iex> custom_fields_changeset(user, %{custom_fields: "invalid"})
%Ecto.Changeset{valid?: false}

@spec display_name(t() | nil) :: String.t()

What to call this person when showing them TO OTHER PEOPLE.

The one canonical answer. Before this existed there were half a dozen private copies, several of which ended || user.email — which is how a public issue board came to print commenters' full addresses next to their words, indexed and scrapeable.

The chain, first non-blank wins:

organization account's name    (an org has no first/last)
first + last name
username
the local part of the email    (before the "@")
"User"

Never the full email. The local part is not anonymity — john.smith@… still reads as "john.smith" — but it carries no domain, is not directly mailable, and is not harvestable as an address.

Every rung is trimmed and rejected when blank: full_name/1 happily returns "" for a first name of " ", and an unguarded chain stops dead on it.

Only fields the USER wrote about themselves. A name recorded by somebody else — phoenix_kit_staff's HR record, a CRM contact label — must never reach this, whatever its quality: the people with no name set are exactly the ones who are pseudonymous by choice or inertia, and publishing an HR-entered legal name on their behalf is not ours to do.

For "does this person have a real name at all", keep using full_name/1 — it still answers nil, and that question is still worth asking.

Examples

iex> display_name(%User{first_name: "John", last_name: "Doe"})
"John Doe"

iex> display_name(%User{first_name: nil, username: "jdoe"})
"jdoe"

iex> display_name(%User{first_name: nil, username: nil, email: "j@x.com"})
"j"

A user changeset for changing the email.

It requires the email to change otherwise an error is added.

Returns list of fields excluded from get_user_field for security.

These fields contain sensitive or internal data and should not be accessed via the generic field accessor.

Examples

iex> excluded_fields()
[:password, :current_password, :hashed_password, :__meta__, :__struct__]

Gets the user's full name by combining first and last name.

Examples

iex> full_name(%User{first_name: "John", last_name: "Doe"})
"John Doe"

iex> full_name(%User{first_name: "John", last_name: nil})
"John"

iex> full_name(%User{first_name: nil, last_name: nil})
nil

Generate a username from an email address.

Takes the part before @ symbol, converts to lowercase, replaces dots with underscores, and ensures it meets validation requirements.

Examples

iex> generate_username_from_email("john.doe@example.com")
"john_doe"

iex> generate_username_from_email("user@example.com")
"user"

Gets all roles for a user.

Examples

iex> get_roles(user)
["Admin", "User"]

A user changeset for guest checkout.

Creates a temporary user with a random password for guests who complete checkout without registering. The user will have confirmed_at = nil until they verify their email.

Features

• Generates a random secure password (required by DB constraint)
• Sets custom_fields.source to "guest_checkout" for tracking
• Generates UUID and username automatically
• Does NOT confirm the email (confirmed_at remains nil)

Examples

iex> guest_user_changeset(%User{}, %{email: "guest@example.com", first_name: "John"})
%Ecto.Changeset{valid?: true}

Checks if a user has a specific role.

Examples

iex> has_role?(user, "Admin")
true

iex> has_role?(user, "Owner")
false

Checks if a user is an owner.

Examples

iex> owner?(user)
true

A user changeset for changing the password.

Options

• :hash_password - Hashes the password so it can be stored securely in the database and ensures the password field is cleared to prevent leaks in the logs. If password hashing is not needed and clearing the password field is not desired (like when using this changeset for validations on a LiveView form), this option can be set to false. Defaults to true.

A user changeset for updating profile information.

Options

• :validate_email - Validates the uniqueness of the email, in case you don't want to validate the uniqueness of the email (like when using this changeset for validations on a LiveView form before submitting the form), this option can be set to false. Defaults to true.

A user changeset for registration.

It is important to validate the length of both email and password. Otherwise databases may truncate the email without warnings, which could lead to unpredictable or insecure behaviour. Long passwords may also be very expensive to hash for certain algorithms.

Options

• :hash_password - Hashes the password so it can be stored securely in the database and ensures the password field is cleared to prevent leaks in the logs. If password hashing is not needed and clearing the password field is not desired (like when using this changeset for validations on a LiveView form), this option can be set to false. Defaults to true.

• :validate_email - Validates the uniqueness of the email, in case you don't want to validate the uniqueness of the email (like when using this changeset for validations on a LiveView form before submitting the form), this option can be set to false. Defaults to true.

An optional :custom_fields map may be included in attrs to persist arbitrary key-value metadata alongside the user record in a single atomic insert. If omitted, custom_fields defaults to %{}.

A user changeset for updating active status.

A user changeset for updating timezone preference.

Examples

iex> timezone_changeset(user, %{"user_timezone" => "+5"})
%Ecto.Changeset{valid?: true}

iex> timezone_changeset(user, %{"user_timezone" => "invalid"})
%Ecto.Changeset{valid?: false}

Unconfirms the account by setting confirmed_at to nil.

Verifies the password.

If there is no user or the user doesn't have a password, we call Bcrypt.no_user_verify/0 to avoid timing attacks.

Validates the current password otherwise adds an error to the changeset.

Validates a locale value for format and existence.

Returns :ok if valid, {:error, message} if invalid.

Examples

iex> validate_locale_value("en-US")
:ok

iex> validate_locale_value("invalid")
{:error, "must be a valid locale format (e.g., en-US, es-MX)"}