Automatic system policies
When you create a supported resource, TaruviBase attempts to synchronize a policy for it that you can edit in the Console. Anything the policy doesn't allow is denied. Behind it, an unscoped policy has no-allow rules, so it denies by default. Only the scoped policy is visible in the Console.
The scoped policy starts with safe defaults for all roles, and Storage uses category-specific defaults. Each new policy still needs immediate least-privilege review: grant the other actions each role needs, and no more.
| Product | Resource | Initial scoped access |
|---|---|---|
| Database | Non-system DataTables | read for all roles. create, update, and delete aren't granted until you add them. |
| Functions | App and proxy Functions | execute for all roles. |
| Analytics | Saved queries | execute for all roles. |
| Storage | Assets buckets | read for all roles. |
| Storage | Attachments buckets | read, create, and update for all roles; Super Admin receives wildcard full access. |
The precise action inventory is in System resource actions. System DataTables skip policy synchronization because they follow separate platform controls.
Synchronization is not the resource transaction#
Resource creation can succeed while policy synchronization fails. The creation paths do not roll back the resource or return the synchronization failure to the Console or API caller, so check the policy yourself after creating a resource.
After creating a resource that gets an automatic policy:
- Open Policy Editor and confirm that the expected scoped system policy is present and enabled. The Console exposes only this scoped policy.
- Add the actions each role needs, and remove any it shouldn't have, before assigning users or releasing the resource.
- Open Live Testing and run one expected-allow and one expected-deny check.
If the policy is missing, stop the rollout and contact TaruviBase support with the site, app, and resource names so it can be resynchronized. Never create a duplicate custom system policy as a substitute: two independently maintained policies make it unclear which rules apply.
Updates and cleanup#
System policies are edited, not recreated as custom policies. Review the full replacement definition before every save, then repeat both Live Testing checks.
Resource deletion and policy cleanup are separate steps, and their order varies:
- Functions and Storage run policy cleanup first, then resource deletion. A cleanup failure is suppressed and deletion continues, leaving an orphan policy. If cleanup succeeds but the deletion fails, it leaves a surviving resource without its policy.
- Database and Analytics run resource deletion first, then policy cleanup. A cleanup failure can leave an orphan policy after its resource is gone.
If a resource and its policy get out of step, contact TaruviBase support to reconcile them. Don't create a duplicate policy or re-create the resource to hide the mismatch. See Troubleshooting access policies for what to collect.