Repository navigation
Lists: saved views (shared and personal, default, fork-to-personal) #51
Description
Activity
Implemented in #107 (branch
issue/51-list-saved-views). Closing here — review and any follow-up happens on the PR.This issue asked to "confirm the
configshape against the live API before modelling it". Done — saved views are documented nowhere (absent from the help centre, a bareobjectin the spec), so I created a view on the test account, probed it, forked it, and deleted both, verifying the account back to{"views":[]}. The full contract is in the PR.The important discovery: unknown
configvalues are silently dropped rather than rejected, so the implementation treats the server's returned view as authoritative after every write and preserves unmodelled keys through a round-trip.That same discovery blocks #52 as currently written — see the comment I have left there.
- added a commit that references this issue
on Sep 16, 2026
Part of #49 — Lists parity gaps: GitHub-backed lists, saved views, view modes and collaborative editing
Unused API:
GET /api/lists/{id}/views— "Every shared view on the list, plus this user'sown personal views" — with
POSTto create (name,scope,config,isDefault),PUTtoupdate,
DELETEto remove, andPOST /api/lists/{id}/views/{viewId}to fork a shared view intoa personal copy ("the escape hatch" when someone else's shared view does not suit).
Android has no concept of views at all, so a list always renders one way.
scope.configshape against the live API before modelling it — the spec types it loosely.Tests: view list parse; create/update/delete round-trips; fork produces a personal copy.
Filed from the parity review of
feature/parity-wip@14d7795against interlinedlist.com (OpenAPI/api/openapi.json, 233 paths) and the public help centre.