Skip to content

Lists: creation options the API accepts but the app drops (parentId, folderId, messageId, initialRows, metadata) #54

Description

@Adron

Part of #49 — Lists parity gaps: GitHub-backed lists, saved views, view modes and collaborative editing

CreateListRequest sends only title, description, schema, isPublic.

  • parentId — child lists form a tree with breadcrumb navigation on the web; Android cannot
    set a parent at creation.
  • messageId — "Create list from message": the list-plus icon on any message creates a list
    using that message as the description, with a suggested name. (Related to, but distinct from,
    the Create-from epic.)
  • initialRows — starter rows at creation, which Powered Templates depends on.
  • metadata / source — pass-through fields.
  • Also expose the From Template tab the web offers on list creation. There is no list-template
    endpoint in the OpenAPI spec, so confirm with the owner where those templates come from before
    building.

Tests: each field reaches the request; parent breadcrumb navigation.


Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

Activity

  1. added
    parityClosing a gap against interlinedlist.com
    P2Completeness / settings surface
    on Sep 15, 2026
  2. Adron commented on Sep 16, 2026

    @Adron
    MemberAuthor

    Implemented in #98 (branch issue/54-list-creation-options). Closing here — review and any follow-up happens on the PR.

    Three things need your input, carried into the PR so they are not lost:

    1. From Template tab was not built — as the issue suspected, there is no list-template endpoint anywhere. The spec has only /api/documents/templates, /api/documents/templates/seed-defaults and /api/documents/from-template, and the help centre has no list-template page. Where do the web's list templates come from?
    2. initialRows shape is unverified. The generated spec types it as "type": "string", and the human-written reference never mentions it. It is modelled as an array of flat column-keyed objects, matching how POST /api/lists/{id}/data serialises a row. Worth confirming before AI: Powered Templates tab on list creation #8 (Powered Templates) depends on it.
    3. folderId is not a documented create field — it is a real column, but folder placement is documented on PUT /api/lists/{id} instead. Included as the issue asked, with a KDoc caveat.

    Also corrected along the way: CreateListRequest.schema was typed String?, but the help reference is explicit that POST /api/lists takes the DSL as an object (the comma-separated string form belongs to PUT /api/lists/{id}/schema). No caller ever set it, so the fix is behaviour-neutral.

    Not done, worth its own issue: PUT /api/lists/{id} accepts parentId, so re-parenting an existing list is still unsupported.

  3. added a commit that references this issue on Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Completeness / settings surfacearea:listsListsparityClosing a gap against interlinedlist.com

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions