Storage, profile pictures, quotas, and deletion windows

Working example: core_workspace_features.py includes account profile, storage provider, storage connection, test, and usage SDK call builders.

Oruoma now treats workspace storage as a managed workspace resource with clear user-facing safety rules. Workspace owners can see usage, understand quota pressure, upload account profile pictures, and recover from deletion mistakes during the waiting window.

What workspace storage is used for

Workspace storage holds files and media created by workspace features, including account profile pictures and other uploaded workspace objects. Oruoma also keeps workspace database usage separate from object storage so owners can understand where capacity is being used.

Storage usage is reported in three layers:

Layer	What it means
Object storage	Bytes used by files and objects inside workspace storage connections.
Database storage	Estimated bytes used by the workspace database.
Aggregate storage	Object storage plus database storage for the workspace.

Use the storage usage dashboard when deciding whether to clean up data, upgrade capacity, or investigate unexpected growth.

Default system storage

Every workspace has protected default storage used by Oruoma system features. For example, account media such as profile pictures should have a safe default place to live without requiring a workspace owner to manually create storage first.

Default system storage is intentionally different from normal custom storage:

It is hidden from normal day-to-day storage lists to avoid clutter.
It can appear in owner/admin diagnostics when needed.
It cannot be disabled or deleted from normal workspace admin flows.
It should not expose private provider configuration or secret values.

This keeps core workspace features working while still giving owners enough visibility to diagnose usage.

Account profile pictures

Workspace account profile pictures are stored through workspace storage rather than as loose external URLs. This gives Oruoma a consistent permission, audit, and cleanup model.

Expected behavior:

Owners/admins can upload or remove profile pictures from account settings.
Uploads are validated for image type and size before storage.
The dashboard shows the updated image after save.
Retrieval uses Oruoma URLs instead of exposing raw storage internals.
Cache behavior is designed so users see updates without leaking private storage details.

If an upload fails, check the file type, file size, account permissions, and whether the workspace has a healthy default account-media storage connection.

Storage metrics and quota alerts

The storage dashboard shows usage cards and per-storage breakdowns. Owners can refresh/recalculate usage when they need a current view.

Common states:

State	What to do
Normal usage	No action required. Keep an eye on trend over time.
Warning threshold reached	Review large storage connections and database growth. Plan cleanup or upgrade.
Limit reached	New writes may be rejected until usage falls below the limit or capacity is raised.

Quota enforcement happens at write boundaries, such as uploads or creation flows that increase measured storage. The goal is boring predictability: fail clearly before data growth becomes expensive or unbounded.

Deleting custom storage

Custom storage deletion is intentionally a staged process. Oruoma favors recoverability over instant destruction because humans occasionally click the big red button and then remember why civilization invented undo.

Deletion flow for non-default storage:

The owner/admin starts a delete request.
Oruoma requires the exact confirmation phrase and, when policy requires it, MFA confirmation.
The storage connection moves into a pending deletion/trash state.
The UI shows recovery details such as status, reason, attempts, remaining time, and permanent-after time.
During the waiting window, the deletion can be cancelled.
After the waiting window, permanent cleanup can remove the storage record and managed local data where applicable.

Default system storage is protected and cannot be deleted through this flow.

Workspace deletion windows and reminders

Workspace deletion is more serious than deleting one storage connection. The workspace deletion flow is owner/control-account scoped and uses a longer waiting period.

Expected user-facing behavior:

Workspace deletion requires strong confirmation and MFA when required by policy.
Pending-deletion workspaces are hidden from normal workspace lists.
Normal workspace switching/access is blocked while deletion is pending.
The requesting owner/control account can still see the recovery state and cancel within the waiting window.
The recovery UI previews reminders and shows the permanent deletion timing.
Oruoma sends a limited number of deletion reminders, with remaining time shown at whole-hour precision.
Cancelling deletion stops future reminders for that deletion request.

The product rule is simple: destructive workspace actions must be visible, reversible during the waiting window, and hard to trigger by accident.

Troubleshooting

Symptom	Likely cause	Fix
Profile picture upload fails	Unsupported file, too large, missing permission, or unhealthy account-media storage	Try a smaller supported image and ask an owner/admin to check storage diagnostics.
Storage usage looks stale	Metrics cache has not been refreshed	Use the dashboard refresh/recalculate action.
Custom storage cannot be deleted	It may be protected system storage or the caller lacks permission/MFA	Confirm it is non-default storage and complete the required confirmation flow.
Pending deletion cannot be cancelled	Waiting window expired or caller lacks owner/control visibility	Escalate to an owner with the workspace deletion recovery view.
New uploads fail with quota errors	Object, database, or aggregate storage limit is reached	Clean up data, cancel unnecessary deletion-pending resources only if still needed, or increase capacity.