Skip to content

Implement Event Versioning (Field-level) #25

@ivanskv2000

Description

@ivanskv2000

Goal

Add automatic versioning to events in Evsy, where a new version is created only when the set of linked fields is changed. This helps track the evolution of event structure without cluttering history with cosmetic changes (e.g. description edits).

Behavior

  • Each event can have multiple versions.
  • Version 0 is created automatically when the event is first created.
  • A new version is automatically created when the set of fields is modified (add/remove).
  • Users can optionally skip versioning and update the current version in place using a toggle in the UI (Update current version switch).
  • Only changes to the field list trigger versioning. Updates to name, description, tags, or links do not create a new version.

Backend Tasks

  • Create EventVersion model linked to Event
    • Fields: id, event_id, version_number, created_at, fields
  • Move the many-to-many relation Event ↔ Field into EventVersion (event_version_field table)
  • On event creation, automatically create version 0
  • On field updates:
    • Compare with the current version's field set
    • If different and update_current_version is false, create a new version
    • Otherwise, update the current version in place
  • Add endpoints:
    • GET /events/{id}/versions — list of all versions
    • GET /events/{id}/versions/{version_id} — details of a specific version
    • GET /events/{id}/fields?version={version_number} — get fields for a specific version (or latest if omitted)
    • POST /events/{id}/fields — allow field updates with an optional flag update_current_version

Frontend Tasks

  • Show version selector in event detail view
  • Add “Update current version” toggle to the field editing section
  • Optionally move field selection into a dedicated section to emphasize versioning impact
  • Make it visually clear when a new version will be created
  • Allow viewing version history (browsing previous versions)

Notes

  • Field ordering should be ignored when detecting differences (compare as sets).
  • Only field changes should affect versioning.
  • Most users will work with the latest version unless navigating history explicitly.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requesthelp wantedExtra attention is needed

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions