Bug 1887465 - Deleted project is still referenced
Summary: Deleted project is still referenced
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.7.0
Assignee: Jon Jackson
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-12 14:32 UTC by Serena
Modified: 2023-09-15 00:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Logic for maintaining active Namespace didn't account for deleting the currently active namespace. Consequence: A Namespace that was recently deleted in the UI could remain set as the currently active Namespace. Fix: Update active namespace logic so that it defaults to "All namespaces" when a user deletes the currently active namespace. Note this is only scoped to the current browser session. (i.e. this doesn't have any effect if the user deletes the Namespace from the CLI or another browser session). Result: When the user deletes the currently active Namespace via the UI, the active namespace in that same browser session is automatically updated to "All Namespaces"
Clone Of:
Environment:
Version: 4.6.0-0.nightly-2020-10-03-051134 Cluster ID: 85344935-f428-4484-bc6d-81990c53a9df Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
Last Closed: 2021-02-24 15:25:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 6975 0 None closed Bug 1887465: Fall back to "all namespaces" when currently active namespace is deleted 2021-01-11 14:42:10 UTC
Red Hat Product Errata RHSA-2020:5633 0 None None None 2021-02-24 15:25:56 UTC

Description Serena 2020-10-12 14:32:57 UTC
Description of problem:
Project/namespace remains selected in main project dropdown after deletion.


Version-Release number of selected component (if applicable):
4.6

How reproducible:
Always


Steps to Reproduce:
1. In the Admin perspective, Go to Pods 
2. Create new project & select that project
3. go to project view in admin console 
4. delete project
4. click "installed operators"

Actual results:
Note that the new project is still referenced in the Project dropdown

Expected results:
The deleted project should no longer be referenced in the Project dropdown

Additional info:
** this happens regardless of the perspective

Comment 1 Serena 2020-10-12 14:35:13 UTC
FYI @amobrem @ejacobs

Comment 2 Jon Jackson 2020-10-19 19:57:16 UTC
Started looking into this and it turns out that this is working as expected. Further discussion found that his is an edge case in the original implementation. There are some cases where we still want the active namespace to remain, even if it's not a selectable item in the dropdown.

Discussed with Sam Padgett who implemented the original behavior. The problem is that when a project is not present in that dropdown, we don't know why. It could have been deleted, or the user might not have permission to see it. In the case where a user doesn't have permission to see a project in the dropdown, they still might be able to view some info in the project via direct link. For that reason, the active namespace must be based on the url parameters and not the user's project permissions.

All of that being said, we CAN handle the case where the delete action happened from the same browser instance (i.e. the case this bug presents). We can react directly to the delete action in the UI, and adjust the active namespace accordingly.

Comment 3 Jon Jackson 2020-10-23 15:09:55 UTC
PR pending

Comment 5 Yadan Pei 2020-11-03 09:12:32 UTC
1. Create a new project yapeitest and view project scope resource pages such as Workloads -> Pods, Operators -> Installed Operators, current active project `yapeitest` is selected automatically
2. Navigate to projects list page and delete `yapeitest` project from console, wait until project is successfully deleted
3. In the current browser window, navigate to project scope resource pages, such as Builds -> Build Configs, Networking -> Services, `all projects` is selected 

But when the project is deleted by CLI, the deleted project is still referenced/selected in project dropdown selector, this should be working as expected. 

@Jon I see you mentioned this `If a user deletes their currently active namespace from the UI, fall back to selecting "all namespaces" as the active namespace`  in PR description, but I would like to double confirm with you. Current behavior(described above) is correct, right?

Comment 6 Jon Jackson 2020-11-03 14:53:55 UTC
(In reply to Yadan Pei from comment #5)
> 1. Create a new project yapeitest and view project scope resource pages such
> as Workloads -> Pods, Operators -> Installed Operators, current active
> project `yapeitest` is selected automatically
> 2. Navigate to projects list page and delete `yapeitest` project from
> console, wait until project is successfully deleted
> 3. In the current browser window, navigate to project scope resource pages,
> such as Builds -> Build Configs, Networking -> Services, `all projects` is
> selected 
> 
> But when the project is deleted by CLI, the deleted project is still
> referenced/selected in project dropdown selector, this should be working as
> expected. 
> 
> @Jon I see you mentioned this `If a user deletes their currently active
> namespace from the UI, fall back to selecting "all namespaces" as the active
> namespace`  in PR description, but I would like to double confirm with you.
> Current behavior(described above) is correct, right?

Yes, this is the correct behavior. We can't change the selected project when it is deleted in the "background". I explain a little bit about why this is in Comment 2:

> Discussed with Sam Padgett who implemented the original behavior. The
> problem is that when a project is not present in that dropdown, we don't
> know why. It could have been deleted, or the user might not have
> permission to see it. In the case where a user doesn't have permission
> to see a project in the dropdown, they still might be able to view some
> info in the project via direct link.

So, we only want to fall back to "all-namespaces" when we know the project was deleted. The only time we know that is when the deletion happens through the console in the current browser session.

Comment 7 Yadan Pei 2020-11-04 01:25:32 UTC
Thank you Jon pointing me the comment.

Moving to VERIFIED

Comment 10 errata-xmlrpc 2021-02-24 15:25:25 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.7.0 security, bug fix, and enhancement 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-2020:5633

Comment 11 Red Hat Bugzilla 2023-09-15 00:49:32 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days


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