ParcelDraft Workflow

Use ParcelDraft workflow for all ordinary parcel changes. Official Parcel versions are read-only in normal operations.

Roles and actions

  • Editor: create draft, update draft in DRAFT, submit, cancel before approval.
  • Reviewer: review-accept (SUBMITTED -> REVIEWED), reject from SUBMITTED, cancel from SUBMITTED or REVIEWED.
  • Approver: final-approve (REVIEWED -> APPROVED), reject from REVIEWED, cancel from REVIEWED.
  • Viewer: read-only access.

Actions depend on the current draft state and an exact dataset role. Approver does not imply Reviewer or Editor for mutations, and Reviewer does not imply Editor.

Standard flow

  1. Create a draft from the current official parcel version (or as a new chain).
  2. Edit draft geometry/attributes while state is DRAFT.
  3. Submit draft (DRAFT -> SUBMITTED).
  4. Reviewer accepts (SUBMITTED -> REVIEWED) or rejects.
  5. Approver final-approves (REVIEWED -> APPROVED) or rejects.
  6. Final approval creates a new official Parcel version.

A source-version draft may be saved without changes while an editor is working, but it cannot be submitted until at least one authoritative parcel attribute or its geometry materially differs from the source version. Geometry uses the database-backed parcel topology tolerance so storage/display CRS round trips do not become false changes. Notes, workflow timestamps, and snap provenance do not count as parcel changes. The submission service checks this invariant against the source row inside the locked database transaction; the browser also withholds the submit control and explains why it is unavailable.

Draft geometry can also be edited in QGIS without changing this workflow. See Edit parcel drafts outside LandWeave.

Attribute changes and boundary editing

Changing attributes on an ordinary parcel update preserves the exact stored boundary when you have not edited its geometry. For a first draft, that boundary comes from the current official parcel. When reopening a saved draft, its own boundary is retained, including earlier deliberate edits and saved new-chain drafts with no official source. Repeated Save Draft and reopen cycles do not move coordinates. This also works when the drawing controls fail to load.

Panning, zooming, inspecting coordinates, changing label precision, and confirming an edit without moving a vertex do not change the boundary. Cancelling an edit session restores the geometry and snap bindings from the start of that session.

Dragging, redrawing, applying a coordinate, nudging by a centimetre, or confirming a snap or traced boundary remains a deliberate edit. The server validates it in the installation's storage CRS and resolves snap and trace coordinates against the current authorized targets. Unedited vertices and interior rings retain their available precision during a partial edit; converting an edited polygon between display and storage coordinates can still introduce very small projection residuals. Existing overlap limits remain in force. Later attribute-only saves preserve that edited boundary exactly.

A small coordinate edit can be saved even when it is too small to count as a material geometry change for source-version submission. Such a draft still needs a qualifying parcel attribute change or material boundary change before Submit is available. Notes and binding changes alone do not qualify. New-chain drafts retain their existing submission rules.

Recovering an unsuccessful edit

Correct invalid attributes and retry using the retained form. Invalid or deleted geometry must be corrected or redrawn; saving cannot silently substitute the old boundary. If saved geometry has an invalid CRS, it is not displayed as editable coordinates. The existing validation message remains available.

If the saved boundary or an authorized snap target has changed since the form opened, reload the current draft and targets, then repeat or explicitly correct the edit. Pending or failed snap work must finish or be resolved with the existing retry/keep-unsnapped controls before saving. Cancelling an edit prevents its late responses from changing the restored geometry.

These checks do not change workflow permissions, actor separation, overlap advisories or transition restrictions. Rejected saves retain the previous stored draft; ordinary saves never change the official parcel. This correction prevents drift on future saves. It does not repair historical drift or authorize historical data changes. Any such repair or data-changing rollback needs separate owner authorization and must preserve official records and audit history.

State model

  • Active states: DRAFT, SUBMITTED, REVIEWED
  • Terminal states: APPROVED, REJECTED, CANCELLED
  • No transitions are allowed from terminal states.

Important rules

  • The creator or submitter cannot review their own draft.
  • The creator, submitter, or reviewer cannot give final approval.
  • Another eligible person must perform each decision stage.
  • Cancellation is role-based; an eligible non-owner may cancel an active item.
  • Only one active draft is allowed per (dataset, version chain).
  • Rejection requires a reason.
  • Approved/rejected/cancelled drafts are not editable.
  • Final approval fails if the draft source version is not the current official version anymore.
  • Draft saving remains available when overlap notices exist. Yellow identifies expected source overlap, blue identifies permitted legacy overlap, orange identifies another draft, and red identifies a blocking authoritative or reserved-area conflict.
  • Submit and review recompute current evidence. Final approval also checks every authoritative validity interval that would coexist with the new parcel version.
  • Select an overlap notice to zoom to the affected area. Conflict overlays are independent of surrounding-parcel visibility and never move or repair draft geometry.

History and audit

For each draft you can view:

  • draft metadata (created_by, submitted_by, reviewed_by, approved_by, etc.)
  • ordered workflow events with per-draft sequence numbers
  • linked resulting official version after approval

This supports full reconstruction of who did what and when.