# `MishkaCmsCore.Runtime.Redirect`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/resources/redirect.ex#L5)

One address of a site answered with a redirect to another — a page or a file that moved, and the
visitors, search engines and shared links that still ask for its old address.

A rule is a site's own (`global? false`): `from_path` is the address asked for, `to` where the
visitor is sent — a path on the same site or a full `http(s)` address — with `status` 301, 302,
307 or 308. An inactive rule is kept and answers nothing.

## Addresses

`from_path` is stored as `MishkaCmsCore.Runtime.Redirects.normalize_path/1` writes it: one leading
`/`, no scheme or host, no query or fragment, no trailing `/` but the root's, and its
percent-escapes decoded, so a rule matches the address however a browser spelled it. `to` is stored
as written. A rule is refused when its target is its own source, and when following the site's
active rules from its target comes back to an address already on the way.

## Served from ETS

Every rule that is active is held by `MishkaCmsCore.Runtime.States.RedirectsState`, loaded at boot
and kept current off this resource's broadcasts. `MishkaCmsCore.Runtime.Plugs.SiteLookupPlug` asks
it once the request's site is known, before any page is resolved — see
`MishkaCmsCore.Runtime.Redirects.redirect/2`.

## Who writes them

Anyone under the request's surface reads a site's rules; writing them takes the redirect section,
`admin:dashboard:runtime:redirect` or `admin:api:runtime:redirect`. A master reaches every site, a
site user its own.

# `t`

```elixir
@type t() :: %MishkaCmsCore.Runtime.Redirect{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  active: term(),
  aggregates: term(),
  archived_at: term(),
  calculations: term(),
  description: term(),
  from_path: term(),
  id: term(),
  inserted_at: term(),
  paper_trail_versions: term(),
  site: term(),
  site_id: term(),
  sorted_versions: term(),
  status: term(),
  to: term(),
  updated_at: term()
}
```

# `__guarded_change__`

Apply the full GuardedStruct pipeline (sanitize → validate → derive →
main_validator) to `attrs` and return either `{:ok, transformed_attrs}`
or `{:error, errors}`. Wire this into an `Ash.Resource.Change` to plug
guardedstruct rules into Ash's changeset pipeline.

The function is named `__guarded_change__` because it does more than
validate — it can also transform values (trim, downcase, slugify,
auto-fill, etc.) before they reach the data layer.

# `__guarded_field_meta__`

O(1) lookup of a field's compile-time metadata by name. Returns
`nil` for unknown fields.

# `__guarded_field_name_set__`

Compile-time-baked `MapSet` of every field name owned by the
`guardedstruct` block. Used by `GuardedStruct.AshResource.Change`
to decide, in O(1), whether a key in `changeset.atomics`
belongs to the pipeline.

# `default_short_name`

# `input`

```elixir
@spec input(values :: map() | Keyword.t()) :: map() | no_return()
```

Validates that the keys in the provided input are valid for at least one action on the resource.

Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g `%MyResource{value: 1, value: 2}`. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g

```elixir
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
```

# `input`

```elixir
@spec input(values :: map() | Keyword.t(), action :: atom()) :: map() | no_return()
```

Same as `input/1`, except restricts the keys to values accepted by the action provided.

# `json_api_match_route`

# `primary_key_matches?`

---

*Consult [api-reference.md](api-reference.md) for complete listing*