Pass client_id, audience at Auth0::Api::V2::ClientGrants#client_grants

[hkdnet]

Changes

I'd like to fetch a client grant by its client id.
We can't call Auth0::Api::V2::ClientGrants#client_grants with client_id while GET /api/v2/client-grants accepts client_id.

References

Public doc for GET /api/v2/client-grants
https://auth0.com/docs/api/management/v2#!/client_grants/get_client_grants

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

• This change adds unit test coverage
• This change adds integration test coverage
  • I'm very happy with adding integration tests for this but I can't run master's integration tests on my local.
• This change has been tested on the latest version of Ruby

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors
• Rubocop passes on all added/modified files
  • No. But master also fails.
• All active GitHub checks have passed

[hkdnet]

I met two GitHub check failures.

snyk

GitHub check ci/circleci: snyk is marked as Required but I think this is not required for all pull requests.
CircleCI workflow snyk only runs with context snyk-env, which is not available for me.
So snyk workflow for my PR is skipped as UNAUTHORIZED.
I believe this is a configuration error. Can someone take a look?

codecov/changes

Checked the error and read https://docs.codecov.io/docs/unexpected-coverage-changes but I have no idea why this happens.
Let me investigate more 🙏

[lbalmaceda]

This would be less breaking if put at the end. WDYT @davidpatrick ?

Also, I think we should include audience as well. Also optional @hkdnet 👍

[hkdnet]

This would be less breaking if put at the end.

An order of keyword arguments does not matter in Ruby.
I prefer putting before page and per_page because giving client_id changes responses more than other parameters. (If you prefer another style, I'm happy to follow it!)

[hkdnet]

Added audience as well. f7c3c9d

[lbalmaceda]

Those calling it with named arguments will not have a problem 👍 however those still using the standard way of passing arguments would run into a breaking change, as the argument they were sending is now pointing to a different variable.

Say someone today has this call:

# This works today
client_grants(1, 2) 

That would be the same as calling with named arguments:

# Without this PR
# def client_grants (page: nil, per_page: nil)
client_grants(page = 1, per_page = 2) 

Now say we put new parameters at the beginning:

# With this PR
# def client_grants (audience = nil, client_id = nil, page: nil, per_page: nil)
client_grants(audience = 'myaudience', client_id = 'yourclient', page = 1, per_page = 2)

That works, but as soon as we remove the name of the params, the user who had working code is now running into issues:

# With this PR
# def client_grants (audience = nil, client_id = nil, page: nil, per_page: nil)
client_grants(1, 2)

Behavior changes as 1 is taken as the audience, and 2 as the client id.

AFAIK Ruby works that way. I could be wrong, it's been years without coding ruby. 😅

[hkdnet]

Ruby has ordinary parameters, optional parameters, and keyword parameters.
Your concern is correct with optional parameters but this method is defined with keyword parameters.

Labels are required to pass values as keyword arguments. All users pass values with labels (or pass no values).

client.client_grants(1, 2) # this does not work. ArugmentError is raised
client.client_grants(page: 1, per_page: 2) # works
client.client_grants() # This also works because both page and per_page are optional.

In this case, adding keyword parameters before the existing keywords does not break anything. Here is a smaller example.

def f(a: nil)
  puts "a = #{a}"
end

f(a: 1) # a = 1

def f(b: nil, a: nil)
  puts "a = #{a}, b = #{b}"
end

f(a: 1, b: 2) # a = 1, b = 2
f(b: 2, a: 1) # a = 1, b = 2

# This still works well :)
f(a: 1) # a = 1, b = 

You can confirm users can use client_grants the same as before with these examples. These specs work well without changing.

• https://github.com/auth0/ruby-auth0/pull/209/files#diff-19c1e1d1d6e6aa44a0c115a794fa4a34R21
• https://github.com/auth0/ruby-auth0/pull/209/files#diff-19c1e1d1d6e6aa44a0c115a794fa4a34R45

[lbalmaceda]

Perfect. Then this is solved 👍 Thanks for your contribution

[lbalmaceda]

Thanks for pointing out the failing snyk check. I've updated that on this PR #210.

[hkdnet]

Thank you @lbalmaceda !