Documents & drawings

The document and drawing register in IssuesId is built on three principles: immutable revisions, withdraw-not-delete, and pins survive uploads. Together they give you a record that holds up when someone asks "what was actually issued on the 14th?"

Immutable revisions

When you upload a new version of a document, the old version isn't replaced — it's archived as a prior revision. Every revision keeps:

→The original file, byte-for-byte.
→The uploader, timestamp, and any revision notes.
→The list of distributions that referenced it.
→The pins (for drawings) that were placed against that revision.

You can scroll back through a document's full history at any time. Nothing is ever overwritten.

Withdraw, don't delete

If a document is no longer current — superseded, cancelled, or issued in error — you withdraw it. Withdrawing:

→Marks the document inactive (it disappears from default registers and search).
→Preserves the file and its full history for audit.
→Leaves prior distributions intact so the proof-of-receipt trail isn't broken.

There is no "delete" for issued documents. This is intentional — if you could delete a document, the audit trail couldn't be trusted. The withdraw-not-delete model is what makes the register defensible.

Drawings and pins

Drawings are documents with one extra trick: you can drop pins (and free-form Fabric.js markup) on them to flag defects, locations, RFIs, or inspections.

Pins and markup are tied to a specific drawing revision. That has two practical consequences:

→Looking at rev B later, you see exactly what was pinned on rev B at the time — the markup is preserved with the file it was drawn on.
→Uploading a new revision starts a fresh markup canvas on that revision. Existing pins stay on the prior revision; they don't auto-migrate to the new geometry (which is usually what you want, because the layout has likely shifted).

The underlying defects, RFIs, and inspections the pins represent are independent of any single revision — they live in their own registers and survive new uploads. The pin is the visual marker; the defect or RFI is the record.

Finding a drawing

Drawings have their own index, separate from the document register, because you look for a drawing differently — visually, by where it is on the job, or by what changed recently.

→Thumbnails, so you recognise a plan without opening it. Switch to a list view when you'd rather scan names and codes.
→Search by name or drawing code.
→Filter by location, several at once — the levels or buildings you care about today.
→Filter by when it was last revised — the last 7, 30, or 90 days. This is the one that answers "what's changed since I was last on site?"

Open a drawing's revision history and you get the full timeline, a side-by-side compare between revisions, and an upload-new-revision action. If a revision was uploaded in error, setting an earlier one back as current is possible but permission-gated — it changes what the whole project sees as the working drawing.

On a phone, the markup tools collapse into a dock at the bottom of the screen, so pinning a defect on a plan is a one-thumb job rather than a pinch-and-hope.

The register

The register is the searchable, filterable list of every document and drawing on a project:

→Filter by status (current / withdrawn / superseded), type, revision, or discipline.
→Sort by upload date, name, or revision date.
→Bulk download a current revision set as a single zip.
→Cross-tenant search is disabled by design — you only see documents from projects you're a member of.

Who sees what

Being on a project doesn't mean seeing the whole register. Document visibility is decided by two independent things: which tier of the register you belong to, and whether your role has been allowed the document's category.

The two tiers

Documents either sit at project level — the register everyone working on the job shares — or they're attached to a specific location, which in practice means a unit.

→Staff (Company Admin, Manager, User) see both tiers. Nothing here narrows them.
→Building Manager sees the project tier and common-area locations. Unit-level documents appear only if they've been given apartment access on that project, which is off by default and set per person.
→Trade sees the project tier only — never a unit's documents. A subcontractor has no business inside a resident's folder.
→Tenant sees the opposite slice: the documents attached to their own location, and nothing at the project level. This is deliberate, and it's what makes the hierarchy nest properly — an owners corporation's set contains a resident's set, not the other way around.
→Client has no document access at all.

An external role also has to be bound to the project before any of this applies. A tenant or trade login can't reach a register on a project they've never been attached to, and the failure is a plain not-found rather than a message confirming the document exists.

Category restrictions

On top of the tier, an organisation can restrict a category to an explicit list of roles. Once a category has any restriction set, only the named roles can open documents in it, and everyone else gets a refusal — categories are the lever for "contracts are for staff, not for trades on site."

Categories with no restriction set behave as they always have: visible to anyone whose tier already reaches the document.

Both rules apply to search and downloads too, not just the register listing. A document you can't see isn't findable by name, and its download link won't resolve for you.

Versioning by revision letter or number

Each revision has two fields: an ordinal (auto-incrementing integer used internally) and a label that's free text. The label is what users see and what appears in registers and distributions, so use whatever convention your organisation already follows:

→A, B, C… for design-style versioning.
→00, 01, 02… for engineering-style versioning.
→2025-04-12 for date-stamped revisions.

Pick one convention and stick with it across a project — mixing styles inside the same register gets confusing fast.

Upload, sign-off, distribute

The typical drawing flow:

01Upload a new revision with a short note ("Updated stair geometry per RFI 14").
02Mark superseded any prior revision the new one replaces.
03Distribute to the recipients who need to know (with acknowledgement required for contract documents).
04Track acknowledgements from the distributions panel.

The distribution carries the revision number forward, so even if you upload rev D tomorrow, the recipients of rev C have a record of what they actually got.