feat(revisions): property changes should auto-create revisions #173

New Issue

forbes · 2026-03-03T20:29:39Z

forbes commented

2026-03-03 20:29:39 +00:00

Context

From GAP_ANALYSIS.md Open Question #1: "Should editing properties auto-create revision?"

Decision: Yes. All item field changes should create a revision for full audit trail.

Current Behavior

PUT /api/items/{partNumber} in internal/api/handlers.go:HandleUpdateItem updates item metadata fields (part_number, description, item_type, sourcing_type, long_description) directly in the items table without creating a revision. A revision is only created when the properties JSONB field is included in the request body.

This means metadata changes (e.g. renaming a part, changing its type, updating its description) leave no trace in revision history.

Proposed Behavior

When any field on an item changes via PUT /api/items/{partNumber}:

Create a new revision that snapshots the current state (properties from the latest revision, plus any new property changes)
Record the metadata field changes in the revision comment (auto-generated if no comment provided, e.g. "description changed from X to Y")
The item-level fields (part_number, description, etc.) continue to be updated in the items table as before

Edge Cases

If the request includes both metadata changes and property changes, create a single revision capturing both
If no fields actually changed (PUT with identical values), skip revision creation
Bulk imports should still work efficiently — consider a skip_revision flag for import endpoints

Files to Modify

internal/api/handlers.go — HandleUpdateItem() (lines ~654-714): detect metadata changes, create revision when any field differs
internal/db/items.go — may need a GetLatestRevision() helper to snapshot current properties

GAP_ANALYSIS.md Section 7, Question 1
Revision schema: migrations/001_initial.sql, migrations/007_revision_status.sql

## Context From GAP_ANALYSIS.md Open Question #1: "Should editing properties auto-create revision?" **Decision: Yes.** All item field changes should create a revision for full audit trail. ## Current Behavior `PUT /api/items/{partNumber}` in `internal/api/handlers.go:HandleUpdateItem` updates item metadata fields (`part_number`, `description`, `item_type`, `sourcing_type`, `long_description`) directly in the `items` table without creating a revision. A revision is only created when the `properties` JSONB field is included in the request body. This means metadata changes (e.g. renaming a part, changing its type, updating its description) leave no trace in revision history. ## Proposed Behavior When any field on an item changes via `PUT /api/items/{partNumber}`: 1. Create a new revision that snapshots the current state (properties from the latest revision, plus any new property changes) 2. Record the metadata field changes in the revision comment (auto-generated if no comment provided, e.g. `"description changed from X to Y"`) 3. The item-level fields (`part_number`, `description`, etc.) continue to be updated in the `items` table as before ### Edge Cases - If the request includes both metadata changes and property changes, create a single revision capturing both - If no fields actually changed (PUT with identical values), skip revision creation - Bulk imports should still work efficiently — consider a `skip_revision` flag for import endpoints ## Files to Modify - `internal/api/handlers.go` — `HandleUpdateItem()` (lines ~654-714): detect metadata changes, create revision when any field differs - `internal/db/items.go` — may need a `GetLatestRevision()` helper to snapshot current properties ## Related - GAP_ANALYSIS.md Section 7, Question 1 - Revision schema: `migrations/001_initial.sql`, `migrations/007_revision_status.sql`

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kindred/silo#173