Sharing

Shares

Create public links for files and supported records, control access, and review incoming submissions.

Shares

Shares create public links for files and supported records. Use them when someone needs to view data, propose changes, upload files, or submit new information without a normal account.

Where shares are used

  • Open Shares to review all links for the current workspace.
  • Create shares from feature entry points such as Files, Buildings, Equipment, and Tools.
  • The module depends on the shares capability. Feature visibility and sidebar setup are managed in System Settings.

Share model

  • A share belongs to one workspace and one target collection such as files, buildings, equipment, tools, or organizations.
  • Each share stores a permission (read, edit, or create), optional title and message, expiry, revocation state, password hash, personal-details requirement, max uses, and current use count.
  • read and edit shares point to linked records in shareItems.
  • create shares do not require existing items. They open a public form for the target collection.
  • Public interactions are recorded in shareAccessLogs and shareSubmissions.
  • Edit submissions also create entries in the Versions system.

Permission modes

Read

  • Recipients can open the public page and view allowed fields.
  • The page only exposes fields marked as public in the backend field definitions.
  • Read shares do not accept submissions.
  • Opening a public share sends the owner a view notification, throttled to at most once per share per day.

Edit

  • Recipients see a public form prefilled from the shared item.
  • A submission creates a shareSubmission and a pending version for internal review.
  • The share creator receives notifications about the submission and the new version.

Create

  • Recipients see an empty public form for the target collection.
  • For non-file collections, the current implementation stores the submission for internal review. It does not create the final record immediately on first submit.
  • For the files collection, create behaves as an upload share. Uploaded files are inserted into Files with pendingReview and a reference back to the share.

Public access flow

  1. A recipient opens /s/:shareId.
  2. If the share has a password, they must unlock it first.
  3. If personal details are required, they must submit name and email. Company is optional.
  4. The public page then renders one of three experiences:
    • read: a read-only detail view
    • edit: a prefilled form for proposed changes
    • create: a blank form, or an upload zone for file shares
  5. Successful views and submissions increment the share use count. Views can also notify the share owner, while submissions use their own submission and version notifications.

Field visibility and form scope

  • Public visibility is controlled per field in the backend schema metadata, not ad hoc in the UI.
  • Fields marked never are blocked from public view and public submission.
  • Fields marked opt-in can be exposed only when the share creator enables them in the share dialog.
  • The opt-in field picker is available for edit and create shares.
  • Relation inputs in public forms use share-scoped option queries, so recipients only see the minimal labels needed for the form.

Manage shares

  • The Shares list shows title, collection, permission, item count, uses, status, created date, and expiry.
  • From the row actions you can copy the public URL, edit the share, revoke it, or delete it.
  • Revoking a share sets revokedAt and archives the link.
  • Deleting a share removes the share itself plus related items, submissions, and access logs.
  • Editing from the standard dialog updates metadata and security settings. It does not currently replace the linked items.

Current behavior to know

  • File shares are the main multi-item share flow. They render all linked files with download or upload behavior.
  • Non-file shares can technically store multiple linked items, but the current public viewer resolves the first linked item for read and edit flows.
  • maxUses is not a unique-visitor counter. It increments on successful public views and again on successful submissions or uploads.
  • Passwords are stored hashed. Public share endpoints are rate-limited.
  • Share access logs exist in the backend for audit purposes, but the standard shares list currently shows summary status and usage instead of a dedicated full log viewer.