Support include kwarg in the Endpoint.all() Method

[jeffkala]

Today if you want to pull back all devices and include config_context data you must use the .filter call.

In the .all() call if you include the include kwarg it will fail

>>> nautobot.dcim.devices.all(include=['config_context'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Endpoint.all() got an unexpected keyword argument 'include'
>>> 

Workaround is to use .filter(include=["config_context"]) with no other filtering criteria.

>>> nautobot.dcim.devices.filter(include=['config_context'])
[<pynautobot.models.dcim.Devices ('demo-cisco-xe') at 0x7f5c64d07b90>, <pynautobot.models.dcim.Devices ('jeff-8000v') at 0x7f5c64d1f410>, <pynautobot.models.dcim.Devices ('nxos9k') at 0x7f5c64d25210>, <pynautobot.models.dcim.Devices ('veos') at 0x7f5c64d26dd0>]

[tsm1th]

How do we determine what is a filter vs. what is a "helper" such as include? I briefly started looking into this and quickly realized that I was converting the all() method to be the same as filter(). If we pass all the kwargs, then it's essentially a replica of filter(). If we limit it to things like include, then how do we keep track of those special kwargs?

[joewesch]

We discussed this internally, and we came to the conclusion that we don't believe .all() and .filter() need to be bespoke methods any longer. Both methods call the same endpoint, but one has a distinct list of query params allowed and the other allows any params. As the Nautobot API evolves, where do we draw the line on what kwargs we allow in .all()?

We think the best route is to convert .all() to just call .filter() behind the scenes and pass along any kwargs. We will continue to accept .all() for backwards compatibility, but functionally they would be the same.