page-save-origin-semantics

What problem does it solve?

This document clarifies how GROWI decides when to enforce revision validation versus bypassing it during page saves, preventing accidental breakage of collaborative editing (Yjs) semantics and avoiding stale-revision errors.

Core Features & Use Cases

• Two-stage origin check: Explains the frontend decision to send or omit revisionId and the backend isUpdatable() logic that enforces or bypasses revision checks based on request origin and latest revision origin.
• Origin semantics and strength matrix: Describes origin values (editor, view, undefined), the rule set where editor-origin can bypass checks against view/editor latest revisions, and when strict revision matching is required.
• Server-side fallback pattern: Recommends fetching previousRevision from currentPage.revision when revisionId is not provided so diff detection and other features remain functional.
• Use cases: Implementing save/update API handlers, debugging save conflicts, adding features that need previous revision data without breaking Yjs collaborative editing.

Quick Start

Ask the guide to explain when the frontend should include revisionId and how the backend isUpdatable check evaluates origin combinations so you can implement a safe server-side fallback for previousRevision.