kindred/silo
1
1
Fork 0
Code Issues 29 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

feat(revisions): auto-create revision on item metadata changes #177

Merged
forbes merged 1 commits from feat/auto-revision-on-update into main 2026-03-04 20:08:43 +00:00
Conversation 0 Commits 1 Files Changed 2 +93 -4
forbes commented 2026-03-04 19:59:45 +00:00
Owner
Copy Link

Summary

Closes #173

When updating an item via PUT /api/items/{partNumber}, any change to metadata fields now creates a new revision for full audit trail.

Problem

Previously, HandleUpdateItem only created a revision when the properties JSONB field was explicitly included in the request body. Changes to item metadata (part_number, description, item_type, sourcing_type, long_description) were applied in-place with no trace in revision history.

Solution

Change detection in HandleUpdateItem

Before calling Update(), compare each request field against the current item values. Track which fields actually changed in a metadataChanges slice.

Auto-revision creation

Scenario Behavior
Only metadata changed Carry forward properties from latest revision, auto-generate comment (e.g. "updated description")
Only properties changed Use provided properties (existing behavior)
Both changed Single revision with new properties and user comment or auto-generated
Nothing changed No revision created (avoids noise)

SSE + job triggers

When a revision is auto-created, publish revision.created SSE event and trigger auto-jobs — matching the pattern in HandleCreateRevision.

Files Changed

File Change
internal/db/items.go Add GetLatestRevision() — efficiently fetches current revision properties via ORDER BY revision_number DESC LIMIT 1
internal/api/handlers.go Modify HandleUpdateItem() — add change detection, auto-revision, SSE event, job trigger

Not Changed

  • POST /api/items (HandleCreateItem) — already creates revision 1
  • POST /api/items/{pn}/revisions (HandleCreateRevision) — explicit revision creation
  • POST /api/items/{pn}/file (HandleUploadFile) — file upload path
  • CSV/ODS import — creates new items via items.Create() which already makes revision 1

Testing

  • go build ./... — passes
  • go test ./... — all tests pass, no regressions
## Summary Closes #173 When updating an item via `PUT /api/items/{partNumber}`, any change to metadata fields now creates a new revision for full audit trail. ## Problem Previously, `HandleUpdateItem` only created a revision when the `properties` JSONB field was explicitly included in the request body. Changes to item metadata (part_number, description, item_type, sourcing_type, long_description) were applied in-place with no trace in revision history. ## Solution ### Change detection in `HandleUpdateItem` Before calling `Update()`, compare each request field against the current item values. Track which fields actually changed in a `metadataChanges` slice. ### Auto-revision creation | Scenario | Behavior | |----------|----------| | Only metadata changed | Carry forward properties from latest revision, auto-generate comment (e.g. `"updated description"`) | | Only properties changed | Use provided properties (existing behavior) | | Both changed | Single revision with new properties and user comment or auto-generated | | Nothing changed | No revision created (avoids noise) | ### SSE + job triggers When a revision is auto-created, publish `revision.created` SSE event and trigger auto-jobs — matching the pattern in `HandleCreateRevision`. ## Files Changed | File | Change | |------|--------| | `internal/db/items.go` | Add `GetLatestRevision()` — efficiently fetches current revision properties via `ORDER BY revision_number DESC LIMIT 1` | | `internal/api/handlers.go` | Modify `HandleUpdateItem()` — add change detection, auto-revision, SSE event, job trigger | ## Not Changed - `POST /api/items` (HandleCreateItem) — already creates revision 1 - `POST /api/items/{pn}/revisions` (HandleCreateRevision) — explicit revision creation - `POST /api/items/{pn}/file` (HandleUploadFile) — file upload path - CSV/ODS import — creates new items via `items.Create()` which already makes revision 1 ## Testing - `go build ./...` — passes - `go test ./...` — all tests pass, no regressions
forbes added 1 commit 2026-03-04 19:59:46 +00:00
feat(revisions): auto-create revision on item metadata changes 563eae4892 
When updating an item via PUT /api/items/{partNumber}, any change to
metadata fields (part_number, item_type, description, sourcing_type,
long_description) now creates a new revision for audit trail.

Previously, revisions were only created when the 'properties' JSONB
field was explicitly included in the request body. Metadata-only changes
were invisible in revision history.

New behavior:
- Detect which metadata fields actually changed vs current values
- If metadata changed without properties, carry forward properties from
  the latest revision and auto-generate a comment (e.g. 'updated description')
- If properties changed, use the provided properties (existing behavior)
- If both changed, create a single revision capturing both
- If nothing actually changed (identical values), skip revision creation
- Publish revision.created SSE event and trigger auto-jobs

Also adds GetLatestRevision() to ItemRepository for efficiently fetching
the current revision's properties without loading all revisions.

Closes #173
forbes merged commit 4426cb380d into main 2026-03-04 20:08:43 +00:00
forbes deleted branch feat/auto-revision-on-update 2026-03-04 20:08:43 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
forbes
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kindred/silo#177
Delete Branch "feat/auto-revision-on-update"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?