Skip to content

Extend user settings with additional configuration - #71699

Merged
bbovenzi merged 24 commits into
apache:mainfrom
dsuhinin:dsuhinin/ui-default-settings
Aug 31, 2026
Merged

bbovenzi merged 24 commits into
apache:mainfrom
dsuhinin:dsuhinin/ui-default-settings

Conversation

@dsuhinin

@dsuhinin dsuhinin commented Aug 17, 2026 •

Copy link
Copy Markdown
Contributor

Right now every task instance opens on the Logs tab, and the app always lands on the Home dashboard. If you prefer something else, you're clicking your way there every single time. This adds two small, opt-in preferences on the Settings page so each user can pick better defaults — and if you don't touch them, nothing changes.

Both preferences are per-user and stored in this browser's localStorage (via useUserSettings); there is no server-side profile and no deployment-level config involved.

Default landing page (default_landing_page, defaults to dashboard) sets what the root URL opens. Switch it to dags and / takes you straight to the Dag list. The dashboard is still there — it now lives at /home, so you don't lose anything. A tiny LandingPage component at the root index route just reads the stored value and either renders the dashboard or redirects to /dags — all client-side, no server-side routing.

Default task instance tab (default_task_instance_tab, defaults to logs) sets which tab a task instance opens on (say, details). The task-instance index route renders a DefaultTab component that reads the stored value and redirects there, keeping the query string and hash intact. Logs now also has its own explicit logs route, and any unknown or unset value falls back to Logs — so existing behavior and deep links stay exactly as they are. And if you're clicking task-to-task in the grid, your explicit tab choice still wins (the current sub-route is preserved)

Screenshot 2026-08-18 at 09 05 15 Screenshot 2026-08-18 at 09 05 33

@uranusjr

Copy link
Copy Markdown
Member

I would suggest dropping the Russian translation files. Most reviewers we have don’t read Russian, so bundling those changes in the same PR will significantly drag out the review process until we can find someone to review those parts. It would be better if this only touches the actual UI changes (and the en file, which is needed), and submit the translation changes in a later PR.

@dsuhinin

Copy link
Copy Markdown
Contributor Author

I would suggest dropping the Russian translation files. Most reviewers we have don’t read Russian, so bundling those changes in the same PR will significantly drag out the review process until we can find someone to review those parts. It would be better if this only touches the actual UI changes (and the en file, which is needed), and submit the translation changes in a later PR.

sure, removed it already.

@dsuhinin

Copy link
Copy Markdown
Contributor Author

@uranusjr @bbovenzi do you think guys that we can somehow try to move forward here?

@dsuhinin

dsuhinin commented Aug 31, 2026 •

Copy link
Copy Markdown
Contributor Author

@uranusjr @bbovenzi @choo121600 can you please take a look?

@bbovenzi bbovenzi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the back and forth!

@dsuhinin

Copy link
Copy Markdown
Contributor Author

Thanks for all the back and forth!

no problem at all! thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:translations area:UI Related to UI/UX. For Frontend Developers. translation:default

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants