2020-03-31 04:29:30 +00:00
|
|
|
import { alias, readOnly } from '@ember/object/computed';
|
|
|
|
import { inject as service } from '@ember/service';
|
2017-12-15 21:39:18 +00:00
|
|
|
import Controller, { inject as controller } from '@ember/controller';
|
|
|
|
import { computed } from '@ember/object';
|
2019-02-12 04:01:46 +00:00
|
|
|
import { scheduleOnce } from '@ember/runloop';
|
|
|
|
import intersection from 'lodash.intersection';
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
import SortableFactory from 'nomad-ui/mixins/sortable-factory';
|
2017-09-19 14:47:10 +00:00
|
|
|
import Searchable from 'nomad-ui/mixins/searchable';
|
2019-02-12 04:01:46 +00:00
|
|
|
import { serialize, deserializedQueryParam as selection } from 'nomad-ui/utils/qp-serialize';
|
2017-09-19 14:47:10 +00:00
|
|
|
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
export default Controller.extend(
|
|
|
|
SortableFactory(['id', 'name', 'compositeStatus', 'datacenter']),
|
|
|
|
Searchable,
|
|
|
|
{
|
2020-03-31 04:29:30 +00:00
|
|
|
userSettings: service(),
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
clientsController: controller('clients'),
|
|
|
|
|
|
|
|
nodes: alias('model.nodes'),
|
|
|
|
agents: alias('model.agents'),
|
|
|
|
|
|
|
|
queryParams: {
|
|
|
|
currentPage: 'page',
|
|
|
|
searchTerm: 'search',
|
|
|
|
sortProperty: 'sort',
|
|
|
|
sortDescending: 'desc',
|
|
|
|
qpClass: 'class',
|
|
|
|
qpState: 'state',
|
|
|
|
qpDatacenter: 'dc',
|
2020-03-13 07:18:05 +00:00
|
|
|
qpVolume: 'volume',
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
currentPage: 1,
|
2020-03-31 04:29:30 +00:00
|
|
|
pageSize: readOnly('userSettings.pageSize'),
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
|
|
sortProperty: 'modifyIndex',
|
|
|
|
sortDescending: true,
|
|
|
|
|
|
|
|
searchProps: computed(() => ['id', 'name', 'datacenter']),
|
|
|
|
|
|
|
|
qpClass: '',
|
|
|
|
qpState: '',
|
|
|
|
qpDatacenter: '',
|
2020-03-13 07:18:05 +00:00
|
|
|
qpVolume: '',
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
|
|
selectionClass: selection('qpClass'),
|
|
|
|
selectionState: selection('qpState'),
|
|
|
|
selectionDatacenter: selection('qpDatacenter'),
|
2020-03-13 07:18:05 +00:00
|
|
|
selectionVolume: selection('qpVolume'),
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
|
|
optionsClass: computed('nodes.[]', function() {
|
2020-03-13 07:18:30 +00:00
|
|
|
const classes = Array.from(new Set(this.nodes.mapBy('nodeClass')))
|
|
|
|
.compact()
|
|
|
|
.without('');
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
|
|
// Remove any invalid node classes from the query param/selection
|
|
|
|
scheduleOnce('actions', () => {
|
|
|
|
this.set('qpClass', serialize(intersection(classes, this.selectionClass)));
|
2019-02-12 04:01:46 +00:00
|
|
|
});
|
|
|
|
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
return classes.sort().map(dc => ({ key: dc, label: dc }));
|
|
|
|
}),
|
|
|
|
|
|
|
|
optionsState: computed(() => [
|
|
|
|
{ key: 'initializing', label: 'Initializing' },
|
|
|
|
{ key: 'ready', label: 'Ready' },
|
|
|
|
{ key: 'down', label: 'Down' },
|
|
|
|
{ key: 'ineligible', label: 'Ineligible' },
|
|
|
|
{ key: 'draining', label: 'Draining' },
|
|
|
|
]),
|
2017-09-19 14:47:10 +00:00
|
|
|
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
optionsDatacenter: computed('nodes.[]', function() {
|
|
|
|
const datacenters = Array.from(new Set(this.nodes.mapBy('datacenter'))).compact();
|
|
|
|
|
|
|
|
// Remove any invalid datacenters from the query param/selection
|
|
|
|
scheduleOnce('actions', () => {
|
|
|
|
this.set('qpDatacenter', serialize(intersection(datacenters, this.selectionDatacenter)));
|
|
|
|
});
|
2017-10-24 23:07:43 +00:00
|
|
|
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
return datacenters.sort().map(dc => ({ key: dc, label: dc }));
|
|
|
|
}),
|
|
|
|
|
2020-03-13 07:18:05 +00:00
|
|
|
optionsVolume: computed('nodes.[]', function() {
|
|
|
|
const flatten = (acc, val) => acc.concat(val.toArray());
|
|
|
|
|
|
|
|
const allVolumes = this.nodes.mapBy('hostVolumes').reduce(flatten, []);
|
|
|
|
const volumes = Array.from(new Set(allVolumes.mapBy('name')));
|
|
|
|
|
|
|
|
scheduleOnce('actions', () => {
|
|
|
|
this.set('qpVolume', serialize(intersection(volumes, this.selectionVolume)));
|
|
|
|
});
|
|
|
|
|
|
|
|
return volumes.sort().map(volume => ({ key: volume, label: volume }));
|
|
|
|
}),
|
|
|
|
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
filteredNodes: computed(
|
|
|
|
'nodes.[]',
|
|
|
|
'selectionClass',
|
|
|
|
'selectionState',
|
|
|
|
'selectionDatacenter',
|
2020-03-13 07:18:05 +00:00
|
|
|
'selectionVolume',
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
function() {
|
|
|
|
const {
|
|
|
|
selectionClass: classes,
|
|
|
|
selectionState: states,
|
|
|
|
selectionDatacenter: datacenters,
|
2020-03-13 07:18:05 +00:00
|
|
|
selectionVolume: volumes,
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
} = this;
|
|
|
|
|
|
|
|
const onlyIneligible = states.includes('ineligible');
|
|
|
|
const onlyDraining = states.includes('draining');
|
|
|
|
|
|
|
|
// states is a composite of node status and other node states
|
|
|
|
const statuses = states.without('ineligible').without('draining');
|
|
|
|
|
|
|
|
return this.nodes.filter(node => {
|
|
|
|
if (classes.length && !classes.includes(node.get('nodeClass'))) return false;
|
|
|
|
if (statuses.length && !statuses.includes(node.get('status'))) return false;
|
|
|
|
if (datacenters.length && !datacenters.includes(node.get('datacenter'))) return false;
|
2020-03-13 07:18:05 +00:00
|
|
|
if (volumes.length && !node.hostVolumes.find(volume => volumes.includes(volume.name)))
|
|
|
|
return false;
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
|
|
if (onlyIneligible && node.get('isEligible')) return false;
|
|
|
|
if (onlyDraining && !node.get('isDraining')) return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
),
|
|
|
|
|
|
|
|
listToSort: alias('filteredNodes'),
|
|
|
|
listToSearch: alias('listSorted'),
|
|
|
|
sortedNodes: alias('listSearched'),
|
|
|
|
|
|
|
|
isForbidden: alias('clientsController.isForbidden'),
|
|
|
|
|
|
|
|
setFacetQueryParam(queryParam, selection) {
|
|
|
|
this.set(queryParam, serialize(selection));
|
|
|
|
},
|
2019-02-12 04:01:46 +00:00
|
|
|
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
actions: {
|
|
|
|
gotoNode(node) {
|
|
|
|
this.transitionToRoute('clients.client', node);
|
|
|
|
},
|
2017-09-19 14:47:10 +00:00
|
|
|
},
|
UI: Fix client sorting (#6817)
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.
2019-12-12 19:06:54 +00:00
|
|
|
}
|
|
|
|
);
|