An intervention progressing through the real ex4pm lifecycle calculus:
proposed -> admitted -> actuated -> verified
|
+-> refused (terminal, from :proposed or :admitted)The :status attribute is the AshStateMachine state attribute -- it is not
hand-defined here; AshStateMachine.Transformers.AddState generates it with
the exact one_of constraint matching every declared state, and enforces
that every declared transition corresponds to a real update action.
Summary
Types
@type t() :: %Ex4pm.Domain.Intervention{ __lateral_join_source__: term(), __meta__: term(), __metadata__: term(), __order__: term(), aggregates: term(), authority_ref: term(), calculations: term(), id: term(), kind: term(), payload: term(), receipt_hash: term(), status: term(), subject_hash: term() }
Functions
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
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
Same as input/1, except restricts the keys to values accepted by the action provided.