Skip to content
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

Merged
merged 17 commits into from
Sep 3, 2021
Merged

Conversation

timroes
Copy link
Contributor

@timroes timroes commented Aug 24, 2021

Summary

For release notes:

Details:
The deprecated kibana.yml setting kibana.defaultAppId (also available as kibana_legacy.defaultAppId) has been removed.

Impact:
When upgrading you need to remove this setting from you kibana.yml file if used. You should use the defaultRoute 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 the defaultRoute advanced setting.

Changes

  • URLs like /app/discover#/visualize that worked beforehand and brought you despite the /app/discover URL to visualize. There should be no use-case for these URLs and we drop support for them via this PR.
  • /app/discover/#foobarOrSomethingNonExisting lead you to the defaultAppId. 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 the kibana.defaultAppId and will now bring you to the defaultRoute of the current space instead.

Checklist

Delete any items that are not applicable to this PR.

@timroes timroes added release_note:breaking Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.0.0 labels Aug 24, 2021
@timroes
Copy link
Contributor Author

timroes commented Aug 30, 2021

@elasticmachine merge upstream

Copy link
Member

@kertal kertal left a 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:

Bildschirmfoto 2021-08-30 um 18 06 49

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).

@timroes
Copy link
Contributor Author

timroes commented Aug 30, 2021

@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?

@kertal
Copy link
Member

kertal commented Aug 31, 2021

@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

@timroes
Copy link
Contributor Author

timroes commented Aug 31, 2021

@elasticmachine merge upstream

@@ -78,7 +69,7 @@ export function HomeApp({ directories, solutions }) {
hasUserIndexPattern={() => indexPatternService.hasUserIndexPattern()}
/>
</Route>
<Route path="*" exact={true} component={RedirectToDefaultApp} />
<Redirect to="/" />
Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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) {
Copy link
Contributor Author

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.

@timroes timroes marked this pull request as ready for review September 1, 2021 06:04
@timroes timroes requested review from a team as code owners September 1, 2021 06:04
@elasticmachine
Copy link
Contributor

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');
Copy link
Contributor Author

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 :)

@timroes timroes marked this pull request as draft September 1, 2021 06:23
Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

Operations: LGTM

@mshustov
Copy link
Contributor

mshustov commented Sep 1, 2021

@timroes is the PR ready for review?

@timroes
Copy link
Contributor Author

timroes commented Sep 2, 2021

@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

@timroes timroes marked this pull request as ready for review September 2, 2021 11:36
Copy link
Contributor

@mshustov mshustov left a 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

Copy link
Contributor

@stratoula stratoula left a 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?

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
home 69 67 -2
urlForwarding 12 11 -1
total -3

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
kibanaLegacy 66 64 -2
urlForwarding 15 12 -3
total -5

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
discover 525.6KB 525.5KB -75.0B
home 120.4KB 119.7KB -775.0B
total -850.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
home 16.1KB 15.6KB -523.0B
kibanaLegacy 45.9KB 45.7KB -204.0B
urlForwarding 11.8KB 10.7KB -1.1KB
total -1.8KB
Unknown metric groups

API count

id before after diff
kibanaLegacy 70 68 -2
urlForwarding 15 12 -3
total -5

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Member

@kertal kertal left a 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

@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 109798 or prevent reminders by adding the backport:skip label.

@kibanamachine kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Sep 7, 2021
@timroes timroes added the backport:skip This commit does not require backporting label Sep 7, 2021
@kibanamachine kibanamachine removed the backport missing Added to PRs automatically when the are determined to be missing a backport. label Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:breaking Team:Visualizations Visualization editors, elastic-charts and infrastructure v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove kibana.defaultAppId
7 participants