Filters

A filter shows only some of a view’s tasks. It saves the instant a rule has an answer, like everything else here.

A rule you add is yours: it narrows your screen and nobody else’s. A view may also carry rules of its own, which everybody sees. See Yours and the view’s.

Three decisions make Ushabti’s filters behave differently from the ones you are used to. They are worth reading before the mechanics.

1. Every rule has to pass

A filter narrows. There is no “any of these rules”, and no way to build one. Two rules means both.

Within a single rule the values are an “or”: Status is Doing, Ready is one rule, and it passes for either. That is where the “or” lives, and it is the only place it lives.

2. “is not” keeps the tasks that hold nothing

A task with no priority is not High. So Priority is not High shows it.

3. “Nothing yet” is a value, not an operator

At the end of every value list sits an entry meaning this task holds nothing here. It is a value in the set, so Doing, or nothing yet is one rule rather than two rules that could never both pass.

It wears the same words the columns use: Unassigned for a person property, No priority for everything else. A checkbox never gets one — off is a value, not emptiness.

4. “Me” is whoever is reading

At the top of a person property’s value list sits Me. It is not your name: it is a value that means the person looking at the board. Put Assignee is Me on a view with Save for everyone, and the one view shows each person their own tasks. Nobody builds a “My tasks” filter by hand, and nobody’s name is saved in the rule.

Me sits beside the other values like any of them, so Me, or Unassigned is one rule. An agent reads Me as itself.

The operators

Property type	Operators, in menu order (the first is the default)
select · multi-select · person	`is` · `is not`
checkbox	`is`
text	`contains` · `does not contain` · `is empty` · `is not empty`
link	`contains` · `does not contain` · `is empty` · `is not empty` — `contains` matches any link of the list
number	`is` · `is over` · `is under` · `is empty` · `is not empty`
date	`is on` · `is before` · `is after` · `is within` · `is empty` · `is not empty`

Text compares case-insensitively. A number rule needs the value to really be a number. Dates compare as YYYY-MM-DD strings — no Date object, no timezone, so the server and your browser always agree.

A date rule that stays true tomorrow

is within names a window of days rather than one day, so due this week does not have to be rewritten every week. Pick it among the operator chips and the date box becomes a third row of words:

The word	What it covers
Today · Tomorrow	that one day
This week · Next week	Monday to Sunday, always, wherever you are
The last 7 days · The last 30 days	the days ending today, today included
The next 7 days · The next 30 days	the days starting today, today included
Overdue	every day before today, and nothing else

The chip says it the way you would: Due this week, Due in the next 7 days, and Overdue on its own, because saying Due is overdue says it twice.

Which “today”?

The project’s. A filter is shared, so “this week” has to be one week for the whole team: a day taken from each reader’s browser would show two people in two zones different cards through one view, and an agent has no browser at all. The owner sets the zone in Settings → Project; it is UTC until they do.

The server works the day out when it reads the board and sends it with the answer, so your browser never reads its own clock. A board left open over midnight keeps yesterday’s day until something makes it read the board again.

A rule is stored as the word — this_week — and read afresh like every other rule, so a word this version does not know is thrown away rather than left hiding cards.

“Blocked” is a rule and not a property

Two words in the property list are not properties: Blocked and Agent waiting. Blocked asks whether the task is waiting on another one, and it reads as a checkbox — Blocked or Not blocked, one rule, one answer.

There is no property behind it and nobody has to add one. A blocked-by link is not a field on a task, so the board has one fixed word for it, the way a card has one fixed row for its key. Nothing writes it: a task added to a board filtered to Blocked is written with no link and no value for it — one of the two rules the composer cannot fill in.

Because the word cannot be deleted, a rule about it is never thrown away. See Blocked by for what makes a task blocked, and for what makes it stop.

“Agent waiting” finds who waits for you

The second fixed word is Agent waiting. It keeps the tasks where an agent asked a person something and stopped until somebody answers: its open run is waiting. It reads as a checkbox too — Agent waiting or No agent waiting.

A hand-over does not count. That run gave the task to somebody else and asks nobody anything, so the filter would only add noise to the one question it answers: where does an agent wait for me. Answer in a comment. The agent wakes, goes back to work, and the card leaves the filter on its own.

You do not need the filter to see that a question waits. N waiting in the top bar counts the same tasks on every view, whatever filter is on, and lists them.

Like Blocked, it is no property and nothing writes it, so a task added under it is written without it. See Runs for how an agent asks.

Using it

The Filter pill sits at the right of the view strip, showing the rule count when there is one. The panel asks two questions in one place that does not move:

Which property? A list of every property, each with its colour dot, and — where a rule already exists — that rule’s summary on the right. Arrow keys move the highlight, Enter picks.
The answer. A back button, then a box whose placeholder fits the type: Which value?, Who?, What words?, What number?, Which date?. Under it the operator chips (only when there is more than one to choose), and for is / is not a tick list of values you can type to filter. Enter toggles the highlighted value and the list stays open, because a rule usually names more than one.

Picking a property that already has a rule of yours reopens that rule rather than making a second one. Date rules are the exception within one set: after March and before June are two rules on purpose, and so are Overdue and Due is before 2026-12-01. Across the two sets there is no exception — if the view already dates a property, you cannot add a date rule of your own about it. See Yours and the view’s.

Picking a property asks a question; it never answers one

Until a rule has an answer, nothing is written: not to the view, not to the other people looking at it, and no chip is drawn. A set rule needs at least one value; a text, number or date rule needs something in the box; is empty and is not empty count as their own answer.

Taking the last answer back deletes the rule. An operator may come with a default — that is the shape of the question, not the answer to it.

The chips

A row under the view strip, one button per rule:

Due is empty
Unassigned — a value that speaks for itself needs no operator
Priority is High, Urgent
Labels is bug, feature +2 — more than two collapses
Estimate is over 3 · Due is before 2026-09-01 · Title contains login
Due this week · Overdue — a window of days, counted from the project’s today

Click a chip to reopen that rule; its ✕ removes it. Clear at the end of the row removes the ones you added.

Yours and the view’s

The board shows the view’s rules, plus yours. Nothing else: there is no “mine differs from the view’s” state and no Reset.

A rule you add through the Filter pill is yours. It is saved against you and that view, so it survives a reload and follows you to another browser — and nobody else’s board moves.

The row reads left to right in the order the rules are applied:

[Labels is bug ✕] │ [Assignee is Jack ✕] Clear · Only you see this — Save for everyone

Left of the divider: the view’s rules, which everybody sees.
Right of it: yours. ✕ takes one away; Clear takes them all away and never touches the view’s.
An order you picked from Sort or a list heading sits on the same row, as the first of yours. Clear takes it away with your rules.
Save for everyone copies your rules and your order onto the view, for everybody, and empties yours. Any member may press it, and the other people’s boards narrow within a second.
✕ on one of the view’s chips asks first, in the chip itself: Remove for everyone? Remove. Escape or a click elsewhere puts the chip back.
Click one of the view’s chips to change its rule, and the panel opens with Changes this for everyone above the question. It is a line, not a question: the change still saves at once. A chip of yours says nothing extra, because nobody else sees it.

One property carries one rule, whoever asked: if the view already filters Priority, the panel says so where you pick it — The view already filters Priority. Remove it for everyone first — and writes nothing, because two rules about one property can contradict each other and empty the board. That counts dates too, which is what it costs: a view dated before June takes no after March of yours, so use the view’s ✕, or another view.

The Filter pill counts every rule hiding cards on your screen, whoever added it.

On a phone the row scrolls sideways rather than wrapping, and the tail shortens to Only you · Save for all.

When a filter names the grouping property

The columns that rule excludes disappear — they are not drawn empty.

Nothing is lost by that: a task in one of those columns failed the same rule, so it is off the board either way. What you gain is the absence of a trap. An empty column you could still drop a card into would take the card and hide it in the same movement, with nothing on screen to say why.

Two things follow:

A column cannot be dragged while such a filter is on. A drop can only name the column it landed after, and the option order belongs to the property everybody shares.
A new column joins the rule, because nobody makes a column in order not to see it.

Adding a task under a filter

A card written and hidden in the same breath, with nothing on screen to explain it, is the worst thing a filter can do. So the composer fills in what the filter asks for.

It only answers a rule it can answer without guessing: the operator is is, there is exactly one value, that value is not “nothing yet”, and the property is not the grouping property — the column decides that one. Everything else is left alone. Under Assignee is Me that value is you, so a task you add under a shared “My tasks” view is yours.

And it says so first. The composer’s hint reads:

Enter to add · sets Priority Urgent, Labels bug

A rule pointing at something you deleted

Nothing rewrites a view when a property or an option it names is deleted. There is no cleanup pass, on purpose: it would have to run in four different delete transactions and would still lose a race.

Instead the rules are read afresh every time, and anything that no longer makes sense is thrown away on the spot — a rule whose property is gone, an operator that is not allowed for that type, a value that is no longer a live option. A rule left with no answer goes with it.

That reading happens in two places that have to agree: on the server when a board is read, and again on every write. So the chips you see and the cards that are hidden always come from the same reading, and both sets of rules — the view’s and yours — go through it. A rule nobody can see must never keep hiding cards.

Who may set one

Any person in the project, for their own screen and for the view alike. An agent may not human only — a token that could write filters could hide work from the people. An agent has no rules of its own either: it reads the view’s filters and never anybody’s personal ones.

SearchThe box in the top bar: a key, a title, a word in a description — and the hits your view is hiding.