Giters

laravel-json-api / laravel

JSON:API for Laravel applications

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[ISSUE] Unable to get filters working in ResourceQuery class

fali12329 opened this issue · comments

commented

Description: I'm having trouble getting filters to work in my ResourceQuery class. I added JsonApiRule::filter()->forget('id')->allow('country_id') to my code, but I keep getting an error message saying "Filter parameter 'country_id' is not allowed". I've double-checked that I'm using the correct syntax for the JsonApiRule::filter() method, but I'm still unable to get filters to work.

Steps to reproduce:

  1. Add JsonApiRule::filter()->forget('id')->allow('country_id') to ResourceQuery class
  2. Try to use the country_id filter parameter
  3. See the error message "Filter parameter 'country_id' is not allowed"

Expected behavior: I should be able to use the country_id filter parameter in my ResourceQuery class.

Actual behavior: I'm unable to use the country_id filter parameter and keep getting an error message.

Additional information: I'm using the latest version of the library and have tried checking my server logs for any error messages, but haven't found anything helpful. Any help or suggestions would be greatly appreciated!

commented

Hey! Thanks for reporting. I'll need to look into this. It's possible I didn't intend forget() and allow() to both be used at the same time, i.e. was thinking it'd be one or the other. If that is the case, then I'll need to fix it so both work together. Will investigate.

commented

Is there any possible work-around to this? We're on a tight Sprint schedule and this is a blocker for us.

commented

Looking at the code, I can't see a problem.

You mentioned you're doing this on the ResourceQuery class. Is that correct, or should it be the ResourceCollectionQuery class?

commented

btw, not saying there isn't a problem - just can't see it by looking at the code in these places:
https://github.com/laravel-json-api/validation/blob/f1e984cd587a86a57da23af00fa1e9c2809b3161/src/Rules/AbstractAllowedRule.php#L67-L87

commented

@genyded any news on whether this is definitely a bug? i.e. just need confirmation you're sure you're using the rule on the correct class for the GET request you're sending?

unfortunately I'm out after work today so can't help this evening. can look at it after work on Friday.

commented

We're wrong on it now. Will keep you posted.

commented

Whenever you get a chance, there is something off here. Even with the Resource Collection Query, the filter with forget() and allow() at the same time does not work.

commented

Ok, thanks for confirming - will take a look.

commented

Just taken a look at this today. There isn't a problem in the allowed filter param rule object, as there's existing unit tests for this scenario that are passing:
https://github.com/laravel-json-api/validation/blob/1837a97a20153246207adaae6703e8bd340d06ea/tests/Unit/Rules/AllowedFilterParametersTest.php#L38-L68

I'm wondering why you're using allow() for country_id? Shouldn't it have a filter class on your schema, in which case you wouldn't need to explicitly allow it?

What's the HTTP status code when you get that error message about country_id, and can you share the JSON payload for the response - containing the JSON:API error objects?

commented

OK, it turns out that a relationship was missing from one of the applicable schemas. One thing that I thought I saw in the docs at some point was a comment along the lines of 'Everything MUST be in the Schema, but in trying to find it now, I cannot seem to locate it. Anyway, when we bring on new developers as was the case here, the docs should make it VERY obvious that ALL attributes MUST be in the Schemas for all resources in order for everything else to work correctly.

Also, the error status was 400 and all the message really said was 'Not Allowed', so we were looking all over the Queries for issues, and nothing really indicated the Schema was the issue. Not sure if there is a better way to handle that, but if there is it would make things a lot clearer, easier.

We love JSONAPI, but the docs seem really isolated and segregated. It would also be nice to have a sample app with auth and everything in it. I think this issue can be closed though,

commented

Thanks for the response. I'm still wondering where that error was coming from though? As in, I'm a bit confused it was a 400 when I would have thought the error was coming from elsewhere in the stack. Don't expend any time answering that question - more just raising it to indicate I'm not 100% clear what's happened in this case.

As for the docs, the problem is they are vast. I.e. I'm not sure how to make them less segregated, seeing as there is an absolute tonne of material to cover, which therefore needs to be split across multiple chapters.

Having said that, I can see that actually if I rolled validation of filter params into the filter params chapter itself - rather than it being a separate query params validation chapter - that might help. Is that what you mean?

As a side note, I am starting to come to the conclusion that validation probably needs to be defined on the field classes, filters, etc themselves, rather than separately. I've resisted that because it doesn't feel optimal in terms of performance, but the current separation probably leads to more confusion than it is worth.