feat: validatiosn in actions
feat: query arguments
feat: add `Ash.Query.for_read/3`
feat: return changeset with API errors
feat: add case insensitive string `CiString`/`:ci_string`
feat: support `context/1` and `arg/1` in filter templates
feat: support targeting notifications with the `for` option
feat: add `ago/2` query function
feat: add basic arithmetic operators (+, *, -, /)
feat: `sensitive?` option for attributes
feat: `sensitive?` option for arguments
feat: `private` arguments, which can’t be set using `for_<action>`
feat: add `prevent_change` which will erase changes just before the changeset is committed
feat: add `match?` validation that supports a custom error message
feat: add `interval` type to support `ago/2` function
feat: add `url_encoded_binary` type
feat: add `function` type
improvement: `changing?` is now a validation
improvement: add `Transformer.get_persisted/3`
improvement: add `api` field to `Notification`
improvement: standardize errors, add `to_error_class`
improvement: use `Comp` everywhere
Improvement: use action on changeset if set by `for_<action_type>`
improvement: `action_failed?` field on change sets
improvement: remove ability for data layers to add operators (for now at least)
Improvement: Changeset.apply_attributes/2 now returns an error tuple
Improvement: add a bunch of new/informative errors
improvement: runtime filter now uses left join logic (a naive implementation of it)
improvement: support more filter templates in resources
Improvement: basic/naive type system for operators/functions
Fix: properly expand module aliases for options w/o compile time dependency
chore(engine): track changeset changes for the request with `manage_changeset?: true`
This is one of the most complicated parts of Ash. In order to pass
a filter statement to the satisfiability solver that we use, we have
to first transpile a *value* statement into a *boolean* statement.
This means that we need to embed the knowledge of mutual exclusivity
wherever possible. Authorization still works if the system doesn't know
the relationship between two value statements, as it will attach
the authorization filters if its not sure. But having this in place
should represent a fairly significant optimization in many cases.
Additionally, filter creation has a set of optimizations around the
`eq` and `in` operators to combine them whlie building a boolean
statement
