Subsystem

HTTP API: views

The 5 operations tagged views, each with its parameters, its body and what it answers.

The views you can see

GET /v1/views

Return the views you saved, and the ones shared with this workspace.

Enveloped with has_more always false, which the link listing settled and which is a statement rather than a shrug here for the same reason: a workspace's saved views are bounded by how many people took the trouble to write one.

Ordered by name, because a list somebody reads to pick from is read alphabetically and most recently saved is a question nobody puts to their own furniture.

Parameters

Responses

Save a view

POST /v1/views

Save a query and an arrangement under a name, so nobody has to retype it.

Parameters

Request body: CreateView as application/json, required.

Responses

One saved view

GET /v1/views/{key}

Return one view by name, whether it is yours or shared with this workspace.

Parameters

Responses

Change a saved view

PATCH /v1/views/{key}

Change a view you saved. Renaming it changes the address people have.

Only the person who saved a view may change it, however widely it is shared. Sharing publishes a view; it does not hand it over. A shared view is somebody's statement of how the team's queue is read, and a second person quietly changing what everybody's saved link draws would be a rewrite under its author's name. Copy it under your own name instead.

Parameters

Request body: UpdateView as application/json, required.

Responses

Forget a saved view

DELETE /v1/views/{key}

Remove a view you saved, or one shared with a workspace you administer.

Gone rather than trashed, unlike a task: a view holds no record of anything that happened, and a deleted one left in the table would go on holding its name against the next person who wants it.

An administrator may remove a shared view and may not change one, as with a comment: its words are its author's, and taking them out is the honest alternative to rewriting them.

Parameters

Responses