Consistent Server Side Filtering
Summary
=======
Implement a consistent API-side filtering across all views. Current filtering options shown at the top of each table is not consistent due to different filtering methods:
a) Server: Does an API request to each service
b) Query: does a client-side filtering (using JavaScript)
By detecting and enumerating the common filtering fields available in the APIs, we could show a standard, simpler and more powerful filtering experience to end-users.
Motivation
========
Current filtering options are not consistent across all views and does not provide all the power each python-*client provides for such operation.
From the UX/UI perspective
Only two tables provide API-filtering: Project->Instances and Admin->Instances. We can consolidate the user experience across all views.
Description
=========
In order to enable API-filtering we must discover all available filtering options in python-*clients. Once we know the possibilities, we could:
- Change default filtering (query) and enable "Server" filtering where available. Target Client APIs are:
* novaclient
* cinderclient
* neutronclient
* keystoneclient
* glanceclient
* swiftclient
- Display a set of options that would enable any user to define which field(s) prefers to filter by.
We would need to define a minimum amount of fields available on each API.
UX
===
Affected views should:
- Show the field name of the current filter. At least one field is consistent across all views: name.
- Use built-in bootstrap components to render filter options as "Button with dropdowns" (http://
- Show current filtering method: equality or regex.
- Show a "loading spinner" while the request is being resolved.
Wireframes, Mocks, Videos and UI Markup
-------
Existing filter UI
Project-> Instances: http://
Project-> Volumnes: http://
Proposed filter UI
TBD
Testing
======
The filter should be able to send requests to the APIs
Outside Dependencies
==================
Still need to break down dependencies once we:
- Investigate the current filtering capabilities available in OpenStack services clients
- Investigate if there's any pending patch that provides extended filtering options
Doc Impact
=========
These changes requires an update to existing documentaiton, where we can Illustrate the filtering capabilities and options
available to end-users
Blueprint information
- Status:
- Complete
- Approver:
- Rob Cresswell
- Priority:
- High
- Drafter:
- Eddie Ramirez
- Direction:
- Approved
- Assignee:
- David Lyle
- Definition:
- Approved
- Series goal:
- Accepted for 13.0.0-queens
- Implementation:
-
Implemented
- Milestone target:
-
queens-1
- Started by
- Rob Cresswell
- Completed by
- Rob Cresswell
Related branches
Related bugs
Sprints
Whiteboard
Addressed by: https:/
Change from client filter to server filter in metadata page
Progress and tracking:
https:/
Gerrit topic: https:/
Addressed by: https:/
Server-side filtering Identity->Projects
Addressed by: https:/
[WIP] Added Server-side/API filtering for swift UI
Addressed by: https:/
Server-side filtering networks
Addressed by: https:/
More available filters in servers (Nova)
Addressed by: https:/
Server-side filtering routers
Addressed by: https:/
WIP - Server-side filtering for project images
Addressed by: https:/
Provide help-text capability for server-side filter choices
Addressed by: https:/
Registry-based client/server-side faceted searching [MERGED]
Addressed by: https:/
Move get_filters to parent Class
Addressed by: https:/
Server-side filtering for admin volumes
Addressed by: https:/
Server-side filtering Orchestration
Addressed by: https:/
[WIP] Show message if no matches found when using filters
Addressed by: https:/
Focus on filter input after user selection
Addressed by: https:/
Server-side filtering vpn
Addressed by: https:/
Implement admin_filter_first setting in Admin>Volumes
Addressed by: https:/
Add server-side filtering Floating IPs
