/tickets resource

[willmurphyscode]

Here's our outline from the API:

Tentative API:

GET /ticketing/tickets/

returns a bag of ticket-related information as a giant array

[
  {
    "id": 432,
    "topicOrMessage": "topic"
  }
]

(for additional fields, see the individual routes so that we don't duplicate this all over the place)

GET /ticketing/tickets/:topicOrMessage/:id

returns a bag of ticket-related information derived from ticket tags:

{
  "id": 432,
  "topicOrMessage": "topic",
  "priority": "immediate",
  "status": "waiting",
  "reasons": ["onboarding", "helpdesk"],
  "otherTags": ["location-america", "language-english"],
}

[bhaibel]

updates to tentative API based on dashboard frontend needs:

GET /ticketing/tickets/

parameters:
order: "priority", "status", "dateCreated", "dateDue"
ascending: boolean
page: integer
query: "status:complete" or the like -- used for filtering, github-style

[
  {
    ....generic-ticket-fields (see GET /ticketing/tickets/:topicOrPost/:id)
  }
]

GET /ticketing/tickets/:id
(where :id is any string other than 'topic' or 'post')
da
404

GET /ticketing/tickets/:topicOrPost

404

GET /ticketing/tickets/:topicOrPost/:id
(:topicOrPost is a string that is either 'topic' or 'post')

{
  "ticket": {
    "id": 3424,
    "topicOrPost": 'post',
    "priority": 'high',
    "status": 'waiting',
    "dateCreated": [datestamp],
    "dateDue": [datestamp],
    "involvedUsers": {
      ... generic serialized fields stolen from normal discourse serializer
    }
    "href": 'https://example.com/ticketing/tickets/post/3424'
  }
}

PATCH /ticketing/tickets/:topicOrPost/:id

send same JSON blob as for the parallel GET request