facetoe / zenpy

Python wrapper for the Zendesk API
GNU General Public License v3.0
347 stars 162 forks source link

tickets.audits with include='users' returns only users #513

Open feimosi opened 2 years ago

feimosi commented 2 years ago

I've been trying to fetch ticket audits with preloaded users but it only returns User objects instead of Audit. I call it like this:

audits = zenpy_client.tickets.audits(ticket, include='users')

In this case audits is a list of users. I don't see a way to access the audits. I enabled full zenpy logging and can see that the correct request is sent: "GET /api/v2/tickets/7226860/audits.json?include=users HTTP/1.1" 200 None The json response also is correct. Then it goes through GenericZendeskResponseHandler and somehow the audits get lost. User objects are also put into the cache as expected.

Any help would be appreciated!

StarParks commented 4 days ago

Issue might be in the for loop at line 163 of response.py, inside the build function:

        # Maybe a collection of known objects?
        for zenpy_object_name in self.object_mapping.class_mapping:
            plural_zenpy_object_name = as_plural(zenpy_object_name)
            if plural_zenpy_object_name in zenpy_objects:
                meta = response_json.get('meta')
                if meta and meta.get('has_more') is not None:
                    return GenericCursorResultsGenerator(
                        self,
                        response_json,
                        object_type=zenpy_object_name
                    )
                else:
                    return ZendeskResultGenerator(
                        self,
                        response_json,
                        object_type=plural_zenpy_object_name
                    )

It expects to only have to return a single Generator, and it ends up returning whatever it finds first ("users").

The Generators may only handle one type at a time. Maybe the build function could return a dict with multiple generators? However, this would certainly introduce a breaking change.

Bug might also be related to the meta['has_more'] in the response_json, as it is False when it should (maybe?) be True.

I can propose a PR if further guidance is given on how this should be handled.