There are several places in the UI where this comes up, but I’ll deal with the users list for right now. There are a few problems with the way the list behaves:
First, the default of chunking by ten items is just too small–default to at least 20, and let it scroll; we all have scroll bars.
But the bigger issue (and IMO a bug) is that, while I can set it to a higher value (25, 50, or 100), that setting doesn’t persist. Like, at all. I can go to the users list, set it to 25 items/page, edit a user, and when it returns, it will be back to 10 items/page. The same is true in the HTTP routes list and of the TLS certificates list. I suspect it’s true of every place where there’s a list, but I don’t have more than 10 software repositories.
And as a tangentially-related issue, why is the same list widget used for the core applications? Can there ever be more than ten of them? If not, why use a list widget that offers pagination at 10, 25, 50, or 100 items?
At a bare minimum, my chunking setting should persist while I’m still working in the same list. I’d argue it should persist at least throughout the login session. And really, it’d be best to let the user specify a value that would persist permanently.
I’m seeing this currently under core 3.22.0, though I’d be surprised if the issue is unique to that version.
@andre8244 tagging you since you wrote most of NsDataTable.vue — curious for your take before we open a PR or do nothing.
Forum report: page size resets to default whenever the table remounts (e.g. edit a row, come back to the list). Confirmed in code: pageLength/pageNumber live only in NsDataTable’s local data(), no persistence anywhere in ns8-ui-lib or in ns8-core’s consumers (DomainUsers.vue, HttpRoutesPanel.vue, TlsCertificatesPanel.vue).
Proposed fix: add an optional storageKey prop to NsDataTable. If set, read the saved page size from localStorage on created() and write it back in paginateTable(). No prop → current behavior unchanged, so it stays backward compatible for other NS8 apps embedding the component. Consumers in ns8-core would then pass a unique key per list ("users", "http-routes", "tls-certificates", etc).
Does that approach look right to you, or is there a reason state was kept local that I’m missing?
keeping the initial view to 10 rows per page is intentional from a general UX design perspective: it keeps the initial screen footprint compact and avoids forcing excessive scrolling on lower-resolution displays or smaller viewports.
We are aware of this limitation and have already implemented persistent table states in newer products, but this particular request has only come up once or twice over the years for NS8.
For improving this behavior I see two approaches we could consider:
saving the selected page size preference individually for each table in localStorage (as Steph suggested)
saving a single page size global preference in localStorage that is shared across all NS8 tables.
Both solutions require careful evaluation. The second approach should require fewer code changes, but because it introduces a centralized change affecting every table across NS8, it carries a higher risk of introducing regressions that would need thorough testing.
Also, since both options use localStorage, your page size preference is saved only in the browser you’re using and won’t work on another browser or device.
You’re going to scroll no matter what. These tables are on the bottom of the page, and so is the selection for # of, it doesn’t matter if you have 5 users or 100, you’re going to scroll. That’s a lot less painful than clicking or tapping through and precision aiming for the 25 every single time you go back to one of these pages.
@stephdl Why another thread? User list or detections list, it’s exactly the same pain point. 9 out of 10 times I’m looking at an ip in detections and I get 12 returns on my search/filter, so I have to scroll to the bottom to get to the selection for 25 and then scroll some more and scroll some more, I mean scrolling is the human condition, yes?!?!? With Unifi you get 100, personally I’m fine with that.
I’ll say another thing, maybe this is another thread, but if this is a pain point, let me tell you about torture.
The logs results field.
You get into the field and start scrolling, scroll hits the bottom, you scroll back up looking at whatever, the whole page scrolls up, you lose sight of the results field, now you have to scroll the page to get the result field back in view, then you’re scrolling the results field till you unintentionally hit the top again and there goes the field, so you scroll the page again to get the field back, rinse and repeat, rinse and repeat.
How often are either of those considerations present when administering a NS8 box? I certainly could be wrong (because I have nothing to go on but my gut feeling), but I doubt this is really that common of a thing.
And by keeping the footprint compact, you’re making the user jump from page to page to page, which is considerably more disruptive than having to scroll IMO. And that doesn’t even get to the fact that you use the same list widget, with chunking and pagination (and searching), on lists where it really doesn’t make any sense at all (like for the two images an app contains).
But all of this would be alleviated, significantly if not completely, if you’d make the chunking setting persistent.
FWIW, I don’t agree when it comes to the Crowdsec logs–it’s all the same list code (at least as far as I can see as a user). The system log viewer probably is a different issue, but Crowdsec uses the same list widget as everything else that’s been mentioned here.
With Unifi you get 100, personally I’m fine with that.