[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

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.17%. Comparing base (df6de4e) to head (b4f0a87).
Report is 602 commits behind head on main.

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%)	⬆️
Linux_2	55.29% <100.00%> (+0.06%)	⬆️
Linux_3	44.75% <40.47%> (-0.01%)	⬇️
Linux_4	35.05% <30.95%> (-0.01%)	⬇️
Windows_1	31.77% <45.65%> (+0.01%)	⬆️
Windows_2	55.26% <100.00%> (+0.06%)	⬆️
Windows_3	44.76% <40.47%> (-0.01%)	⬇️
Windows_4	35.05% <30.95%> (-0.01%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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

[ruanyl]

Maybe we can rename the "workspace" in prepend and remove function as well^^

[SuZhou-Joe]

I was intending to rename the withoutWorkspace to withoutClientBasePath but I was thinking in the future, the clientBasePath may consist of workspace/dataSourceId/other stuff and prependOptions will have withoutWorkspace/withoutDataSourceId/withoutClientBasePath options accordingly so I kept them.

But for now, there is no such case so it has no harm to have only one withoutClientBasePath config in prependOptions, but will add some comment here.

[ruanyl]

I see, thanks for the clarification^^

[SuZhou-Joe]

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

[ashwin-pc]

LGTM!

[ashwin-pc]

Suggested change

	it('#setup when workspace id is in url and enterWorkspace return error', async () => {
	it('should correctly set up WorkspacePlugin when workspace ID is present in the URL', async () => {

The current test title does not match whats being tested for. You dont seem to be testing for an error. This is just a suggestion based on what the test seems to be doing

[SuZhou-Joe]

Thanks, it will be automatically addressed by #6154 . A mistake when splitting a large PR into several smaller PRs.

[ashwin-pc]

Thanks for adding context here