* node eligibilty taken into consideration when clients list filtered to 'ready'
* A working draft of complex positive querying
* tags and filter badge
* CompositeStatus -> Status
* Buttons within a Helios SegmentedGroup
* Convert the other dropdowns to helios on clients index
* A bunch of client index test fixes
* Remaining clients list acceptance tests for State facet modified
* Color the status cell for servers and nodes
* Testfix and changelog
* Leader indicator moved post-word
* Icon and badge treatment
* Capitalizing test checks
* HDS badges dont expose statusClass like we used to, so stop checking for it
Manual interventions:
• decorators on the same line for service and controller
injections and most computed property macros
• preserving import order when possible, both per-line
and intra-line
• moving new imports to the bottom
• removal of classic decorator for trivial cases
• conversion of init to constructor when appropriate
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
