[blicknix]

I'd like to contribute an admin extension, "Space report". It shows:

• counts of personal, project and Vault spaces
• total used and assigned quota, spaces near or over quota, top lists
• orphaned spaces: personal spaces whose owner no longer exists in the user backend, and projects without (live) members

Reports can be exported as PDF, Markdown and CSV, or saved to the admin's personal space. It uses only existing Graph endpoints (/graph/v1beta1/drives, /graph/v1.0/users, /graph/v1.0/groups) and needs no server changes.

New dependencies: jspdf (MIT) and jspdf-autotable (MIT) generate the PDF in the browser. The bundle grows to about 460 kB (150 kB gzip). It is a single file, because Web loads extensions via requirejs. The alternative would be dropping PDF and keeping only Markdown, CSV and browser print. Is adding these OK?
#606

Note for oCIS: GET /graph/v1.0/users and /groups are read without paging. With an LDAP size limit the lists come back truncated without any indication. The extension works around this by confirming every missing ID with GET /users/{id}. Proper paging or a truncation flag in Graph would help other admin tools too.

Implementation is ready (lint, types, unit and e2e tests pass); happy to open the PR once the dependency question is settled.

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[blicknix]

@LukasHirt Could you have a look and give some feedback on this?

[LukasHirt]

Thank you @blicknix looks like a great and useful extension! Before I dive deeper into the review, I'd like to address two topics first.

1. New dependencies

A few quick notes:

• the size is a bit heavy but I would not consider this specifically as a blocker since it's accessible only by admins.
• seems like the used jspdf version is having some CVEs, though it looks like they wouldn't be exploitable in our env, it would still get marked by scanners - if they would stay, I would see it as requirement to use the latest major version (but still, it seems that the lib is having CVEs quite often…)
• lockfile is not updated
• covering only Latin-1 via pdfSafe feels rather limiting and report for specific languages would feel very broken and embedding fonts that would fix it would grow the size even more

I would personally suggest to omit these dependencies for the first version. However, I am open to discussing this in case there is a specific reasoning/use case behind it.

2. Custom code to call APIs

Is there any specific reason for not using web-client to call the APIs? I would strongly advise on using it. If there is something that prevents it (lack of specific functionality or bug) I would propose to have that first solved and then use it in this PR.

[blicknix]

good points.

I will remove the pdf dependencies and just make it markdown. PDF can then be handled through the browser via printing. The reason was to be able to share the report within ocis as a pdf and save an extra step to do so.

The own API calls where created to be able to make a report for all storage providers. I think the use case is 99% only for non vault spaces anyway, so I will change that for easier maintainability.