Overhaul Upserts in 4.x
- Dominant language
- Elixir
- Stars
- 2.5k
- Forks
- 422
- Avg merge
- 23h 26m
- Merged PRs (30d)
- 46
Description
Upserts are currently very "dumb", insofar as they do not apply any action logic. From a conceptual standpoint, however, they can and should be modeled as a "create or read and update" operation. To accomplish this, the following changes would be made:
Introduction of four new options:
- `upsert_read_action - defaults to primary read`
- `upsert_update_action - defaults to primary update`
- `authorize_upsert_read - defaults to true`
- `authorize_upsert_update - defaults to true`
If authorizing the read, then the authorization rules of the primary read will be applied to `changeset.filter`.
If authorizing the update, then the authorization rules of the update will be applied to `changeset.filter`, using `error(...)` to produce a forbidden error in data layers that support it.
Contributor guide
Research direction
Start by tracing the upsert flow and the changeset.filter entry point in the Ash codebase; the issue does not name specific files or tests. Compare the primary read and update actions and the existing authorization path. Done means the four options have the stated defaults, authorization applies to changeset.filter as described, and supported data layers produce forbidden errors through error(...).
Written by the indexing model from the issue text.
Assessment
- Tech stack
- elixir
- Domain
- authorization, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100