You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a rudimentary interface for Tickets (SoftLayer::Ticket class).
It would be easy to flesh it out if you can offer some ideas of what you would like to do with Tickets
Create standard ticket (SoftLayer::Ticket.create_ticket)
Get Tickets (by id is what you meant? SoftLayer::Ticket.ticket_with_id)
Get Open Tickets (could be implemented better SoftLayer::Account#tickets includes the open tickets)
Get Ticket Subjects (SoftLayer::Ticket.ticket_subjects)
That leaves Create administrative ticket and some kind of cleanup to open tickets that will allow you to use object filters.
I'm also not trying to claim that the implementation that is there is really great. I haven't gone over it with a fine tooth comb, but if you need something quick and dirty, it should be a good start.
I thought I typed a reply to this! (where did it go...?)
Anyway, good catch, I should have been more clear -- ticket_with_id is good. But a get_tickets could maybe default to a full fetch of all tickets and offer a few filter methods that take advantage of the new XML-RPC query interface. The get_open_tickets could just be a wrapped call with the right filter parameter then (with the option to refine it further).
The datatype returned by ticket_subjects is plenty useable.
I don't think you want to do a full fetch of all tickets by default. Over time accounts can accumulate a very LARGE number of tickets and returning all of them (or searching through all of them repeatedly) would probably yield poor performance.
Routines like SoftLayer_Account::getOpenTickets are tuned on the server side to retrieve their results quickly. They are designed to satisfy the most common use-cases.
There should be a way for a developer to say 'give me ALL my tickets' if they really want to, and we should ensure there is way to do criteria-based ticket searches, but I think 'give me all my tickets' would be the wrong choice for default behavior.
That raises a thought. I wonder if there is some way either leverage ActiveRecord directly, or mimic its querying features to help make Object Filters approachable.
True. Something that pages would be preferable. I haven't looked at the XML-RPC stuff yet, but I understand it has something to that effect?
But that said, I haven't run into a situation with too many tickets, but it makes sense that would be way too much for accounts with large numbers of tickets. Maybe that call should be paged by default.
Paging is usually handled through the "result_limit" mechanism. You'll make one call that returns the count of things that you want to page through then call with a result limit for each page.
Result limits were added in one of the versions of 1.0.X. In 2.0 they were changed so that you make a single call for the starting point and length rather than having two separate calls.
Activity
SLsthompson commentedon Jun 12, 2014
There is a rudimentary interface for Tickets (SoftLayer::Ticket class).
It would be easy to flesh it out if you can offer some ideas of what you would like to do with Tickets
cbreden commentedon Jun 12, 2014
I personally only have very basic needs for this one at the moment.
SLsthompson commentedon Jun 13, 2014
OK. With the current objects you can:
SoftLayer::Ticket.create_ticket)SoftLayer::Ticket.ticket_with_id)SoftLayer::Account#ticketsincludes the open tickets)SoftLayer::Ticket.ticket_subjects)That leaves Create administrative ticket and some kind of cleanup to open tickets that will allow you to use object filters.
I'm also not trying to claim that the implementation that is there is really great. I haven't gone over it with a fine tooth comb, but if you need something quick and dirty, it should be a good start.
cbreden commentedon Jun 16, 2014
I thought I typed a reply to this! (where did it go...?)
Anyway, good catch, I should have been more clear --
ticket_with_idis good. But aget_ticketscould maybe default to a full fetch of all tickets and offer a few filter methods that take advantage of the new XML-RPC query interface. Theget_open_ticketscould just be a wrapped call with the right filter parameter then (with the option to refine it further).The datatype returned by ticket_subjects is plenty useable.
SLsthompson commentedon Jun 17, 2014
I don't think you want to do a full fetch of all tickets by default. Over time accounts can accumulate a very LARGE number of tickets and returning all of them (or searching through all of them repeatedly) would probably yield poor performance.
Routines like
SoftLayer_Account::getOpenTicketsare tuned on the server side to retrieve their results quickly. They are designed to satisfy the most common use-cases.There should be a way for a developer to say 'give me ALL my tickets' if they really want to, and we should ensure there is way to do criteria-based ticket searches, but I think 'give me all my tickets' would be the wrong choice for default behavior.
SLsthompson commentedon Jun 17, 2014
That raises a thought. I wonder if there is some way either leverage ActiveRecord directly, or mimic its querying features to help make Object Filters approachable.
cbreden commentedon Jun 17, 2014
True. Something that pages would be preferable. I haven't looked at the XML-RPC stuff yet, but I understand it has something to that effect?
But that said, I haven't run into a situation with too many tickets, but it makes sense that would be way too much for accounts with large numbers of tickets. Maybe that call should be paged by default.
SLsthompson commentedon Jun 17, 2014
Paging is usually handled through the "result_limit" mechanism. You'll make one call that returns the count of things that you want to page through then call with a result limit for each page.
Result limits were added in one of the versions of 1.0.X. In 2.0 they were changed so that you make a single call for the starting point and length rather than having two separate calls.
SLsthompson commentedon Jul 21, 2014
Requirement to create sys admin tickets has moved to issue #42
SLsthompson commentedon Jul 21, 2014
Requirement to find tickets using filters and/or elastic search is now documented in issue #43
I believe this addresses all the lingering issues here so I'm going to close this über issue in favor of the more focused issues