Projects

A project in IssuesId is the container for everything on a single build — defects, inspections, work orders, RFIs, documents, drawings, distributions, and the team. Most of the platform's per-tenant data is project-scoped, so getting a project set up well at the start saves time everywhere downstream.

Project fields

Each project carries:

→Name (required) and description.
→Address — captured as both a free-form address field and structured fields (addressLine1, addressLine2, suburb, state, postcode, country) so reports and exports format cleanly.
→Project type — picked from the organisation's configured project types (apartments, commercial fit-out, civil, etc.). Use this to group projects in reports and dashboards.
→Start date and practical completion date — used by schedule reports and the defect-liability window.
→Defect liability days — defaults to 90. Defines the warranty window after PC.
→Manager and contact name + email — primary points of contact, separate from project membership.
→Total dwellings — for residential projects, used by per-unit reports.
→Post-construction management — flag for projects continuing into a managed defect-liability period after PC.

Project membership

Project membership is separate from organisation membership. A user can be in your org but not on a specific project — and that's how the platform keeps scope clean:

→Add a user to a project to grant them visibility and the role-appropriate actions on that project.
→Remove them when they roll off — historical records they touched (their captures, transitions, sign-offs) stay attributed to them.
→Some roles (notably Tenant and Client) only ever see the projects they're explicitly added to.

The search and reports surfaces both honour project membership: you don't see documents, users, or records from projects you're not a member of.

Per-project workflow rules

Each project carries its own workflow rules as JSON on the project record. This means:

→A high-rise residential project can have different escalation timings than a small commercial fit-out.
→Cloning a project's rules to a new project is straightforward.
→Workflow rule changes are scoped — you can adjust escalation on one project without affecting others.

Notification emails

A project has a notification email list — a free-form array of email addresses that receive project-level notifications (typically off-platform stakeholders like a consultant, principal contractor, or owner's rep). These addresses don't have user accounts; they just get the notification.

Per-project category exclusions

The defect category taxonomy is org-wide, but not every category is relevant on every project. Each project can exclude specific categories — they disappear from the picker for that project's team without affecting other projects in the same organisation.

Exclusions are additive on top of the org-wide list: a category that's active at the org level can be turned off per-project, but you can't add a project-only category that isn't in the org taxonomy. Edit the org taxonomy if a category is needed somewhere it's not yet listed.

Client visibility setting

Projects have a client_defect_visibility setting that controls what users with the Client role see:

→`all` (default) — clients see every defect on the project. Matches the original behaviour.
→`fixed_only` — clients see only defects whose status is fixed or closed. Useful when you want the client to see progress without seeing every raw open issue.

The setting is applied at the API layer — you can't bypass it by hitting a different endpoint.

Soft delete (archive)

Projects aren't hard-deleted. Setting a project inactive removes it from default lists, but every defect, inspection, document, and audit record on it stays in the database. This keeps reports from prior periods accurate and preserves the audit trail.