ja_resource
ja_resource copied to clipboard
vt-elixir
A behaviour to reduce boilerplate code in your JSON-API compliant Phoenix controllers without sacrificing flexibility.
I would like to specify the relationships and fields I want to return on every endpoint, instead of once per serializer module. From the docs I gather the only way...
After updating a pretty old project to Ecto 3.4 and Elixir 1.7, I found I had a whole bunch of failing tests anywhere where I was not overriding ja_resource's handle_delete....
So when a changeset is invalid, Ecto returns an `Ecto.InvalidChangesetError`. This is what should be used instead of ` @type validation_errors :: {:error, Ecto.Changeset.t}`, as otherwise you have to do...
This may be some what related to #45, but currently it looks like setting `parent_id` works for both create and update but permitted_attributes isn't getting nil attributes in order to...
As `The response SHOULD include a Location header identifying the location of the newly created resource` is mentioned in [JSON-API specification](http://jsonapi.org/format/#crud-creating-responses-201), I wonder if the location header should be put...
"Model" is frowned upon, we should update to something better. Some alternatives: Resource Module Schema Source Resource.module/0 ?
- Should have same api as phoenix json generator. - Should generate model if does not exist. - Should use JaSerializer if installed.
Hi! I've butchered the code a bit to fit our specific usecase (integrating with an authorization library, like [bodyguard](https://github.com/schrockwell/bodyguard)) My goal was to run authorization on the actual record, for...
In our project, we would like to use `ja_resource` but we're having issues with authorising users. In a lot of cases, the user being authorised to perform an action depends...
