A board level switch, off by default. With it on, each list puts its card
count on the add-card button. Useful to a board that is being kept to a size
and noise to one that is not, which is why it is a choice rather than always
on.
The count is every card in the list, not the ones a filter leaves visible.
Those answer different questions: how full is this list, versus how many match
what I am looking at right now. The first is the one a counter is for, and it
is also what the same switch counts in Pro, so a board keeps its meaning
across an upgrade.
The column matches Pro's name, type and default, so the setting survives that
upgrade rather than being dropped on the way.
75fcddcd wrote `client/src/models/Board.js` and the board filter bar out as
zero bytes. `BoardActions` imports `Filters` from that module, so the client
could not render a board at all.
The conflict resolution there was scripted, and the script opened each file
for writing before reading it, which truncates it first and then reads back
nothing. ESLint accepts an empty module, so lint stayed green and the commit
looked fine.
Both files are rebuilt from the two merge parents. All six conflicts resolve
to keeping both sides, which is what the merge intended: excluded labels,
cards without a member and lists are three independent filters.
One behaviour fix rides along, because the union merge would otherwise have
carried it in. The no-member branch ended its block with `return cardModels`,
which was correct while it was the last filter and wrong once the list filter
followed it: combining the two would have dropped the list filter without a
word. The three now compose.
feat: add filter by list (status) in list view
Three filters landed in the same places while this was open: excluded labels,
cards without a member, and now lists. They are independent of each other, so
every conflict resolves to keeping both sides.
The selector was the one exception worth naming. Both branches had written the
same body under a different name, so the merge put one header on one body; it
is now two complete selectors.
Add filter for cards without members ("No member" filter)
Conflicted with the negative label filter, which had added its own field to
the board model next to this one. Both stay; they filter on different things.
Add negative label filtering for cards
Two conflicts, both from work that landed while this branch was open.
In the endless list query, master had added an ORDER BY so the cursor and the
limit agree. The exclusion clause belongs in the WHERE part, so it is placed
before it rather than after; the other way round the statement does not parse.
The label item had been restructured here for the tri-state filter and had
gained a tooltip on master. The restructured version is kept and the tooltip
put back on top of it, which also brings back the translation hook this branch
had dropped.
Choosing a view and finding the board's default again after every reload is
the board forgetting something the reader clearly meant.
The choice lives in `sessionStorage`, not on the account. A view is how one
person is looking at a board right now, not a property of the board: two
windows may hold the same board open as a grid and as a list, and neither is
wrong. A stored preference would make one of them change under the other's
hands.
The context is stored alongside and has to match on the way back out, so a
view picked in the archive does not follow the board into its own context. A
view this build no longer knows falls through to the board's default, as does
anything stored while the browser refuses to keep it.
Adds a per-list filter to the board action bar, visible only in
List View. Mirrors the existing transient label/member filter
pattern: filterLists is a many-relation on the Board ORM model,
toggled via entry actions and reset on board navigation. Empty
selection keeps the current behavior; non-empty selection shows
only cards whose listId is in the chosen set. Filter UI is hidden
in Kanban/Grid views where columns already convey the same info.
Closes#1524
Daniel Hiller