Proposal for the host to be able to filter (or sort) bookings by certain criteria in the bookings page

[MinosChatzidakis]

I have a proposal to make regarding the bookings page. I think that it would be beneficial for a host to be able to sort their bookings (upcoming or past) by certain criteria, such as event type, start time, etc. Right now they only have the option to view them in the order that they were boked, which hurts customization and organization possibilities.

Apart from that, I believe that this would also benefit team managers, since they could sort or filter bookings by additional criteria such as the team or even the team member that the booking has been assigned to. This would be excellent as it would allow team managers to view the data in a more structured manner, helping them create a better idea of the responsibilities their teams have undertaken.

Thank you for the consideration.

[shockalotti]

Thanks Minos, this is a good one and mostly a yes from me.

One small correction first. Bookings aren't ordered by when they were made. Both the "mine" and workspace queries sort by start time, and the page then splits them into Upcoming (soonest first) and Past (most recent first). There's also a Mine / All toggle for admins. So there is an ordering, just not one you get to choose.

Your actual point survives that though. There's no way to filter by event type, by host, or by status, and no search box. Once a workspace is busy, Upcoming is a long undifferentiated scroll and finding one thing means scanning for it. That's a real gap.

The mildly embarrassing part: the filters you're describing already exist. The MCP tool list_bookings accepts status, date_from, date_to, event_type_id and host_id. That vocabulary is designed, shipped, and tested. It just isn't reachable by a human being. An LLM connected to your workspace can slice your bookings six ways; you, the person who owns them, can't slice them at all. So this is less "build a new feature" and more "point an existing one at the UI", which is a much better place to be starting from.

How I want to build it, and why it isn't just dropdowns. GET /v1/bookings currently has no pagination and no limit. It loads every booking the caller can see, then runs several follow-up queries keyed on every one of those booking ids, against a database pool that is deliberately a single connection. The MCP tool has the same shape and then does its filtering in Go afterwards, so asking it for one host's bookings still pulls the whole workspace into memory first.

Adding filters purely in the browser would make the page feel faster while quietly making it heavier, and would push that problem further down the road. So the version I want to build pushes the filters down into SQL, exposes them as query parameters on the REST endpoint, and has both the admin page and the MCP tool go through that one path. Pagination lands in the same change, because filtering without a limit is still an unbounded query.

Slightly more work than dropdowns, but it fixes a scaling problem that is going to bite someone eventually, and it removes a duplicate filtering implementation rather than adding a third.

On the team dimension. Good news here: teams are already a real entity in Calnode, with members and per-member routing priority, so this is buildable now rather than blocked on future work. Filtering bookings by team resolves through team membership (a team's bookings are the bookings hosted by its members), which needs no schema changes.

One honest wrinkle worth flagging before I build it. Event types don't currently record which team they belong to. The column exists but nothing sets it. Today the event-type editor treats a team as a convenient way to bulk-add its members as hosts, and from that point on the association is to the people, not to the team. That works fine for your stated goal of seeing what a team has taken on, but it means someone who belongs to two teams will have their bookings show up under both. If that ambiguity turns out to matter in practice, the fix is to record the team on the event type properly, which is a separate and slightly larger piece of work.

So: event type, host, status and date range, server-side, with pagination, and team filtering via membership with that caveat understood. Thanks for pushing on this.

[MinosChatzidakis]

I am glad you agree with my proposition, and that the solution seems to be already half-implemented in the form of an MCP tool. I also understand that the path you are planning on following will rule out potential performance issues, which I agree is the right call.

Thanks for implementing this and for listening to feedback.

[shockalotti]

Tracking issue opened: #18. It covers the SQL-side filters, pagination, pointing both the admin page and the MCP tool at one path, and the team-membership caveat noted above.