[Stateful sidenav] Welcome tour

[sebelga]

In this PR I've added the "Solution view welcome tour".

The tour only shows in the following condition

• When there is only 1 space (the "default") and it has a solution set
• If it hasn't been closed by the user

Other rules in place:

• Once the first user closes the tour, other users won't see the tour (the flag is stored in Global settings)
• If the users edits the default space and sets a solution, the tour won't show, even if there is only one space
• If the user has 2 spaces and deletes 1 space, the tour won't show (even if the space has a solution set)
• When the user sees the tour, if they click on the space drop down to open it and then they click on the "Manage spaces" button, the tour is hidden and not shown anymore. We assume that they took action from the tour message.

Fixes https://github.com/elastic/kibana-team/issues/1142

Screenshots

How to test

• Add the following in your kibana.dev.yml

xpack.cloud.id: "ftr_fake_cloud_id:aGVsbG8uY29tOjQ0MyRFUzEyM2FiYyRrYm4xMjNhYmM="
xpack.cloud.base_url: "https://cloud.elastic.co"

• Launch Kibana and navigate to /app/management/kibana/spaces/edit/default
• Edit the default space by setting one of the solution view (e.g. "search")
• Delete the Global settings es doc sending this request

curl -XDELETE -u system_indices_superuser:changeme  "http://localhost:9200/.kibana/_doc/config-global:9.0.0" -H "kbn-xsrf: spaces"

• Refresh the browser window
• You should see the tour dialog

[sebelga]

/ci

[sebelga]

/ci

[sebelga]

/ci

[sebelga]

/ci

[sebelga]

/ci

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: 4cd3226df26b84c2f8debe558e0838a756bfd979
• Interpreting CI Failures

Failed CI Steps

• FTR Configs #16
• FTR Configs #16
• FTR Configs #90

Test Failures

• [job] [logs] FTR Configs #16 / Spaces app (with solution view) space solution tour solution tour does show the solution tour if the default space has a solution set
• [job] [logs] FTR Configs #16 / Spaces app (with solution view) space solution tour solution tour does show the solution tour if the default space has a solution set
• [job] [logs] FTR Configs #90 / transform - creation - runtime mappings & saved search creation with runtime mappings batch transform with pivot configurations and runtime mappings navigates through the wizard and sets all needed fields

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
spaces	332	335	+3

Async chunks

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

id	before	after	diff
spaces	254.5KB	255.0KB	+581.0B

Page load bundle

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

id	before	after	diff
spaces	31.1KB	33.5KB	+2.4KB

History

• 💔 Build #239817 failed 1ef329426da332ac0eb1bee63d29d2156d383f7f
• 💔 Build #239555 failed cabcc6a99f588fe038179f10f2e5af9aeb26aef0
• 💔 Build #239410 failed 5a93dd76ccf28275096c5d588ff70721de7a5f92

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

cc @sebelga

[sebelga]

/ci

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[azasypkin]

I have a few nits, but my main concern is that we seem to be calling the Spaces API even if we know the user has already closed the tour. This is problematic since the tour is a one-time thing for new users, while the redundant call will affect everyone.

[azasypkin]

Imaging all the logic/variables you'd have to put in place for the cache + deal with potential concurrent calls to the Promise (which makes an HTTP request)

Well, I don't think these additional variables would be that scary comparing to BehaviorSubject, defer, pipes, switchMap, shareReplay, subscribe, and unsubscribe machinery that one should be sufficient familiar with to understand the flow.

Just for the record, I had something like that in mind (not tested though, semi-pseudo code):

export function initTour(core: CoreStart, spacesManager: SpacesManager) {
  const showTourUiSettingValue = core.settings.globalClient.get(SHOW_SPACE_SOLUTION_TOUR_SETTING);
  async function shouldShowTour() {
    // We don't show tour if there are already multiple spaces in the cluster.
    const spaces = await spacesManager.getSpaces();
    if (spaces.length > 1) {
      return false;
    }

    // We don't show tour if default space's solution is `classic`.
    const defaultSpace = spaces.find(({ id }) => id === 'default');
    return !defaultSpace.solution || defaultSpace?.solution === SOLUTION_VIEW_CLASSIC;
  }

  function hideTourInGlobalSettings() {
    core.settings.globalClient.set(SHOW_SPACE_SOLUTION_TOUR_SETTING, false).catch(() => {
      // Silently swallow errors, the user will just see the tour again next time they load the page
    });
  }

  // Don't make call to Spaces API if the setting is explicitly set to false.
  let cachedShouldShowTourPromise: Promise<boolean> | null =
    showTourUiSettingValue === false ? Promise.resolve(false) : null;
  return {
    shouldShowTour: () => {
      if (!cachedShouldShowTourPromise) {
        cachedShouldShowTourPromise = shouldShowTour().then((shouldShow) => {
          // Disable the tour if the setting isn't yet explicitly set to false.
          if (!shouldShow && showTourUiSettingValue !== false) {
            hideTourInGlobalSettings();
          }
          return shouldShow;
        });
      }
      return cachedShouldShowTourPromise;
    },
    onFinishTour: () => {
      hideTourInGlobalSettings();
      cachedShouldShowTourPromise = Promise.resolve(false);
    },
  };
}

Anyway, code style is not something I’d block the functionality over as long as it's performant and functionally correct. I’m just genuinely curious why people like Observables, since I don’t, at least in the vast majority of cases.

[azasypkin]

question: @elastic/kibana-core, is a workaround like this the only way we have to “reset” config-global in tests?

[azasypkin]

It creates other types of problem.

Are you referring to the fact that we always render SolutionViewTour no matter what solution the active space is configured with?

[sebelga]

Thanks for the review @azasypkin. I addressed all your feedback, can you have another look? thanks!

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: fc00407

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
spaces	332	335	+3

Async chunks

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

id	before	after	diff
spaces	254.5KB	255.0KB	+581.0B

Page load bundle

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

id	before	after	diff
spaces	31.1KB	33.5KB	+2.4KB

History

• 💛 Build #241745 was flaky ed1d86e
• 💔 Build #241686 failed 7d2d8a7
• 💚 Build #240842 succeeded d7586fe
• 💔 Build #240744 failed eae5945
• 💔 Build #240571 failed 862eb61
• 💚 Build #240215 succeeded 14d5974

cc @sebelga

[azasypkin]

Okay, I think we’re good to merge. Thanks for addressing my feedback. That said, before merging, let’s also address all remaining IMPORTANT notes.

[azasypkin]

Important

How long do you think we’ll need to rely on this link? Who currently has permissions to edit or delete it? Is your plan to eventually move this to the proper Kibana docs and use the docLinks service instead?

I’m a bit concerned that we don’t have any guardrails to prevent this link from breaking or pointing to anything that it shouldn't point to. Unlike normal doc links changes to to this short URL doesn't require any review.

[sebelga]

I am guessing this tour will stay for 1 or max 2 releases. @kevinsweet controls that short URL. I think we should be able to coordinate before he deletes the link, making sure we have removed the tour in the UI.

[azasypkin]

Thanks, we should be good to go then (wasn't sure if it was going to stay forever).

[sebelga]

@kevinsweet please correct my assumptions here. If they are correct maybe we could already open the issue to remove the tour in release X?

[sebelga]

Thanks for the review @azasypkin 👍 I addressed all remaining IMPORTANT notes. Will merged once CI turns green.

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11345871196

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts You might need to backport the following PRs to 8.x: - Set spaces and roles CRUD APIs to public (#193534)

Manual backport

To create the backport manually run:

node scripts/backport --pr 194926

Questions ?

Please refer to the Backport tool documentation

[sebelga]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation