# `MishkaBlog.AutoPosting`
[🔗](https://github.com/mishka-group/mishka_blog/blob/v0.0.1/lib/mishka_blog/resources/auto_posting.ex#L5)

Manages auto-posting configurations in the MishkaBlog plugin with full versioning support.

This resource represents auto-posting configurations that enable automated publishing
of blog posts to external platforms (social media, newsletters, etc.). Each configuration
belongs to a specific site and plugin, defining how and when content should be
automatically distributed.

Auto-posting configurations feature full version control through PaperTrail integration,
tracking all changes with snapshot-based history including configuration updates
and activation toggles. The resource implements soft deletion via archival and
provides comprehensive configuration management through flexible key-value storage.

The config field uses a map structure where each key represents a configuration
parameter with metadata about its type, value, and help text. This allows plugins
to define their own configuration schemas dynamically while maintaining a consistent
interface for administration.

The unique constraint on plugin and site_id ensures each plugin has only one
configuration per site. Database-level constraints ensure data integrity and
prevention of modifications to archived configurations. Multi-tenant isolation
ensures configurations are properly segregated between sites.

# `t`

```elixir
@type t() :: %MishkaBlog.AutoPosting{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  archived_at: term(),
  calculations: term(),
  config: term(),
  description: term(),
  id: term(),
  inserted_at: term(),
  is_active: term(),
  latest_version: term(),
  name: term(),
  paper_trail_versions: term(),
  plugin: term(),
  recent_versions: term(),
  site: term(),
  site_id: term(),
  sorted_versions: term(),
  updated_at: term(),
  version_count: 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*