Thanks! Are you able to come up with a test scenario for this? We've one polymorphic association in the spec dummy app, Article#tags, so maybe it could be leveraged in some spec to make sure we don't break these polymorphic associations in the future either?

Hiya @SebastianEdwards, are you able to show me an example of a JSONAPI::Resource class with a request that fails without your fix? I didn't quite catch what you were trying to say in your PR description.

If you could provide an example with this level of detail, that would be super awesome ☺️

Ping @SebastianEdwards ☝️ I'm waiting for your answer before I'm able to figure this out.

Cool - will come back with a test soon. Bit swamped w/ work at the moment!

Hiya @SebastianEdwards, still waiting here ☺️. If you don't have the time to create a test, would you be able to add some more details to what kind of resource this fixes? Something like this would be amazing to have:

Here's the setup:

Comment.new(id: 1, reviewing_user: user_with_id_2).save

class CommentResource < JSONAPI::Resource
  include JSONAPI::Authorization::PunditScopedResource

  has_many :tags
  has_one :article
  has_one :reviewer, relation_name: "reviewing_user", class_name: "User"
end

And we'd send this JSON API request:

PATCH /comments/1

"data": {
  "type": "articles",
  "id": "1",
  "relationships": {
    "reviewer": {
      "data": {
        "type": "user",
        "id": "3"
      }
    }
  }
}

@valscion

There is also a problem when we have has_one relationship and trying to save it with parent but sending null

class User
  belongs_to :nationality, class_name: 'Country'
end

PATCH /users/1

"data": {
  "type": "users",
  "id": "1",
  "relationships": {
    "nationality": null
    }
  }
}

So we need to add same functionality (when nil) to related_models_with_context also in 1.0.0.alpha3

now we have an error:

{
  "errors": [
    {
      "title": "Record not found",
      "detail": "The record identified by  could not be found.",
      "code": "404",
      "status": "404"
    }
  ]
}

Released v1.0.0.alpha4 with the fix to @jpalumickas' issue with the PATCH request. I'm afraid the issue that @SebastianEdwards has is still a mystery to me, as I haven't received the details I need to understand what this issue is about.

@SebastianEdwards, still waiting for more details on your issue. I'd love if we could fix the issue you're facing and have a spec ensuring we don't break it in the future.

See #54 (comment) for what I'd need to understand what this issue is about.

Hi @valscion,

Sorry I've been such a slack bastard with this. If only good intentions could write tests!

My issue was exactly what @jpalumickas had described - my front-end code would send null in the place of a { "data": { "id": 1, "type": "thing" } } object rather than just leaving the key off entirely. This null wasn't handled in the processor which expected a hash.

Looks like the fix has been merged in another PR with tests so happy days! (Thanks @jpalumickas!)

Can you confirm that your case is solved by the fix done in #69?

Yup. #69 fixes the issue - will close this.

Thanks for following up with the confirmation! ❤️