Add **params for all collection endpoints

[timchaston]

Hi,

I realised I needed to be able to use the 'limit' and 'offset' pagination parameters for collections, otherwise I was only able to pull down the first 20 of any particular thing (specifically I needed to be able to access more than 20 custom fields).

I've added double-splat params to all the collection endpoint methods so that they can be supplied, as can anything else, rather than adding an explicit and specific arguments for them.

Let me know if you prefer another approach.

Also, I haven't written any tests for 'limit' and 'offset' (well, I did, but only for one endpoint, and it was hacky, so I figured I'd be better off getting feedback before spending the time on writing them for more endpoints). Let me know if you have any suggestions/preferences for tests. Do the pagination parameters need to be tested for every one of the collection endpoints? Also, do we need to test large numbers of items, or is 2 sufficient, do you think? Currently there's no easy way to generate an arbitrary number of different users set up. I see factory_bot is in there, but not set up for Contacts at least (in my hacky test, I just inserted counter into the email address to create 50 Contacts).

[codeclimate]

The PR diff size of 15160 lines exceeds the maximum allowed for the inline comments feature.

[codeclimate]

The PR diff size of 34454 lines exceeds the maximum allowed for the inline comments feature.

[codeclimate]

The PR diff size of 34454 lines exceeds the maximum allowed for the inline comments feature.

[timchaston]

Fixes made for bugs and style.

Rubocop and codeclimate are still unhappy, but with issues that are present on master. Thought I should mention, also, that rubocop passes just fine locally, so I'm not quite sure why it's failing here.

[mhenrixon]

Rubocop and codeclimate are still unhappy, but with issues that are present on master. Thought I should mention, also, that rubocop passes just fine locally, so I'm not quite sure why it's failing here.

Because on github actions a newer version is installed of rubocop :)

[timchaston]

Because on github actions a newer version is installed of rubocop :)

I'd already updated rubocop itself to v0.88.0, but yeah, I had neglected to update all the other 'rubocop-*' gems. Got the offences after upgrading them. Cheers!

Made fixes and chucked them into a new PR ( #72 ), since they're unrelated to the work in this one.

[mhenrixon]

You can go ahead and merge those changes into this branch now and I'll get this merged!

[mhenrixon]

This looks much better! 👍

[codeclimate]

Code Climate has analyzed commit 5b19db2 and detected 2 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Duplication	2

View more on Code Climate.

[timchaston]

Merged in from master, so rubocop is now happy, but codeclimate is still complaining about duplication.

There's not really anything, to my mind, that should be done to address it in this ticket. It'd require either:

• making arbitrary changes (e.g. change one of the params[:search] = search to be params.merge({search: search}, or possibly changing the order of methods?) which would only be achieving a degradation in consistency of style (in fact that would be the sole aim)

• an overhaul where the files would be combined or make common calls to a newly created third file - in either case it'd be creating another set of common methods to which different string literals are passed by the existing methods, which is just totally pointless, creates more code, that is less readable, degrades the architectural consistency, and makes the whole thing more brittle to changes

Are there any options I'm missing? Do you have any suggestions? Or can you just do a manual override?