Dashboard list of cloud account summaries
As a customer, I want to see a overview list of my cloud accounts on the dashboard page below the graphs.
Acceptance Criteria
-
Verify that with no name filter, all cloud account rows are displayed. -
Verify the rows shown are updated appropriately when the name filter changes; they should show rows filtered to cloud accounts with matching names. -
Verify the numbers for each row are updated appropriately when the date filter changes; they should show data for days in the selected date range. -
Verify that if the end date of the filter is <= the creation date of the cloud account, any numbers are shown as "N/A". -
Verify the rows are ordered according to the selector at the top of the page. (If implemented) -
Verify that each row includes: -
cloud account name -
datetime of last seen instance event -
total number of images seen active during the date period -
total number of instances seen active during the date period -
total number of instances using RHEL-tagged images seen active during the date period -
total number of instances using OpenShift-tagged images seen active during the date period
-
-
Verify an issue exists for tracking integration tests!
Assumptions and Questions
- Do we really need sorting for the pilot? Our initial customers only have O(10) cloud accounts.
- No! We do not for pilot, but we will have a story after pilot to add this feature.
- Paging and filtered list view responses. Since we're going sans-paging and not providing an automatic "give us everything" list response for the accounts summary display, the UI will have to "pre-implement" start and end date filters before "empty state" and the "account summary list" display.
- The reasoning behind requiring the initial filter is based on the processing required to generate the list.
- For distinction, this is a "search" based API pattern that offsets additional logic into the UI. Within the React component setup there is currently a correlation between component loading, and API call, this pattern will need to be adjusted.
- This sequence adjustment potentially creates disposable UI work, post-pilot if/when paging is implemented.
- When paging is implemented the UI team would like to address the requirement that a "start" and "end" date be required to access a default response. A default paged response, sans-start and sans-end date, would help eliminate additional UI checks/conditions/sequence by realigning the correlation between component and API call (lighter code, less error prone).
Edited by Ghost User