fix(provisioning_api): filter users by enabled state on the server

[SebastianKrupinski]

Summary

• Resolves: [Bug]: Active Account List Break if 1/3 of Total Accounts are Disabled #47114

• Resolves: Client Ticket

• The account list in settings fetched pages that included disabled accounts and hid them in the browser. Loading the next page is only triggered when the list footer becomes visible, so when most accounts on a page were disabled the footer never left the viewport and the "Active accounts", group and "Recent accounts" views stopped loading.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[SebastianKrupinski]

/backport to stable35

[SebastianKrupinski]

/backport to stable34

[SebastianKrupinski]

/backport to stable33

[SebastianKrupinski]

/backport to stable32

[SebastianKrupinski]

/compile

[pringelmann]

I'm honestly not sure this should be fixed in the client. The server builds full details for every disabled user just so we can hide them, and the loop multiplies that. Most of the inline issues also go away without a client-side loop.

Maybe we could add an opt-in enabled=true param to /cloud/users/details instead? The server skips disabled users until it has a full page and returns the next offset in the Link header.

[SebastianKrupinski]

Maybe we could add an opt-in enabled=true param to /cloud/users/details instead? The server skips disabled users until it has a full page and returns the next offset in the Link header.

Sure, I was just going for the smallest fix, but the backend fix is better

[pringelmann]

I think this might skip users when there's more than one user backend (e.g. LDAP + Database), since search() pages each backend separately but the offset here counts the merged result. Could you double check?

[pringelmann]

Thank you for the extra effort to improve this by moving it to the server! Just one comment on limit/offset handling on multiple backends...but otherwise looks good :)