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

Manages team structures in the MishkaBlog plugin with full versioning support.

This resource represents teams that can contain multiple bloggers. Teams provide a way to
organize bloggers into groups working on the same content areas.

Each team belongs to a specific site and has a unique slug for URL identification.

## Permissions attached to a team

A team can carry `MishkaCmsCore.Accounts.Permission` rows (`permission_ids`, and the
`:assign_permissions`, `:add_permission` and `:remove_permission` actions). Changing them needs
the permission area on the request's surface (`admin:dashboard:permission` or
`admin:api:permission`) besides the blog's own post area, and a site's admin attaches only
permissions it holds itself: each attached row is a `MishkaBlog.TeamPermission`, which asks
`MishkaCmsCore.Accounts.Validations.GrantWithinActorScope`. Members do not inherit them: every
gate reads the permissions a user holds itself.

Team profiles feature full version control through PaperTrail integration, tracking
all changes with snapshot-based history and the ability to restore previous versions.
The resource implements soft deletion via archival and provides comprehensive
metadata management for team organization.

Database-level constraints ensure data integrity with slug validation and prevention
of modifications to archived teams. Multi-tenant isolation ensures teams are properly
segregated between sites. The resource provides extensive API actions for external
integrations and maintains complete audit trails of all modifications.

# `t`

```elixir
@type t() :: %MishkaBlog.Team{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  archived_at: term(),
  avatar_url: term(),
  calculations: term(),
  cover_image_url: term(),
  description: term(),
  follower_count: term(),
  followers: term(),
  id: term(),
  inserted_at: term(),
  latest_version: term(),
  master_members: term(),
  master_members_join_assoc: term(),
  member_count: term(),
  members: term(),
  members_join_assoc: term(),
  name: term(),
  paper_trail_versions: term(),
  permissions: term(),
  permissions_join_assoc: term(),
  recent_versions: term(),
  site: term(),
  site_id: term(),
  slug: term(),
  sorted_versions: term(),
  status: term(),
  tenant_members: term(),
  tenant_members_join_assoc: 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*