Bug 1827086 - Toolbar filter has inconsistent element issues of Name across different resources page.
Summary: Toolbar filter has inconsistent element issues of Name across different resou...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.5
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 4.5.0
Assignee: Joe Caiani
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-23 08:49 UTC by XiaochuanWang
Modified: 2020-07-13 17:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: different filter components being used on different pages Consequence: inconsistent visual filter issues Fix: provide a single component for all views Result: provides a consistent toolbar across views
Clone Of:
Environment:
Last Closed: 2020-07-13 17:30:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
compare the Name filter across Search and Pod pages (712.97 KB, image/png)
2020-04-23 08:49 UTC, XiaochuanWang
no flags Details
Verification screenshot (71.25 KB, image/png)
2020-05-13 08:40 UTC, XiaochuanWang
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 5294 0 None closed Bug 1827086: Align list view toolbar with search using pf toolbar component 2021-01-08 14:04:08 UTC
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-07-13 17:30:44 UTC

Description XiaochuanWang 2020-04-23 08:49:08 UTC
Created attachment 1681033 [details]
compare the Name filter across Search and Pod pages

Description of problem:
The Chip Group "Name" will always display ahead of the other Chip Group, but Search page orders normally.


Version-Release number of selected component (if applicable):
4.5.0-0.nightly-2020-04-21-103613

How reproducible:
Always

Steps to Reproduce:
1. User go to resource list page, such as Pods or Deployment.
2. Add some filters by Status or Labels, then add a Name filter
3. (Compare to the correct page) Go to Search page, repeat the step2 and check

Actual results:
2. Name filter is always display ahead of the others, which is incorrect. (refer to the screenshot)

Expected results:
2. The last added filter should append in the end of Chip Groups filters.

Additional info:
There is another inconsistent issue for "Name":
Search page does not have Close button for Chip Group "Name" but all the other resources pages have Close button for "Name"

Comment 1 Robb Hamilton 2020-04-27 13:07:22 UTC
Reassigning to Bipul as he worked on the original implementations.

Comment 2 Bipul Adhikari 2020-04-29 12:41:46 UTC
If you look into the search page. The "Resource" chip will always come first even if you type "Name" first. We can remove the close button from the "Name" chip in the list page to make it more aligned with the Search Page. But AFAIK natural selection order preservation is not present in the "Search" page as well.

Comment 3 Bipul Adhikari 2020-04-29 12:58:43 UTC
Sorry I was looking at a 4.4 Cluster. Apparently it maintains order in 4.5.

Comment 4 Joe Caiani 2020-05-08 16:58:49 UTC
moving to upcoming sprint: the bugfix is in code review. will be merged in for upcoming sprint

Comment 7 XiaochuanWang 2020-05-13 08:40:14 UTC
Created attachment 1687991 [details]
Verification screenshot

Comment 8 XiaochuanWang 2020-05-13 08:43:06 UTC
Search page and other pages are same now: 1) filter items ordered by user's selection. 2) Name removed the duplicated Close button on the group chip card.
Refer to the verification screenshot.
Verified on 4.5.0-0.nightly-2020-05-13-043728

Comment 9 errata-xmlrpc 2020-07-13 17:30:33 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, 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/RHBA-2020:2409


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