Constant INVITATION_TOML 

pub const INVITATION_TOML: &str = r#"
[resource]
name = "invitation"
scope = "organization"
timestamps = true

[permissions]
list   = "role:admin"      # admins see who is still pending
read   = "role:admin"
create = "private"         # issued by POST /auth/invitations, never by hand:
                           # a row written directly has no token to send
update = "private"
delete = "role:admin"      # revoking is deleting the row

[fields.email]
type = "string"
required = true
max_length = 320

[fields.role]
type = "string"            # the role they will hold once they accept

[fields.token_hash]
type = "string"
required = true
unique = true
hidden = true

[fields.invited_by]
type = "reference"
references = "user"
on_delete = "set_null"

[fields.expires_at]
type = "timestamp"
required = true

# Set when the invitation is used. A row with this filled in is history, kept
# so "who let them in, and when" survives the membership being edited later.
[fields.accepted_at]
type = "timestamp"
"#;

An invitation to join an organisation, addressed to someone who may not have an account yet.

This is the table behind POST <base>/auth/invitations. The emailed link carries a token whose hash is what lives here, for the same reason an API key’s does: a leaked database should not be a pile of working links.

It is org-scoped, so an admin only ever sees the invitations to their own organisation, and read/create are role:admin — the endpoints that a person without an account uses (previewing a link, accepting it) are not CRUD on this resource at all, and reach the row through the token they were sent rather than through the API’s permissions.