-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove kibana.defaultAppId setting #109798
Conversation
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A note about Discover changes. I wonder if we should redirect the user to another app, or like it's currently handled in this PR, just show the error message:
I think the user expects to come to Discover, so he would need to click again to return to Discover. We could e.g. show the "main" view in Discover with the message on top (and ideally add info what was the invalid URL, this could be helpful for debugging).
@kertal I think we can def improve the default routing of Discover for those cases, though while we're not having a listing page in Discover I don't know what would be a good place to bring them (in the other apps they are brough to the listing page). I'd def see this outside of this PR, so maybe you could file a separate issue for better default routing where we can discuss the best way? |
Agreed, will open an issue |
@elasticmachine merge upstream |
@@ -78,7 +69,7 @@ export function HomeApp({ directories, solutions }) { | |||
hasUserIndexPattern={() => indexPatternService.hasUserIndexPattern()} | |||
/> | |||
</Route> | |||
<Route path="*" exact={true} component={RedirectToDefaultApp} /> | |||
<Redirect to="/" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ This adds a redirect to the home page in case any unknown route has been entered. With the old logic the existing Route
would have taken care of forwarding to the defaultAppId
in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not redirect to defaultRoute
set in uiSettings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The question is: why would only the Home page do that in this case, and not ALL apps? I feel it's a bit weird, that something like /app/home#/fooobar
would bring you to the default app, but /app/dashboard#/foobar
wouldn't. Or we'd basically need to set this as an expactation to all apps, that if they can't find the route in their app they should forward to the default app, which sounds like a larger change to me. I am happy to rediscuss this behavior, but I think we should not make a special case JUST for the home app and nothing else, and in this case rather let every app handle their "unknown route" internally to do something reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we'd basically need to set this as an expactation to all apps, that if they can't find the route in their app they should forward to the default app, which sounds like a larger change to me.
agree. that sounds like a high-level policy.
const [, , kibanaLegacyStart] = await core.getStartServices(); | ||
kibanaLegacyStart.navigateToDefaultApp(); | ||
const { navigated } = navigateToLegacyKibanaUrl(hash, forwards, basePath, application); | ||
if (!navigated) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ This code is required to make sure that the following URLs keep working: /app/kibana#/foobarOrSomeOtherNonExistingNonesense
Earlier the code navigated to the configured defaultAppId
. With this change we'll just navigate to /
in the current space (thus the basePath.get()
), which will itself triggering the behavior looking for the configured defaultRoute
and bringing us there.
Pinging @elastic/kibana-vis-editors (Team:VisEditors) |
@@ -26,7 +26,7 @@ export default function ({ getService, getPageObjects }) { | |||
}); | |||
|
|||
it('clicking on console on homepage should take you to console app', async () => { | |||
await PageObjects.common.navigateToUrl('home'); | |||
await PageObjects.common.navigateToApp('home'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ This would actually not be needed with further changes I made to the PR, since those URLs are now handled properly, but imho that looks anyway nicer, so I just left it in :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Operations: LGTM
@timroes is the PR ready for review? |
@mshustov I still wanted to provide tests for the url_forward function, but besides that it's done. I just thought I wait till I got time to finish the tests before pushing it into review... but since I anyway misclicked earlier and pinged everyone already, I think I can already set it to review know - pending some more incoming tests :D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok for Home plugin changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kibana-vis-editors team changes LGTM. I tested it locally in Chrome and works as expected!
@timroes the cloud PR to remove the whitelisted setting is not ready yet, right?
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, code owner review. opened an issue to improve the changed behavior in Discover: #111172
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Summary
For release notes:
Details:
The deprecated kibana.yml setting
kibana.defaultAppId
(also available askibana_legacy.defaultAppId
) has been removed.Impact:
When upgrading you need to remove this setting from you
kibana.yml
file if used. You should use thedefaultRoute
Advanced Setting (within the Kibana UI > Stack Management > Advanced Setting) to configure a default route for users when entering a space.Fixes #54088
This PR removes the
kibana.defaultAppId
setting, which has been deprecated and replaced since a while with thedefaultRoute
advanced setting.Changes
/app/discover#/visualize
that worked beforehand and brought you despite the/app/discover
URL tovisualize
. There should be no use-case for these URLs and we drop support for them via this PR./app/discover/#foobarOrSomethingNonExisting
lead you to thedefaultAppId
. The behavior for those is now changing. They will lead you to Discover and use whatever Discover (or other corresponding apps) have setup as their "unknown route" behavior. Visualize and Dashboard already had reasonable default behaviors for unknown routes. For the Home application I added it in this PR (see inline comments). Discover we have some ongoing routing work, thus I would refer the change there to a separate PR./app/kibana#/discover
Those URLs keep working as beforehand and will forward you to the corresponding app./app/kibana#/foobarOrSomethingNonExisting
Those URLs earlier brought you to thekibana.defaultAppId
and will now bring you to thedefaultRoute
of the current space instead.Checklist
Delete any items that are not applicable to this PR.
[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)[ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)[ ] This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)[ ] This was checked for cross-browser compatibility