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

User loginIn and loginNotIn inputs are incorrect types and don't influence query #1174

Closed
kellenmace opened this issue Mar 3, 2020 · 4 comments · Fixed by #1368
Closed
Assignees
Labels
effort: low around a day or less Good First Issue Issue that doesn't require previous experience with WPGraphQL impact: med minor perf improvements, fix broad userbase issues Status: In Progress Status: 🚀 Actionable Issues that have been curated, have enough info to take action, and are ready to be worked on Type: Bug Something isn't working
Milestone

Comments

@kellenmace
Copy link
Contributor

When running a WP_User_Query() in PHP, login__in and login__not_in accept an array of user logins to be included in/excluded from the query. Docs: https://developer.wordpress.org/reference/classes/WP_User_Query/prepare_query/.

When running a users query using WPGraphQL however, the corresponding loginIn and loginNotIn input fields each accept a single integer. They need to be updated to accept an array of user logins instead, and use those logins to influence the users query that ultimately gets executed.

Example Query

This query shows the input fields in question:

query {
  users(where: {
    loginIn: 123 # Should be an array of user logins.
    loginNotIn: 456 # Should be an array of user logins.
  }) {
    nodes {
      userId
      name
    }
  }
}

Expected behavior:

The loginIn and loginNotIn input fields would take an array of user logins as strings, which would then be used when the users query is run.

Actual behavior:

The loginIn and loginNotIn input fields each take a single integer, and are not used when the users query is run.

Plugin Version

WPGraphQL version: 0.7.0

@jasonbahl jasonbahl added Status: 🚀 Actionable Issues that have been curated, have enough info to take action, and are ready to be worked on Type: Bug Something isn't working effort: low around a day or less Good First Issue Issue that doesn't require previous experience with WPGraphQL impact: med minor perf improvements, fix broad userbase issues labels Mar 11, 2020
@jasonbahl
Copy link
Collaborator

jasonbahl commented Mar 11, 2020

This should be pretty straight forward to address. I believe all we need to do is change the Type of the fields for loginIn and loginNotIn to be 'type' => [ 'list_of' => 'String' ]. We'll need to make sure they are passing to the connection resolver properly as well, but I think this should be a pretty quick PR!

@holyblast
Copy link

same issue: #1140
but login itself is a string (user's slug name),
shouldn't the type of loginIn / loginNotIn be a list of String instead of Int?

@jasonbahl
Copy link
Collaborator

🤦‍♂ haha! yes. The issue right now is that it is an Int. I need to slow down when I type.

Should be changed to 'type' => [ 'list_of' => 'String' ]

@jasonbahl
Copy link
Collaborator

@holyblast I updated the comment above to properly reflect. Thanks!

@jasonbahl jasonbahl added this to the 1.0 release milestone Apr 24, 2020
jasonbahl added a commit to jasonbahl/wp-graphql that referenced this issue Jul 6, 2020
- This fixes the loginIn and loginNotIn argument field types for User connection queries to allow for list of strings as the input.
@jasonbahl jasonbahl self-assigned this Jul 6, 2020
jasonbahl added a commit that referenced this issue Jul 6, 2020
…gs-are-incorrect-type

Bug/#1174 login login not in args are incorrect type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: low around a day or less Good First Issue Issue that doesn't require previous experience with WPGraphQL impact: med minor perf improvements, fix broad userbase issues Status: In Progress Status: 🚀 Actionable Issues that have been curated, have enough info to take action, and are ready to be worked on Type: Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants