(Some) API calling functions don't properly parse Python boolean values as parameters

[BryanBaird]

Current behavior

When calling a list() function or similar, the API often accepts a boolean parameter for filtering results. For example, the \REPORTS\ GET endpoint allows a boolean filter for archived status.

When the results are returned with the Python client, these fields are properly cast as Python boolean values. But when trying to pass in the parameter to the query, the client requires the value to be passed as a string instead.

Example

This fails:

import civis
client = civis.APIClient()
client.reports.list(limit=10, archived = False)

CivisAPIError: (400) Invalid archived status 'False'.

But this succeeds:

import civis
client = civis.APIClient()
client.reports.list(limit=10, archived = "false")

Expected behavior

Use the native data type(s) for the language, and parse those into whatever structure is needed for the url path on the API call.

[jacksonlee-civis]

@BryanBaird Thank you for filing this issue! I agree that the archived parameter in question should ideally take a boolean value not a string. The root problem comes from the upstream Civis API, where this parameter is specified as a string and then the downstream Python and R clients would error if you provide a boolean not a string. If anything needs to be updated or fixed, it would be the upstream Civis API but not the civis-python or civis-r codebases. Let me bring to this issue to the maintainers of the Civis API and see what they think. Fixing this archived parameter from string to boolean might be considered breaking existing code that specifies this param, but I have no clue how big of a problem this breaking change would be.

[jacksonlee-civis]

Update -- Civis-internal folks are indeed concerned with the potentially widespread breaking change for archived, since this parameter is used under many Civis API endpoints. I've opened an internal ticket for switching archived from a string to a boolean at the upstream Civis API, but it's unlikely to be prioritized anytime soon. For now, users still have to specify the less ideal archived="false" (as a string), which you've shown. I'm going to leave this ticket open so long as the issue still prevails at Civis API backend.