EaserixDocs
DevelopersAPI referenceTasksIssues

Grouped issue counts

Totals for the issues the caller can see, grouped, honouring every filter listIssues honours because it shares the same query builder. A count walking a different predicate than the list beside it would put two numbers on screen that disagree, with neither looking wrong alone. Exists because a paged list cannot answer "how many". Group headers, board columns and the progress bars on the cycles and projects pages each need a real total per group, and one grouped query serves a whole screen where per-group requests would take one per column. Each group carries `total` and `done` - both, because a progress bar needs two numbers and fetching them separately would double the requests per bar. `done` counts issues whose state is of the `completed` type. `key` is always a string, including for priority, which groups on an integer column. A null key is a real group: unassigned, no project, or no cycle. Groups holding no issues are ABSENT rather than zero - the caller knows its own states, projects and cycles and can render those as zero, which the server cannot do for assignees.

View as Markdown
GET
/v1/issues/counts

Authorization

bearer
AuthorizationBearer <token>

In: header

Query Parameters

team_id?string

Restrict to one team.

Formatuuid
group_by*string

Value in

  • "state"
  • "priority"
  • "assignee"
  • "project"
  • "cycle"
blocked?boolean

Same flag as listIssues. Counts only issues with an open blocker, so a column total cannot disagree with the cards under it.

scope?string

Same as listIssues, together with q. With scope=all the counts are of CANDIDATES: issues whose stored text contains every word, which can include a few that listIssues later drops because they matched only markdown syntax. Use them as facets beside a results list, not as its exact length.

Default"title"

Value in

  • "title"
  • "all"

Response Body

application/json

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/v1/issues/counts?group_by=state"
{  "groups": [    {      "key": "string",      "total": 0,      "done": 0    }  ],  "total": 0,  "done": 0}

Create an issue

The issue number is per-team incrementing (max(number)+1, computed in a transaction) and position starts equal to the number. State resolution: an explicit stateId must belong to the target team (else 400 "stateId does not belong to that team"); omitted, the team's lowest-position state is used; a team with no states at all is 400 ("no workflow state available; create a state first"). priority defaults to 0 (0 none, 1 urgent, 2 high, 3 medium, 4 low); estimate 0 means "no estimate" and is stored as null. assigneeId must be an org member; projectId/cycleId/parentId must reference rows inside the caller's org (else 400 "invalid …Id"). Records a "created" activity and notifies the assignee (import-mode creates do not notify). The creator and the assignee are seeded as followers of the issue, on imported creates too: seeding notifies nobody, it only decides who hears about later activity. A description containing @[Name](mention:memberId) tokens is processed the same as on a comment (see POST /v1/issues/{id}/comments) — each resolvable mention notifies and follows, even though the description arrived at creation rather than through a later edit.

Get an issue

The issue with state, assignee, and labels embedded.