Link permissions (moved)
This page describes a control that no longer exists. Shares used to
carry two separate settings: a visibility tier (public / unlisted /
members) for who could read, and a link_permission tier (none /
can_view / can_comment / can_suggest) for what a URL-holder could
do beyond reading. The two were folded into one ordered access ladder,
and the link_permission column was dropped.
Read Access and passwords instead. The short version:
| Old pair | Now |
|---|---|
unlisted + none |
access: view |
unlisted + can_comment |
access: comment (the default for new shares) |
unlisted + can_suggest |
access: suggest |
members + anything |
access: restricted |
public + a tier |
the same rung, plus indexed: true |
Set it with anchorify access <slug-or-id> restricted|view|comment|suggest [--index|--no-index], on the share settings page, or via
POST /api/v1/shares/:id/access. The old
anchorify link-perm subcommand and the
POST /api/v1/shares/:id/link-permission endpoint were both removed —
they don't silently no-op, they fail.
Two things that carried over unchanged:
- Rate limiting. Comments and suggestions from URL-holders go through the same per-IP token bucket as authenticated writes. See Rate limits.
- Per-recipient grants. The ladder is one setting for everyone holding the link. "This person can edit, that person can only read" still means an explicit grant — see Doc-level roles.