More API goodness

[ezrast]

I'm not sure if there's documentation on this, but best I can tell by source-diving we can only retrieve tickets by ticket ID or by client using the API. Or we can request ALL the tickets (except IIRC it isn't actually all the tickets, only non-deleted ones in the primary queue).

At the moment filtering the giant list client-side is good enough for my purposes, but that's going to get unwieldy fast once we have more than a few thousand tickets. I'd like to be able to search at least by assignee and type (open, on hold, closed). I'd really like to have the full functionality of Ubersmith's support.ticket_list function, but realistically assignee, type, and maybe latest activity timestamp are probably sufficient.

[johann8384]

API features are currently driven by what was needed for the ui.

This shouldn't be too hard to implement.

On Mar 1, 2014, at 6:44 AM, ezrast [email protected] wrote:

I'm not sure if there's documentation on this, but best I can tell by source-diving we can only retrieve tickets by ticket ID or by client using the API. Or we can request ALL the tickets (except IIRC it isn't actually all the tickets, only non-deleted ones in the primary queue).

At the moment filtering the giant list client-side is good enough for my purposes, but that's going to get unwieldy fast once we have more than a few thousand tickets. I'd like to be able to search at least by assignee and type (open, on hold, closed). I'd really like to have the full functionality of Ubersmith's support.ticket_list function, but realistically assignee, type, and maybe latest activity timestamp are probably sufficient.

—
Reply to this email directly or view it on GitHub.

[ezrast]

The information returned by the API also isn't formatted consistently for the different calls. For example, ticket information from /ubersmith/tickets has human-readable values for the keys 'timestamp', 'type', 'activity_type', etc, while /ubersmith/tickets/ticketid/x has those keys mapped to UNIX timestamps and internal numeric type IDs (with keys like 'type_name' and 'activity_type_name' mapped to human-readable forms). Some consistency (preferably in the form of the latter behavior) would be nice.

(though not without a heads-up if this gets changed in place, since it will obviously break everything I currently have written)

[johann8384]

Will address in Issue 64.

#64

On Mar 16, 2014, at 4:56 AM, ezrast [email protected] wrote:

The information returned by the API also isn't formatted consistently for the different calls. For example, ticket information from /ubersmith/tickets has human-readable values for the keys 'timestamp', 'type', 'activity_type', etc, while /ubersmith/tickets/ticketid/x has those keys mapped to UNIX timestamps and internal numeric type IDs (with keys like 'type_name' and 'activity_type_name' mapped to human-readable forms). Some consistency (preferably in the form of the latter behavior) would be nice.

(though not without a heads-up if this gets changed in place, since it will obviously break everything I currently have written)

—
Reply to this email directly or view it on GitHub.