Skip to content
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

Closed
cbreden opened this issue Jun 11, 2014 · 10 comments
Closed

Create semantic interface for Tickets #26

cbreden opened this issue Jun 11, 2014 · 10 comments

Comments

@cbreden
Copy link

cbreden commented Jun 11, 2014

Possibly abstract the various high level ticket types together, too.

@SLsthompson
Copy link
Collaborator

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
Copy link
Author

cbreden commented Jun 12, 2014

I personally only have very basic needs for this one at the moment.

  • Create standard ticket
  • Create administrative ticket
  • Get Tickets
  • Get Open Tickets (merging these two with the new XML query features might be good)
  • Get Ticket Subjects (ids and subject names of the SL constants. array of arrays? array of hashes? relates to Create semantic interface for Constants #30)

@SLsthompson
Copy link
Collaborator

OK. With the current objects you can:

  • 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.

@cbreden
Copy link
Author

cbreden commented 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_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.

@SLsthompson
Copy link
Collaborator

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.

@SLsthompson
Copy link
Collaborator

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
Copy link
Author

cbreden commented 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
Copy link
Collaborator

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
Copy link
Collaborator

Requirement to create sys admin tickets has moved to issue #42

@SLsthompson
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants