Laver docs
Open Laver
Boards and tickets

Search the workspace#

Press ⌘KCtrl+K on Windows and Linux — anywhere in the app. One box searches every board, ticket, comment and wiki page you are allowed to open, and takes you to whichever one you pick.

It is not the board filter. The filter narrows the board in front of you and searches nothing else; this searches the whole workspace and is the way to find work on a board you are not looking at. See Filters and card display for the board's own box.

Using it#

  • Type at least three characters. Below that nothing is sent: two characters match most of a workspace and say nothing useful.
  • Results arrive as you type, a moment behind the keystroke.
  • and walk the list, opens the highlighted result, Esc closes the palette. A click does the same as . While the palette is open it keeps every key to itself, so nothing you type reaches the board underneath.
  • Opening a result takes you to it: a board opens the board, a ticket or a comment opens that ticket on its board, a page opens it in the wiki.

What it searches#

Four kinds of thing, in this order:

Kind Matched on
Boards The board's name
Tickets The ticket's title and description
Wiki pages The page's title and text
Comments What somebody wrote on a ticket

Boards come first because typing a board's name is an unusually clear thing to do, then tickets, then pages, then comments. Up to eight of each — a workspace full of tickets cannot crowd the pages out of the reply.

A ticket that matched on its own title or description is not repeated as a comment result, so nothing on the list appears twice.

Each row carries a short excerpt with the matching words marked, and a line of detail: a ticket shows its ID, board, column, priority and when it last moved; a comment shows who said it and when; a page shows its wiki.

How the words are matched#

Search matches whole words, not fragments, so otificatio finds nothing while notification finds the ticket. The word you are still typing is prefix-matched — expor already finds export.

Beyond one word it reads a query the way a search engine does:

  • deploy checklist — both words, anywhere in the ticket, in any order.
  • "deploy checklist" — that phrase.
  • deploy -staging — matching deploy, excluding staging.
  • deploy or release — either.

Anything that names one ticket finds that ticket, whether or not its words match:

  • the ID shown on the ticket dialog, with or without the # — the first eight characters of its uuid,
  • the whole uuid, from an API reply or an agent's message,
  • a ticket link, which is what Copy URL on a ticket's right-click menu puts on your clipboard.

Eight characters is the shortest thing read as an ID: shorter hexadecimal words like cafe and decade are ordinary words that people search for. A bare eight-character ID searches the text as well and returns both.

A ticket you are not allowed to open and a uuid that never existed give exactly the same empty result.

What it will not show you#

  • Anything you could not already open. Boards and tickets are scoped to the boards you have access to, and wiki pages to the pages you may read — a workspace-visible child of a private page stays hidden. Search invents no access of its own.
  • Wiki results for a guest. A guest never reads the wiki, whatever a page's visibility, so no page or wiki appears for them. See Roles and permissions.
  • Archived tickets, archived boards and archived pages, and anything in the trash.
  • Ticket bodies. The reply carries titles, excerpts and the handful of details on each row, and nothing else — the palette is a way to reach a ticket, not a way to read the workspace.

Over the API#

The same search is GET /search?workspace_uuid=...&q=..., which returns boards, tasks, pages and comments. limit sets how many of each come back, up to 20, and types — a comma-separated subset of boards,tasks,pages,comments — asks for only the kinds you want. types can only narrow a reply: every kind is scoped to what the caller may read either way.

API keys are accepted. See Driving a board over the API for searching a single board instead, and the API reference for the endpoint itself.