Bug 1839101 - Some sidebar links in developer perspective don't follow same project
Summary: Some sidebar links in developer perspective don't follow same project
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Dev Console
Version: 4.4
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: 4.8.0
Assignee: Christoph Jerolimov
QA Contact: spathak@redhat.com
Rishu Mehra
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-22 13:37 UTC by Felipe M
Modified: 2022-11-04 08:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
If you have the console open in multiple tabs, some sidebar links in the *Developer* perspective do not directly link to the project, and there is an unexpected change in the selected project. This will be resolved in a future release. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1839101[*BZ#1839101*])
Clone Of:
Environment:
Last Closed: 2021-07-27 22:32:23 UTC
Target Upstream Version:


Attachments (Terms of Use)
Sidebar links in developer perspective follow the same project (1.32 MB, video/webm)
2021-05-04 13:09 UTC, spathak@redhat.com
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 8249 0 None open [WIP] Bug 1839101: Add namespaced attribute to main navigation links 2021-02-25 18:13:57 UTC
Red Hat Product Errata RHSA-2021:2438 0 None None None 2021-07-27 22:33:11 UTC

Description Felipe M 2020-05-22 13:37:06 UTC
Description of problem:
Some links on the sidebar in Developer perspective don't directly link to the project, causing confusing behavior if user has the console open in multiple tabs.

Version-Release number of selected component (if applicable):
4.4, 4.3 confirmed (4.2 potentially too)

How reproducible:
Having two projects "project-a" and "project-b"

Steps to Reproduce:
1. Open one tab with project-a
2. Open second tab with project-b
3. Click on links on the sidebar for project-a's tab

Actual results:
Some links contain project ID of the current tab, others not and redirect potentially using local storage `bridge/last-namespace-name` to 'project-b'.

Expected results:
All links contain the project ID of the current tab

Additional info:
- I intended to submit a pull request to fix this, but I'm not sure if this is by design for some reason.
- I checked the menu in Administrator perspective and all links seems fine.

Comment 1 cvogt 2020-05-25 17:11:40 UTC
This isn't by design.
Pages that are based on a resource kind currently update to include the namespace in the link while pages do not. Those pages use a different component that is more generic and doesn't support this capability. This is something we should consider for all pages that are namespace scoped.

Comment 2 Andrew Ballantyne 2020-05-26 20:12:33 UTC
Hi Felipe M,

Did you encounter this issue where it would not respect your current selected project while navigating around when having multiple tabs open? I ran a few tests trying to reproduce this and I noticed that even when multiple tabs were open, each nav item navigated without an issue to all links in the developer perspective. 

If I opened a link to a new tab (right-click "open in new tab") then it took the last namespace I interacted with (local storage value) rather than the current namespace one.

Is this the issue you saw? Or were you just remarking on the anchor hover info provided by the browser?

Let me know when you get a chance.

Thanks,
Andrew

Comment 4 Felipe M 2020-05-27 07:17:39 UTC
Hi Andrew,

the issue I'm opening this for is the detailed in the second paragraph:

> If I opened a link to a new tab (right-click "open in new tab") then it took the last namespace I interacted with (local storage value) rather than the current namespace one.

There are some links in the Developer sidebar that don't contain the namespace in the anchor (thus using local storage), so if you've interacted with `project-b` in other tabs and try to navigate on the tab from `project-a` to one of those links, you get moved to `project-b` instead.

Comment 5 Andrew Ballantyne 2020-05-27 19:13:50 UTC
Right, this is definitely not by design (as Christian mentioned) so we'll need to address this. Thank you for logging the issue and clarifying the user experience you had.

Comment 7 cvogt 2020-05-29 15:27:53 UTC
(In reply to Felipe M from comment #4)
> There are some links in the Developer sidebar that don't contain the
> namespace in the anchor (thus using local storage), so if you've interacted
> with `project-b` in other tabs and try to navigate on the tab from
> `project-a` to one of those links, you get moved to `project-b` instead.

I do not encounter this behavior. Even though the links do not contain the current namespace, the links all open to the expect namespace. This is because on load of the app, the namespace value is pulled from localStorage but then stored in memory and we do not pull from localStorage again.

There is one smaller issue where opening the link in a new tab will result in switching over to `project-b`. This is because the web app will need to load in the new tab and therefore pulls the namespace from localStorage.

Comment 15 Rishu Mehra 2021-02-19 15:49:06 UTC
Updated the doc text field with the required content.

Comment 17 spathak@redhat.com 2021-05-04 13:09:27 UTC
Created attachment 1779365 [details]
Sidebar links in developer perspective follow the same project

Comment 18 spathak@redhat.com 2021-05-04 13:11:17 UTC
Verified on build version: 4.8.0-0.nightly-2021-04-30-102231
Browser: Google Chrome 89

Comment 21 errata-xmlrpc 2021-07-27 22:32:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438

Comment 22 Fred Day 2022-06-15 06:51:30 UTC
Because the issue mentioned in this bug report should have been handled in a recent advisory, it has been closed with an ERRATA resolution.

Follow the link below for further details on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug patch and security upgrade) and where to obtain the updated files.

If the solution does not work, please file a new bug report. https://waffle-game.com

Comment 23 Tony Whit 2022-07-05 11:59:25 UTC
Since the issue referenced in this bug report ought to have been taken care of in a new warning, it has been shut with an ERRATA resolution.

On the off chance that the resolution doesn't work, if it's not too much trouble, record another bug report. https://fridaynightfunkin.lol

Comment 24 timeline 2022-11-04 08:02:57 UTC
I had a lot of harvest after seeing this post of yours! Before, I used to play games, this is a fun game for entertainment, but now I will follow you, read your articles will have more knowledge. https://nytimescrossword.io


Note You need to log in before you can comment on or make changes to this bug.