[Workspace] Add workspace id in basePath

[SuZhou-Joe]

Description

In order to let users switch to specific workspace when paste a deep link from other users, we need to make url stateful with workspace info. This PR mainly introduce the capability to keep the workspace Id in url consistent with the workspace id in memory so that user can feel free to copy the url and share to others.

You can find all the options and discussions from the RFC issue: #5243 .

Issues Resolved

#6015

Screenshot

Testing the changes

• Using the branch to bootstrap
• Enable workspace by adding workspace.enabled to opensearch_dashboards.yml file
• Start OSD by using yarn start --no-base-path to make sure no random base path will be appended
• Visit the OpenSearch Dashboards under foo workspace: http://localhost:5601/w/foo/app/dev_tools
• You will find /w/foo params will always be there when you navigate between left navigation, making the url shareable.

Check List

• [x] All tests pass
  • [x] yarn test:jest
  • [x] yarn test:jest_integration
• [x] New functionality includes testing.
• [x] New functionality has been documented.
• [x] Update CHANGELOG.md
• [x] Commits are signed per the DCO using --signoff

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.17%. Comparing base (df6de4e) to head (b4f0a87).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6060      +/-   ##
==========================================
+ Coverage   67.16%   67.17%   +0.01%     
==========================================
  Files        3327     3328       +1     
  Lines       64415    64448      +33     
  Branches    10366    10376      +10     
==========================================
+ Hits        43262    43295      +33     
  Misses      18621    18621              
  Partials     2532     2532              

Flag	Coverage Δ
Linux_1	31.74% <45.65%> (+0.01%)	:arrow_up:
Linux_2	55.29% <100.00%> (+0.06%)	:arrow_up:
Linux_3	44.75% <40.47%> (-0.01%)	:arrow_down:
Linux_4	35.05% <30.95%> (-0.01%)	:arrow_down:
Windows_1	31.77% <45.65%> (+0.01%)	:arrow_up:
Windows_2	55.26% <100.00%> (+0.06%)	:arrow_up:
Windows_3	44.76% <40.47%> (-0.01%)	:arrow_down:
Windows_4	35.05% <30.95%> (-0.01%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[ashwin-pc]

I was following your test instructions. Inserting a test workspace did not do anything. If i inserted a workspace called foo but added /w/bar to the URL. /w/bar persisted. Deleting the foo workspace from the .kibana index did not change this behaviour either.

[SuZhou-Joe]

Deleting the foo workspace from the .kibana index did not change this behaviour either.

Correct because in this PR we do not introduce the validation part(in order to make this PR small and focus), so even if there is no specific workspace id in .kibana index, the persistent behavior will still be there.

Validation part will be introduced by another PR, which depends on this PR and #6093 so have not been raised yet.

[SuZhou-Joe]

@ashwin-pc I think the major concern left is the one that we may introduce an in-direct dependency in core to plugin (https://github.com/opensearch-project/OpenSearch-Dashboards/pull/6060#discussion_r1517106496) , For now there are two options:

1. Leave it as it is and add a TODO comment to optimize that part in the future with a following issue.
2. Revert to the version I mentioned in the response, which will get clientBasePath no matter workspace is enabled or not. You can find the diff here: https://github.com/opensearch-project/OpenSearch-Dashboards/pull/6060/commits/64b364545164ac3da2e43189ec060ad72f4a559b#diff-f1218ada97a1395de9cad0d115290e84da30f1666d5092e86a12d92a486813b3 .

Which option do you perfer?

[ashwin-pc]

@ashwin-pc I think the major concern left is the one that we may introduce an in-direct dependency in core to plugin (#6060 (comment)) , For now there are two options:

1. Leave it as it is and add a TODO comment to optimize that part in the future with a following issue.
2. Revert to the version I mentioned in the response, which will get clientBasePath no matter workspace is enabled or not. You can find the diff here: 64b3645#diff-f1218ada97a1395de9cad0d115290e84da30f1666d5092e86a12d92a486813b3 .

Which option do you perfer?

Think this goes back to my initial question, dont we already have access to the config in core? Here is where we inject the metadata from the config into the injected metadata (Link). Branding uses this to decide how to apply branding to the app. We then use this data in core to do things similar to what you are doing here. The difference is that this looks for the config value instead of the existence of a plugin and hence does not have a dependency on the plugin. This should solve both, the need for the front end workspaces component in this PR for rerouting and the selective workspace ID parsing

[SuZhou-Joe]

But there are some difference, config for branding is a core configuration while the config for workspace is a plugin configuration. Plugin configurations are transformed to uiPlugins, so workspace.enabled = true equals: workspace plugin can be found in uiPlugins list. If we try to find the real config workspace.enabled, we need to expose the raw config to browser side in server/render_service and I afraid that may expose too much info.

[ruanyl]

@ashwin-pc I think the major concern left is the one that we may introduce an in-direct dependency in core to plugin (#6060 (comment)) , For now there are two options:

1. Leave it as it is and add a TODO comment to optimize that part in the future with a following issue.
2. Revert to the version I mentioned in the response, which will get clientBasePath no matter workspace is enabled or not. You can find the diff here: 64b3645#diff-f1218ada97a1395de9cad0d115290e84da30f1666d5092e86a12d92a486813b3 .

Which option do you perfer?

I tend to choose the 2nd approach. If someone tries to visit a workspace URL when workspace is disabled, I think it's fine as long as it returns 404.

[SuZhou-Joe]

@ashwin-pc Reverted to option 2, could you please help to review here?