Add the tenant into the short URL once the short URL is resolved

[leanneeliatra]

Description

This is a duplicate PR (closed) to #1443,
Copying the changes from a branch branched from main allowed me a cleaner & safer way to perform similar rebase.

---

When the tenancy is being changed after copying a short URL, if the user then pastes this short URL into a new tab, the user will be redirected to the current selected tenant, not the tenant as specified in the copied short URL.
We need to retain this information in the URL and redirect so the user is brought to the correct link, with the correct user.

Category

[Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation]

Why these changes are required?

To enable sharing of a short URL with the tenant as specified in the URL remaining selected as the active tenant.

What is the old behavior before changes and new behavior after changes?

The old behaviour is:

1. A short URL is copied (tenant is specified in the URL)
2. The tenant is changed
3. The link is loaded in a new tab
4. The tenant remains as is specified in 2, not as we would want/expect it to be as per the URL

The new behaviour is:

1. A short URL is copied (tenant is specified in the URL)
2. The tenant is changed
3. The link is loaded in a new tab
4. The link is loaded with tenant info retained.

The goal of the piece of code

• Solve issue 1203 which led to the user being directed to the incorrect tenant. This was happening in the case the short URL was copied, then the tenant was changed & the URL was loaded in a new tab.The outcome was the tenant specified in the short URL was not maintained on page load.

How it is done

• The short URL when copied and pasted has the security_tenant, however, when the URL is being rendered and parsed, this information was not retained in the resolved short URL.
• Upon page reload, the security tenant was fetched again from the localstorage, which was the switched tenant (not the tenant originally specified in the short URL.)

Why it is done this way

• Therefore in the case of multitenancy, when parsing the short URL, we inject the security tenant into the short URL, adding it as a parameter and retaining this information then in the resolved URL. Allowing the page to correctly load the page, with the correct tenant that was specified & copied in the short URL.
• The addTenantParameterToResolvedShortLink controls this functionality.

Other attempted solutions:

The first solution implemented to fix this issue, was to wipe the local storage to solve this issue.
However, once it was done, I realised the localstorage value was needed elsewhere & could not be wiped as intended.
New solutions were considered, perhaps using a cookie, which came with it's own challenges to change how localstorage is currently being used.
In the end, the solution that maintained the localstorage (as it was needed in the code for other purposes) and solved the issue at hand (couldn't change the tenant after copying the short URL), was to, if the tenant was changed in multitenancy mode, to make sure the tenant information remained in the short URL (it was there before page load but is removed from the resolved URL, we ensured the tenant information was retained in the resolved URL) and also, remove any specifics of the URL (so the user wouldn't be brought to a dashboard that doesn't exist in that tenant and get an error message).

Issues Resolved

[BUG] Shortlinks to other Tenants do not work #1203

Testing

Submitting the PR for an initial review of changes, tests will follow.

Check List

• New functionality includes testing
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[DarshitChanpura]

LGTM. Waiting on CI before approval. Thank you for being on top of addressing comments

[codecov]

Codecov Report

Merging #1462 (10cb5f4) into main (8dab6a3) will not change coverage.
The diff coverage is n/a.

❗ Current head 10cb5f4 differs from pull request most recent head 888f809. Consider uploading reports for the commit 888f809 to get more accurate results

@@           Coverage Diff           @@
##             main    #1462   +/-   ##
=======================================
  Coverage   65.62%   65.62%           
=======================================
  Files          93       93           
  Lines        2307     2307           
  Branches      314      309    -5     
=======================================
  Hits         1514     1514           
  Misses        725      725           
  Partials       68       68           

see 1 file with indirect coverage changes

[DarshitChanpura]

Hey @leanneeliatra I'd suggest writing a unit test in jest and an end-to-end test in functional test repo.

[leanneeliatra]

Hey @leanneeliatra I'd suggest writing a unit test in jest and an end-to-end test in functional test repo.

Thanks @DarshitChanpura, The unit test is done, I'll do the end-to-end test in cypress in the functional test repo.

[cwperks]

Thank you @leanneeliatra! This change looks good to me. I am adding the backport 2.x label.

[opensearch-trigger-bot]

The backport to 1.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.x 1.x
# Navigate to the new working tree
cd .worktrees/backport-1.x
# Create a new branch
git switch --create backport/backport-1462-to-1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e9f95763a16f5e42247830ff6083af6ef7014e9b
# Push it to GitHub
git push --set-upstream origin backport/backport-1462-to-1.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.x

Then, create a pull request where the base branch is 1.x and the compare/head branch is backport/backport-1462-to-1.x.

[opensearch-trigger-bot]

The backport to 1.3 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.3 1.3
# Navigate to the new working tree
cd .worktrees/backport-1.3
# Create a new branch
git switch --create backport/backport-1462-to-1.3
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e9f95763a16f5e42247830ff6083af6ef7014e9b
# Push it to GitHub
git push --set-upstream origin backport/backport-1462-to-1.3
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.3

Then, create a pull request where the base branch is 1.3 and the compare/head branch is backport/backport-1462-to-1.3.