# `Diffo.Provider.Party`
[🔗](https://github.com/diffo-dev/diffo/blob/v0.9.0/lib/diffo/provider/components/party.ex#L5)

Abstract Party reader — plumbing, not a TMF subtype recommendation.

TMF632 treats Party as abstract; the concrete subtypes are
`Diffo.Provider.Organization` and `Diffo.Provider.Individual`. Use those
(or your own domain leaf composed from `BaseParty` + the matching
`BaseOrganization` / `BaseIndividual` fragment) for any **new** Party data.

This resource is kept in core minimally to serve three roles:

  1. **Abstract reader for projection bootstrap.** `Diffo.Provider.get_party_by_id!/1`
     and friends load via this resource so `AshNeo4j.worlds/1` can project
     the loaded node to its outermost concrete world. Symmetric with how
     `Diffo.Provider.Place` (the abstract reader for Place) and
     `Diffo.Provider.Instance` (the abstract reader for Instance) serve
     their respective cascades.
  2. **PartyRef-typed placeholder.** A Party record with `type: :PartyRef`
     and `referred_type:` set represents a reference to an externally-managed
     Party. `Diffo.Provider.create_party!(:PartyRef, %{referred_type: :X, ...})`
     routes to this resource's `:create` action.
  3. **`:Entity`-typed abstract Party.** Diffo extends the TMF632 type enum
     with `:Entity` for party-like aggregates that aren't strictly Organization
     or Individual. `Diffo.Provider.create_party!(:Entity, %{...})` routes
     here.

See `Diffo.Provider.BaseParty` for the underlying fragment, attributes,
validations, and TMF `@type` / `@referredType` wire mapping.

## Preferred API

Production code should use the typed subtype leaves (`Organization` /
`Individual`) or, more ergonomically, the type-atom dispatcher on
`Diffo.Provider`:

    Diffo.Provider.create_party!(:Organization, %{...})

Reads go through the dispatcher's projection path:

    Diffo.Provider.get_party_by_id!(id)    # returns concrete subtype struct

An Ash Resource for a TMF Party

# `t`

```elixir
@type t() :: %Diffo.Provider.Party{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  calculations: term(),
  created_at: term(),
  external_identifiers: term(),
  href: term(),
  id: term(),
  name: term(),
  notes: term(),
  party_refs: term(),
  referred_type: term(),
  type: 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*