- Shipped
- August 9, 2026 at 4:40 AM UTC
- Author
- Kamo
- Commit
- 1037589
Nothing has ever summed storage per organization. Six entities carry a byte count per file, and no code aggregated any of them, which is why the account stats tab renders "No usage data available for this period" for every org. Adds the shared model that aggregation needs: - StorageDomain — the five org-attributable storage areas, each declaring whether its removed records survive. Documents and KB media soft-delete, so a lifetime total is a straight query; mailboxes, recordings and disclosures hard-delete, so theirs can only accumulate forward. - OrgStorageSnapshot — one row per (org, day, domain). It exists for three figures that are unrecoverable after the fact: lifetime totals for the hard-deleting domains, the opening position that period removals are differenced against (no table timestamps a deactivation — EmbRecordState's DATE_UPDATED is insertable=false and never refreshes), and a period-close number fixed when the period ended. - OrgStorageAggregator — every per-domain aggregate in one class. Totals are summed over records, never over stored objects: img_dats keeps one physical copy per hash however many orgs hold that file, and that saving is Kamo's. The aggregator deliberately carries no stereotype. Every service runs @ComponentScan("com.kamo"), so annotating it would construct it in all ~40 of them; BillingService declares the bean. Also adds the search-index queries the email size backfill needs — size_bytes was written as a hardcoded 0 since the index was created, so mailbox storage reads as zero bytes platform-wide until those rows are repaired. Schema verified in production before this landed: org_storage_snapshots exists with all 16 columns after a KamoInitializer run.