Skip to main content
Every document has an owner. Object ACLs can grant another user or group view, change, or delete access without granting administrator privileges.

​
Access model

For an authenticated object request, Suchi first loads the actual object and requires its system to match any explicit request system and the token’s bound system. The account must be active and may enter the system only through direct membership or implicit instance-administrator access. Then:
  1. Instance administrators bypass document ACLs.
  2. The object owner is allowed.
  3. User and group grants are combined; the effective bits must include the requested permission.
  4. Otherwise access is denied.
Admins never bypass the explicit/token system boundary or authorize nonexistent objects. Membership alone grants no document ACL; ownership, a group/direct grant, or approval assignment alone grants no system entry. An S01 member with a retained S02 grant after losing S02 membership still cannot read that document. A partner admitted to both systems still needs ordinary document permission. Anonymous callers have no object access except through a valid share link. Grants add access within these boundaries; they cannot override them.

​
System membership and trust

First prefixed taxonomy import introduces systems atomically. Before it, the original archive is hidden and ordinary new users/admin demotions are admitted there automatically. Naming it retains those memberships. Afterwards new systems admit only instance admins until granted direct members; new users and demoted admins receive no automatic memberships. Codes are permanent, names editable. Admins manage memberships after introduction. Removing membership atomically revokes that user’s system shares and API tokens and removes pending mobile pairings. Pending Microsoft sign-ins for that system are discarded only after the membership change commits; failed changes preserve them. Re-adding membership never resurrects those credentials or sign-ins. Document ACL rows remain ineffective while membership is absent; re-admission can make those retained grants useful again, subject to the other authorization checks. Writes and idempotent receipt replay recheck current account, membership and local token authority in the writer transaction. Read authorization is a snapshot: removal cannot retract bytes already delivered. Shared server admins, host and backup operators remain trusted; these are not separate databases, encryption keys or a regulatory/professional-independence guarantee. object_acls supports document, tag, correspondent, document_type, and storage_path. Principals are users or groups. Reapplying a grant replaces its permission bits.

​
Enforcement

Document detail, download, preview, versions, correspondents, custom fields, mutation, trash, and restore endpoints enforce object permissions. Document lists, FTS search, saved views, statistics, and similar-document retrieval put visibility restrictions inside their database queries so hidden rows do not leak through counts, snippets, or pagination. Taxonomy mutation endpoints enforce grants on existing taxonomy objects. Taxonomy names are shared vocabulary only within an enterable selected system. Lists and autocomplete do not hide those same-system labels by object ACL, but never reveal another system’s vocabulary. API tokens are bound to one system as both default and ceiling. Scopes and object permissions are additional gates, not substitutes for membership. Change a device’s system by creating a new pairing/token, not by switching an old token. Mobile Reader calls require documents:read on document lists, search, document detail, version lists, thumbnails, and task reads. The scope check runs before object ACL and sensitivity checks; it never broadens row visibility. Mobile pairing should require both documents:read and documents:write. Upload idempotency keys are user-global and their fingerprints bind the target system: reusing a key in another system conflicts. Every replay rechecks authority; a version replay also requires change permission on its predecessor.

​
Account safeguards

Under Settings > Archive configuration > People and metadata > Users, you cannot disable the account you are signed in with. Its Active switch is read-only. To disable that account, sign in as another active administrator. User updates must leave at least one active administrator. Disabled administrators do not count; promote or enable another administrator before demoting the last active one. The API enforces this inside the write transaction, including when administrators make concurrent changes. Rejected updates leave all fields unchanged.

​
Capabilities

Administrators grant optional capabilities to individual members under Settings > Archive configuration > People and metadata > Users > Additional access. Administrators have every capability implicitly. User creation and updates store administrators with an empty member-capability list. Promotion preserves their implicit access and does not revoke dependent resources. When demoting an administrator, explicitly grant the member capabilities they should retain; omitted capabilities do not restore legacy hidden grants. Normal revocation cascades apply to the access they lose. The web app labels these capabilities Ask the archive, Manage document dates, Manage mailboxes, Create share links, and Share saved views. Removing archive_chat removes the Ask action; its conversations are already transient browser memory and create no server-side records. Removing a capability also closes the access it granted:
  • Removing archive_intelligence hides extraction, extracted-fact review, and Calendar. Existing pending facts and dates already in Calendar remain stored and auditable. Dates already available to Calendar remain readable document metadata: callers with documents:read may still use date: and date-role: predicates.
  • Removing mailboxes disables the member’s mailbox rows without deleting them. Granting it again does not re-enable those rows automatically.
  • Removing share_links revokes the member’s live share links. Granting it again permits new links but does not restore revoked links.
  • Removing share_views makes the member’s shared views private. The saved views remain available to their owner.
The database revocations and account change succeed or fail together. A concurrent promotion or regrant cannot cause an older revocation to remove resources created after access was restored. Successfully stored capability audit records follow committed transition order. Audit persistence remains best-effort; failed writes are logged without rejecting account updates. Rejected disables do not discard pending Microsoft sign-ins.

​
Groups

Administrators manage users and groups under Settings > Archive configuration > People and metadata. Group membership makes one grant apply to several users. The equivalent API surface is:
A group with active grants cannot be deleted. Revoke those grants first so access does not disappear accidentally.

​
ACL API

ACL management is currently exposed through the JSON API:
ACL routes require an authenticated browser or OIDC session. New user grants check in the caller’s write transaction that the recipient is active and can enter the object’s system (member or administrator); a new grant to a nonmember is rejected, not stored as an access workaround. Assuming user 5 meets that requirement, an administrator can grant view and change access to document 17 with:
Use principal_kind: "group" and a group ID for a group grant. The API is idempotent: an identical PUT is a no-op and deleting a missing grant succeeds. Share links are time-bounded anonymous bearer access, not ACL entries. They are useful for sending selected documents to someone who has no Suchi account. Revoking a share link does not change user or group grants. A share contains documents from exactly one system and remains subject to the creator being active and able to enter it. Public requests return only still- shareable live documents. Revocation, removal of membership, or loss of the creator’s authority cannot be bypassed using the bearer link. Automations can change ownership but v0.1 does not include a general ACL-grant automation action. Approval definitions are governed by their own task and assignee rules rather than object ACLs.

​
Multi-user setup

  1. Create users under Settings > Archive configuration > People and metadata > Users or through /api/admin/users.
  2. After systems are introduced, grant direct membership in each required system. Administrators’ entry is implicit; no per-system administrator roles exist.
  3. Create groups for recurring document-sharing needs, then grant document ACLs. Users, groups, roles and capabilities are instance-wide, not new tenant directories.
  4. Verify system entry as well as list, search, preview, edit and delete as a member.
Within an enterable system, an object without ACL grants remains visible only to its owner and administrators. See Architecture for authorization invariants and API for complete payloads.