What Ithibati puts on an invitation, and what an invitation owes Ithibati.

The table belongs to the application, like the accounts table and for the same reason. An invitation says what somebody is being invited to, such as a role, a site or a team, and that is exactly what this library keeps out of itself. So you declare the schema in your application, and this macro adds Ithibati's half of it:

defmodule MyApp.Accounts.Invitation do
  use Ecto.Schema
  import Ecto.Changeset

  alias Ithibati.Schema.Identifier
  alias Ithibati.Schema.Invitation

  use Invitation, identifier: :email, format: Identifier.email_format()

  schema "invitations" do
    ithibati_invitation()

    field :role, Ecto.Enum, values: [:admin, :author]
    belongs_to :site, MyApp.Sites.Site

    timestamps(type: :utc_datetime_usec)
  end

  def changeset(invitation, attrs, opts \ []) do
    invitation
    |> invitation_changeset(attrs, opts)
    |> cast(attrs, [:role, :site_id])
    |> validate_required([:role, :site_id])
  end
end

The options are the account macro's. identifier: is required, and it is the one you have to write out. format: takes a regular expression, and Ithibati.Schema.Identifier.email_format/0 offers a pattern for addresses. constraint_name: and unique_index: name the unique index on the token digest rather than on the identifier. You may write each of the three value options inline, or name a module attribute standing above the use line.

identifier: names the field the invitee is addressed by. It has to be the same field the account schema uses, and Ithibati.Config.invitation_schema/0 refuses the pair when it is not. Ithibati cannot read the field from the account schema instead, because a schema's fields are fixed when the module compiles, and which schema is the account's is read at runtime.