UI: Add timetable type filter to Dag list#69728
Conversation
boring-cyborg
Bot
added
area:API
6218138 to
4841870
Compare
potiuk
added
the
ready for maintainer review
| FilterParam[list[str] | None], | ||
| Depends(filter_param_factory(DagModel.timetable_type, list[str], FilterOptionEnum.IN)), |
There was a problem hiding this comment.
This is an exact match. To make this a more useful feature I think we need to follow how tags work and create an endpoint to query all timetables that exist amongst all the dags to give a typeahead dropdown UX
There was a problem hiding this comment.
A new search bar only for tags? Is this what we are expecting from this UI?
I feel the UI is looking a little cluttered with multiple search bars for each different category.
@pierrejeambrun fyi
Hello! I will update the PR by tomorrow morning. Working on it today |
f1.movHere is an example of how it will look like. If you agree with the design, I will move ahead with the implementation. I have fixed the favorites to the right as we resize the window so they dont move around on smaller screens |
Users could filter by timetable type through the public API, but the Dag list uses the private UI endpoint. This makes the same capability available from the page users actually use.
Keeping these text inputs on one implementation prevents their debounce, clearing, and URL synchronization behavior from drifting.
Dags can use built-in or plugin timetables whose persisted type names are not discoverable from free text alone. Exposing readable values lets users narrow large Dag lists without knowing the exact class path.
3a2493c to
c5dacaf
Compare
4 participants
Adds timetable type filtering to the Dag list UI.
The public API already supports filtering Dags by
timetable_type, but the Dag list page uses the private/ui/dagsendpoint. This wires the same filter through the private endpoint, generated UI client, and Dag list filters.The timetable filter uses a discoverable, server-backed typeahead and supports selecting multiple timetable types with OR semantics. The timetable and tag controls use a small shared filter-select component so their chips, clearing, option handling, and styling stay consistent. Other compatible filters can migrate to this shared component incrementally, giving filter controls consistent behavior across Airflow UI pages without broadening this PR into an unrelated UI rewrite.
closes: #53738
Testing:
Was generative AI tooling used to co-author this PR?
Generated-by: OpenAI Codex following the guidelines