-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create semantic interface for Tickets #26
Comments
There is a rudimentary interface for Tickets (SoftLayer::Ticket class). |
I personally only have very basic needs for this one at the moment.
|
OK. With the current objects you can:
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 -- 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 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. |
Requirement to create sys admin tickets has moved to issue #42 |
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 |
Possibly abstract the various high level ticket types together, too.
The text was updated successfully, but these errors were encountered: