Client Status Visibility Automation: A Tab Labeled "All" Was Not Showing All

A tabbed status filter built entirely in client-side code is a completely reasonable, common pattern — fetch a list once, then let a person switch between views of it instantly with no further network request needed. That pattern's entire correctness depends on one unstated assumption holding true: that the list being filtered client-side is actually the COMPLETE set the filter is meant to operate over. The moment the initial fetch itself applies a narrower scope than the filter UI implies — here, a service defaulting to active-only when no filter is explicitly requested — every one of the client-side filter's own tabs inherits that same narrowing silently, with nothing in the filter logic itself capable of detecting or correcting it, because from the filter's own point of view, it received a list and filtered it exactly as instructed.

Building a tabbed filter UI and writing the data-fetching call that feeds it are, in most codebases, two closely related but separately reasoned-about pieces of work — the filter logic operates entirely on whatever list it is handed, and the fetch call is written once, often before every tab's own exact requirements have been fully considered. A default choice made in the fetch call for entirely reasonable, unrelated reasons — returning only active records unless told otherwise, a sensible general-purpose default for most OTHER uses of the same service — can silently become the actual, binding constraint on what an "All" tab is capable of ever showing, without either piece of code containing anything that looks, on its own, like a mistake. The gap lives specifically in the unstated assumption connecting the two: that the fetch's own scope and the filter UI's own stated promises agree.

Centriu Maestro's client management screen structures its own status filtering as a common, standard pattern: a single data-loading function retrieves a list of clients, and four tabs — Active, Paused, Inactive, All — each apply their own filter to that SAME in-memory list, switching between views instantly with no additional request needed as a person clicks between tabs.

The data-loading function's own call to the underlying client-listing service, before this fix, passed no status filter at all. The service's own default behavior in that case — confirmed directly from its own existing implementation — is to return only clients with an active status, a default written for the service's own general-purpose use across the codebase, not written with this specific four-tab screen's own requirements in mind. Because every one of the four tabs filtered the SAME list the data-loading function returned, every tab inherited that same active-only scope automatically: Paused and Inactive searched a list that structurally could never contain a paused or inactive client, and All searched the identical active-only list, despite its own label implying the complete set.

The fix is a single, targeted change to the data-loading function's own call: it now explicitly requests `includeInactive: true`, an option the underlying client-listing service had already implemented and already supported, simply never invoked by this particular screen before. With that option passed, the service returns clients across every status, and the four tabs' own existing filtering logic — entirely unchanged — now operates on the actual, complete list its own labels always implied it was filtering. The fix was verified by exercising a full client lifecycle directly — create, edit, pause, reactivate — using a disposable test client specifically created for that purpose, and confirming live that the All tab genuinely shows every real client regardless of status, the Inactive tab correctly surfaces a deactivated client, and the reactivation control, previously unreachable for want of any way to find the client it needed to act on, now works end to end.

Before the fix, a check-in desk offering four different guest lists to browse — Currently Here, Left Early, No-Show, and Full Guest List — printed all four from a single master sheet that itself only ever recorded who was CURRENTLY still at the party, silently dropping anyone who had left. The sheet labeled "Full Guest List" was, in practice, identical to "Currently Here," because both were drawn from the same incomplete master record. After the fix, the master sheet itself records every invited guest regardless of whether they are still present, and all four lists finally show what their own labels always promised.

Centriu Maestro's client status tabs now filter a genuinely complete client list, closing a gap where a paused or deactivated client had been silently excluded from every tab, including the one explicitly labeled to show all of them.

This automation covers specifically how Centriu Maestro's client management screen fetches and filters clients by status. It is a distinct concern from this pillar's separate pages on Maestro's own campaign-level status handling — pausing, resuming, or a campaign being deleted directly on an ad platform — which operate on entirely different records and entirely different code paths.

Fetching once and filtering every tab client-side is an efficient, entirely reasonable pattern precisely because it avoids a separate network request per tab. Its correctness rests entirely on the single fetch actually retrieving the full range every tab claims to filter — an assumption worth explicitly confirming any time a filter option (like an "All" tab) implies a broader scope than whatever default the underlying data source happens to apply when asked for nothing in particular.