Skip to content
Back to blog
drive9/14/2026

View, Suggest, or Edit: Three Modes for Who Can Change What

Piskes Drive's View/Editing mode toggle controls what a document actually lets happen at the command level, not just what buttons are visible.

drivedocumentspermissions

Anyone who's used Google Docs or Excel Online knows the small control near the top corner that switches between Viewing, Suggesting, and Editing. It's become a recognizable pattern precisely because it solves a real problem: file-level sharing tells you who can open a document, but it doesn't tell you what mode they're working in once they're inside it. A colleague reviewing a draft and a colleague actively rewriting it need different defaults, even if both have "access" to the same file.

Piskes Drive has the same pattern, and it's worth being precise about what it actually is — this is a different feature from file-level sharing permissions, which control who gets into a document at all. Editor mode controls what happens once you're in it.

What's actually enforced

The implementation (frontend/apps/drive/src/lib/drive/editor-mode.ts for documents, frontend/apps/drive/src/lib/office/sheet-permission.ts for spreadsheets) sets read-only or editable status through FWorkbookPermission's own setReadOnly() and setEditable() methods — public facade methods that Univer, the engine underneath both documents and spreadsheets, exposes specifically for this purpose. That's a meaningfully different mechanism than disabling buttons in the interface. A disabled button stops one interaction path — the one someone thought to grey out. A permission enforced at the command layer stops every command, whichever way it was triggered: a click, a keyboard shortcut, a paste, an undo reaching back into content that shouldn't have changed.

Why the distinction matters in practice

The gap between "the UI discourages this" and "this cannot happen" is exactly the gap that erodes trust in a collaborative tool over time. A reviewer who's supposed to be in view-only mode but who can still accidentally trigger an edit through a keyboard shortcut the UI didn't anticipate isn't actually in view-only mode — they're in a mode that looks like it, until it doesn't. Building this on the same command-layer permission system Univer already uses for its own protection features means the guarantee is real, not cosmetic.

Using it

Set the mode on a document or sheet the way you would in any tool with this pattern: viewing for someone who should only read, suggesting for someone whose changes should land as proposals rather than direct edits, editing for full access. The value isn't novelty — it's a well-understood control, implemented in a way that actually holds under the kind of edge-case interaction (a stray keyboard shortcut, an undo) that a purely visual restriction would miss.

View, Suggest, or Edit: Three Modes for Who Can Change What — Piskes