Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graphene query single and multiple model filtering #3

Open
Eraldo opened this issue Jul 25, 2018 · 4 comments
Open

Graphene query single and multiple model filtering #3

Eraldo opened this issue Jul 25, 2018 · 4 comments

Comments

@Eraldo
Copy link
Owner

Eraldo commented Jul 25, 2018

As a developer, I want to be able to define limitations on which model instances can be fetched by a DjangoFilterConnectionField even if queried indirectly as a reverse foreign key relation of another model.

Currently my filters only apply where I explicitly set them via DjangoFilterConnectionField -- not on related entry points.

I saw some code from stephrdev which would fix this. With the comment that it would probably not work as is in my repo.

stephrdev: Can you please point me to code again?

@rdev
Copy link

rdev commented Jul 25, 2018

Hi! As I said in your #2, I have no idea what this project is and why I was tagged on it

@Eraldo
Copy link
Owner Author

Eraldo commented Jul 29, 2018

Sorry, I meant another person and mixed up the usernames. ;)
(I menat @stephrdev)

@rdev
Copy link

rdev commented Jul 29, 2018

No worries 👍

@stephrdev
Copy link

To control the available model instances on a manager (no matter which direction) you can override the resolve_<[related] manager name> or replace the connection class of the object type.

To prevent related managers all around in the graph schema, it is always a good idea to use only_fields Meta option on DjangoObjectType to control which fields are exposed at all. You might not need all of the fields.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants