# `MishkaCmsMigration.MigrationLog`
[🔗](https://github.com/mishka-group/mishka_cms_migration/blob/v0.0.1/lib/mishka_cms_migration/resources/migration_log.ex#L5)

One entry of a run's log: a step of its life (`step`), who took it (`user_id`, none for a job
that failed on its own or that Oban discarded), and what it said: the host the run reads from,
a finished step's counts and a failed step's reason. Nothing else of the run is kept, so an entry
never holds its connection or its secret.

The steps are the run's own (`MishkaCmsMigration.Resources.Notifiers.Steps`): `:connected` when
the run is created, `:dry_run_started`, `:dry_run_finished`, `:dry_run_failed`,
`:dry_run_cancelled`, the same five words for an import, and `:cancelled` for a run cancelled
while it waited. Written by that notifier alone, once each step is saved, as the system
(`authorize?: false`); every actor is refused `:record`.

Read by whoever may read the site's runs (`MishkaCmsMigration.MigrationRun`): a master reads every
site's entries, a site admin only their own site's. Each entry is broadcast on
`"migration_log:<site_id>:created"` and `"migration_log:created"`, which the Migration page's
Logs follow (`MishkaCmsMigration.Activity`).

# `t`

```elixir
@type t() :: %MishkaCmsMigration.MigrationLog{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  calculations: term(),
  counts: term(),
  id: term(),
  inserted_at: term(),
  reason: term(),
  run: term(),
  run_id: term(),
  site: term(),
  site_id: term(),
  source_host: term(),
  step: term(),
  user: term(),
  user_id: term()
}
```

# `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.

# `primary_key_matches?`

# `steps`

```elixir
@spec steps() :: [atom()]
```

Every step an entry may tell of, in the order a run goes through them.

---

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