fix: show resource counts for all side navigation items (#1196)

* fix: show resource counts for all side navigation items The side navigation looks up the count of a nav item by its name, but the counts are keyed by the K8s resource type. Many Harvester nav items are named differently than the resource they list (e.g. harvesterhci.io.volume lists persistentvolumeclaim), so no count was shown for them. Some list views also show only a subset of their resource type, so the plain count would not match the list. Override the count getter of the harvester store: - Resolve the nav item to the resource type it lists, using the same fallback to the configureType resource as schemaFor. This fixes Hosts, Alertmanager Configs, Cluster Flows, Cluster Outputs, Flows, Outputs and Secrets. - Count only the subset shown by the list for Volumes, VM Networks, VM Backups, VM Snapshots, Volume Snapshots, Cloud Configuration Templates and Storage. The matches are counted per namespace once per store list using sharedComputed. - Like the list views, do not count resources in system namespaces when "All Namespaces" is selected. Steve's counts endpoint only returns the total per resource type, so the filtered counts are computed from the store list and are only available once that list is loaded. Until then these nav items show no count, unless there are no resources of that type at all (then 0). The dashboard loads PVCs and networks, the VM list PVCs and backups, the other resources are loaded when their list is opened. Related to: https://github.com/harvester/harvester/issues/11984 Signed-off-by: Volker Theile <vtheile@suse.com> * refactor: get the side navigation counts from the server Stop loading full resource lists and filtering them in the browser to get the side navigation counts. - Nav items listing all resources of a type use the counts endpoint, through the resource type of the nav item. - VM backups, VM snapshots, volume snapshots, storage classes, cloud config templates and VM networks request their subset from /v1/harvester with a page size of 1. These requests run again when the counts endpoint reports other numbers for the type, and when the namespace filter changes. - Namespaces count the already loaded namespaces that are neither system nor Fleet managed. - Volumes have no count: the list hides volumes that are only marked by annotations, which the API cannot filter on. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * refactor: keep the side navigation count helpers in the store getters Move them out of their own file, next to the count getter that uses them. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: make the side navigation count requests more robust - Ignore a late response of the previous cluster. Resetting the request ids when loading a cluster let it overwrite the count of the new one. - Keep the watchers when a cluster left while it was loading finishes loading after the new one. - Show no count instead of 0 on Harvester v1.3, which ignores the query and sends all resources without a count. - Hide the storage network by its generated name. Networks created before Harvester v1.4 do not have the hash label, and an upgrade does not add it. - Stop refreshing after leaving the product, cancel pending refreshes when the watchers stop, and cope with the store module being unregistered when logging out. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: count only the settings the Settings page shows The nav item showed the total of all Setting resources, but the page only shows the allowed ones that exist in the cluster and are supported by its version. Move these rules into a visibleSettings getter that both the page and the count use, so that they always agree. SettingList no longer needs its feature flag check. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * test: remove a Settings page test that was committed twice Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> * fix: show the number of volumes in the side navigation The Volumes list hides golden image volumes and the temporary volumes CDI uses to populate a volume, so the total of the counts endpoint would be wrong. Golden image volumes are only marked by an annotation, which Harvester's API cannot filter on, but each one belongs to a DataVolume owned by its VM image. So request the volumes that are not owned by another volume, and the DataVolumes owned by a VM image, and show the difference. Every nav item with a list now has a number, so remove NO_COUNT. Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> --------- Signed-off-by: Volker Theile <vtheile@suse.com> Signed-off-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> Co-authored-by: Marcelo Fukumoto <marcelo.fukumoto@suse.com> (cherry picked from commit 784c22e27e)
2026-11-15 13:26:15 +08:00 · 2026-11-10 11:21:10 +00:00
parent 3322162d9a
commit 2ddb696c75
10 changed files with 1170 additions and 47 deletions
@@ -0,0 +1,65 @@
+import { MANAGEMENT } from '@shell/config/types';
+import SettingsPage from '../harvesterhci.io.setting.vue';
+import { HCI } from '../../types';
+import { HCI_SETTING } from '../../config/settings';
+
+describe('list: harvesterhci.io.setting', () => {
+  async function fetchPage({ visibleSettings = [], isSingleProduct = false } = {}) {
+    const dispatch = jest.fn(() => Promise.resolve([]));
+    const page = {
+      initSettings: [],
+      $store:       {
+        dispatch,
+        getters: {
+          isSingleProduct,
+          currentProduct:              { inStore: 'harvester' },
+          'harvester/visibleSettings': visibleSettings,
+        }
+      }
+    };
+
+    await SettingsPage.fetch.call(page);
+
+    return { page, dispatch };
+  }
+
+  const visible = (id, config = {}) => ({
+    id, config, data: { id }
+  });
+
+  it('should list the visible settings sorted by name, a setting with an alias under its alias', async() => {
+    const { page } = await fetchPage({ visibleSettings: [visible('z-setting'), visible(HCI_SETTING.UI_PL, { alias: 'branding' })] });
+
+    expect(page.initSettings.map(({ id }) => id)).toStrictEqual(['branding', 'z-setting']);
+  });
+
+  it('should keep the config and the resource of a setting', async() => {
+    const { page } = await fetchPage({ visibleSettings: [visible('a-setting', { kind: 'json', canReset: true })] });
+
+    expect(page.initSettings[0]).toMatchObject({
+      id: 'a-setting', kind: 'json', canReset: true, data: { id: 'a-setting' }, hide: true, canHide: true, hasActions: true
+    });
+  });
+
+  it('should only allow actions on the server version when it is read only', async() => {
+    const { page } = await fetchPage({
+      visibleSettings: [
+        visible('a-setting', { readOnly: true }),
+        visible(HCI_SETTING.SERVER_VERSION, { readOnly: true }),
+      ]
+    });
+
+    expect(page.initSettings.map(({ hasActions }) => hasActions)).toStrictEqual([false, true]);
+  });
+
+  it('should load the settings of the management store only in a single product', async() => {
+    const { dispatch: multiCluster } = await fetchPage();
+    const { dispatch: singleProduct } = await fetchPage({ isSingleProduct: true });
+
+    expect(multiCluster.mock.calls).toStrictEqual([['harvester/findAll', { type: HCI.SETTING }]]);
+    expect(singleProduct.mock.calls).toStrictEqual([
+      ['harvester/findAll', { type: HCI.SETTING }],
+      ['management/findAll', { type: MANAGEMENT.SETTING }],
+    ]);
+  });
+});