Scheduled reports and the weekly digest

An administrator picks sections, a schedule (daily, weekly or monthly,
at a time in a time zone) and recipients, who must be accounts on this
server. Every node looks for due reports once a minute; a run is claimed
with the task lock, keyed by report and due time, and recorded on the
report, so it goes once. The report is built from what the server
already keeps: mail flow, the queue, spoofing from received DMARC
reports, TLS failures, deliverability findings and what changed since
the last run, security counters, people near their quota, and expiring
certificates. It is mailed as text and HTML with optional CSV
attachments, DKIM-signed; a sender domain without a key fails the run
with that reason instead of sending unsigned.

The weekly digest is a built-in report on every server, on by default:
every section, Mondays 07:00 UTC, to the system administrators. It can
be changed or turned off, not deleted. A tenant administrator makes and
sees only their own tenant's reports, which leave out server-wide
sections.

New: inbuxa:ScheduledReport and inbuxa:ScheduledReportSettings, the
sysScheduledReportGet and sysScheduledReportUpdate permissions (granted
once to existing administrator roles), privacy catalog entries, and a
system test. Spec: inbuxa-drafts specs/scheduled-reports.md.

crates/common/src/auth/permissions.rs

@@ -317,6 +317,12 @@ impl Default for DefaultPermissions {
                 Permission::SysDeliverabilityUpdate | Permission::SysDeliverabilityCheck => {
                     default.superuser.push(permission);
                 }
+                // inbuxa: scheduled-reports spec, RP-22: a tenant administrator
+                // makes reports for their own tenant, which the server limits
+                Permission::SysScheduledReportGet | Permission::SysScheduledReportUpdate => {
+                    default.superuser.push(permission);
+                    default.tenant.push(permission);
+                }
                 // inbuxa: DLP and mail flow rules, and held mail, are the
                 // server's: never a tenant's (dlp-and-mail-flow-rules spec,
                 // settled answer 3)

crates/common/src/manager/granted_permissions.rs

@@ -32,8 +32,8 @@ use types::id::Id;
 /// (ai-explain spec, EX-4: superuser by default), the audit log, account
 /// locks and legal holds (audit-hold-lock spec, AU-9, AL-12, LH-13), and
 /// the data inventory (personal-data catalog spec), accepting security
-/// to-do items (security to-do list spec), and the deliverability check
-/// (deliverability spec).
+/// to-do items (security to-do list spec), the deliverability check
+/// (deliverability spec), and scheduled reports (scheduled-reports spec).
 const ADMIN_GRANTS: &[Permission] = &[
     Permission::SysAiExplain,
     Permission::SysAuditGet,
@@ -60,6 +60,8 @@ const ADMIN_GRANTS: &[Permission] = &[
     Permission::SysDeliverabilityGet,
     Permission::SysDeliverabilityUpdate,
     Permission::SysDeliverabilityCheck,
+    Permission::SysScheduledReportGet,
+    Permission::SysScheduledReportUpdate,
 ];
 
 /// Granted to the server-level Compliance Officer role once it exists:
@@ -77,8 +79,8 @@ const OFFICER_GRANTS: &[Permission] = &[
 
 /// Granted to the default tenant administrator roles: reading and exporting
 /// the tenant's audit log (AU-9), locking and delegating its accounts
-/// (AL-12), the tenant's slice of the data inventory, and its own domains'
-/// deliverability findings (DL-20).
+/// (AL-12), the tenant's slice of the data inventory, its own domains'
+/// deliverability findings (DL-20), and its own scheduled reports (RP-22).
 const TENANT_GRANTS: &[Permission] = &[
     Permission::SysAuditGet,
     Permission::SysAuditExport,
@@ -88,6 +90,8 @@ const TENANT_GRANTS: &[Permission] = &[
     Permission::SysAccountLockDestroy,
     Permission::SysComplianceGet,
     Permission::SysDeliverabilityGet,
+    Permission::SysScheduledReportGet,
+    Permission::SysScheduledReportUpdate,
 ];
 
 #[derive(Clone, Copy, PartialEq, Eq)]