Conversation
The old fallback navigated to `/dashboard/default-overview/`, which relied on the legacy prebuilt General dashboard that no longer exists — it 404s now. Redirect to the manage page instead so the user lands on a valid route and can pick or create a dashboard.
github-actions
Bot
added
the
Scope: Frontend
gggritso
changed the title
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e9a70fc. Configure here.
Contributor
edwardgou-sentry
left a comment
edwardgou-sentry
left a comment
There was a problem hiding this comment.
I think the cursor review might be true? Without dashboards-edit it does look like the user would end up in a looping redirect. I think we'd either have to send the user to the first available prebuilt dashboard, or update the dashboard manage pages to not short circuit on missing dashboards-edit permission
Member
Author
|
Sort of! As of a few months ago |
Member
Author
|
As an aside, I also have a task to consolidate those flags and turn them back into plan flags from Flagpole |
gggritso
changed the title
edwardgou-sentry
approved these changes
Apr 28, 2026
gggritso
deleted the
georgegritsouk/fix-dashboards-remove-default-overview-redirect
branch
gggritso
added a commit
that referenced
this pull request
Apr 28, 2026
Follow-up to #113758, see more context there! tl;dr we have a new pre-built dashboard system, where pre-built dashboards are stored as database stubs, with the full dashboard config living in JSON. Therefore, I am getting rid of the last vestiges of the _previous_ prebuilt dashboard system. Right now there is just one single old pre-built dashboard called "General". This PR removes it, so it never comes back in the UI. According to the access logs, single digits users per months are looking at it, and I think they might be _us_. Here, I remove `get_prebuilt_dashboards()` and the surrounding `default-overview` prebuilt dashboard system, which returned a hardcoded widget configuration as a plain Python dict injected into API responses. Notable changes: - types that used `Dashboard | dict...` are gone now, because only _real_ `Dashboard` objects are passed around - specs that counted dashboards are all decremented by one, since the "General" dashboard is gone - there are bits of odd code where one dashboard must be left remaining, due to the "General" dashboard. I left it for now, and I'll remove it (and the front-end counterparts) in the next PR - The `DashboardTombstone` model is kept for now and will be removed in a follow-up PR along with the DB table drop. Refs DAIN-1562 --------- Co-authored-by: Claude <noreply@anthropic.com>
3 tasks
cleptric
pushed a commit
that referenced
this pull request
May 5, 2026
#113758) Dashboards have a new shiny pre-built dashboard system, where dashboards are stub objects in the database, supported by frontend JSON blobs. There's also an _old_ prebuilt dashboard system, in which there's one pre-built "General" dashboard that's stored as JSON blob in the code, and manually injected into responses. I am deleting the old one. Step 1 was hiding the pre-built dashboard selector from the UI (already done). This is Step 2, which is removing a redirect to the "General" dashboards when none are found. The changes are a bit confusing, but the summary is: - the `OrgDashboards` component is used to render a single dashboard! This happens on the URL `/dashboards/:dashboardId/` _or_ on the `/dashbords/` URL if the user doesn't have Dashboard edit permissions. HOWEVER, the `dashboards-basic` and `dashboards-edit` flags have _the same cohort_, so it's not possible to get into a case where you are looking at a single dashboard on the `/dashboards/` route. So, that UI code is gone - since that code is gone, it's no longer possible to render `OrgDashboards` without a `dashboardId`, the dashboard ID is always available from the URL, it's only rendered on routes with that URL structure. So, no need to redirect back to `/dashboards/` or anything like that, that case is now impossible - since `dashboards-basic` and `dashboards-edit` have the same rollout cohort, there's no need to redirect back to the overview from the details page Next steps will be to actually remove that dashboard from the backend, and then I can clean up the FE references to it, and replace the two flags with a single plan flag. References DAIN-1210
cleptric
pushed a commit
that referenced
this pull request
May 5, 2026
Follow-up to #113758, see more context there! tl;dr we have a new pre-built dashboard system, where pre-built dashboards are stored as database stubs, with the full dashboard config living in JSON. Therefore, I am getting rid of the last vestiges of the _previous_ prebuilt dashboard system. Right now there is just one single old pre-built dashboard called "General". This PR removes it, so it never comes back in the UI. According to the access logs, single digits users per months are looking at it, and I think they might be _us_. Here, I remove `get_prebuilt_dashboards()` and the surrounding `default-overview` prebuilt dashboard system, which returned a hardcoded widget configuration as a plain Python dict injected into API responses. Notable changes: - types that used `Dashboard | dict...` are gone now, because only _real_ `Dashboard` objects are passed around - specs that counted dashboards are all decremented by one, since the "General" dashboard is gone - there are bits of odd code where one dashboard must be left remaining, due to the "General" dashboard. I left it for now, and I'll remove it (and the front-end counterparts) in the next PR - The `DashboardTombstone` model is kept for now and will be removed in a follow-up PR along with the DB table drop. Refs DAIN-1562 --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dashboards have a new shiny pre-built dashboard system, where dashboards are stub objects in the database, supported by frontend JSON blobs. There's also an old prebuilt dashboard system, in which there's one pre-built "General" dashboard that's stored as JSON blob in the code, and manually injected into responses.
I am deleting the old one. Step 1 was hiding the pre-built dashboard selector from the UI (already done).
This is Step 2, which is removing a redirect to the "General" dashboards when none are found. The changes are a bit confusing, but the summary is:
OrgDashboardscomponent is used to render a single dashboard! This happens on the URL/dashboards/:dashboardId/or on the/dashbords/URL if the user doesn't have Dashboard edit permissions. HOWEVER, thedashboards-basicanddashboards-editflags have the same cohort, so it's not possible to get into a case where you are looking at a single dashboard on the/dashboards/route. So, that UI code is goneOrgDashboardswithout adashboardId, the dashboard ID is always available from the URL, it's only rendered on routes with that URL structure. So, no need to redirect back to/dashboards/or anything like that, that case is now impossibledashboards-basicanddashboards-edithave the same rollout cohort, there's no need to redirect back to the overview from the details pageNext steps will be to actually remove that dashboard from the backend, and then I can clean up the FE references to it, and replace the two flags with a single plan flag.
References DAIN-1210