# `MishkaDocument.SectionTag`
[🔗](https://github.com/mishka-group/mishka_document/blob/v0.0.1/lib/mishka_document/resources/section_tag.ex#L5)

Manages the many-to-many relationship between documentation sections and tags.

This resource serves as the join table that associates sections with tags,
enabling sections to have multiple tags and tags to categorize multiple sections.
Each record represents a tag assignment, indicating that a section is tagged
with a specific tag for content organization and discovery.

The resource implements upsert functionality through the assign action, preventing
duplicate section-tag assignments while allowing efficient bulk updates.
The unique constraint on section_id and tag_id pairs ensures that each section
can only be assigned a specific tag once, maintaining data integrity.

Access to this resource is controlled through policies that allow manipulation
either through the Section or Tag resource relationships or by users with
administrative privileges. This ensures that tag assignments can only be
modified by authorized actors.

An admin who is a master (a user with no site) reaches every site's rows; a site admin only rows
whose section is on its own site. `:assign` takes only a section and a tag of the site the write is
made for — the tenant, or the actor's own site when there is no tenant — see
`MishkaCmsCore.Runtime.Resources.Validations.TenantIsolation`.

# `t`

```elixir
@type t() :: %MishkaDocument.SectionTag{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  calculations: term(),
  inserted_at: term(),
  section: term(),
  section_id: term(),
  tag: term(),
  tag_id: term(),
  updated_at: 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?`

---

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