Skip to content

Settings & preferences parity — most of PATCH /api/user/update is unreachable from Android #31

Description

@Adron

The gap

UpdateProfileRequest in :feature:profile sends displayName and bio. PATCH /api/user/update accepts:

displayName, bio, avatar, theme, maxMessageLength, defaultPubliclyVisible,
messagesPerPage, viewingPreference, showPreviews, showAdvancedPostSettings, latitude,
longitude, isPrivateAccount, githubDefaultRepo, notificationTrayLimit.

Eleven of those fifteen have no Android surface at all. Several of them change behaviour the user
will notice immediately — default post visibility, feed contents, whether the account is private.

The web groups these under Settings (/help/settings): Profile settings, View preferences,
Message settings, Notifications, Profile location, Subscription & Billing, Security, Integrations,
AI features.

Done when

Android has a Settings surface that mirrors the web's groups, and every preference above is
readable and writable — with the feed, composer and notification surfaces actually respecting
them.


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
    epicA feature area tracked as a parent issue
    parityClosing a gap against interlinedlist.com
    P1Big hole in a shipped feature
    on Sep 15, 2026
  2. Adron commented on Sep 16, 2026

    @Adron
    MemberAuthor

    All six sub-issues are done, so closing this epic.

    All fifteen PATCH /api/user/update fields are now modelled, and every one that has a meaningful Android surface has one.

    Four things this epic established that are worth keeping:

    viewingPreference accepts only my_messages, all_messages, followers_only, following_only — confirmed from the server's own 400. The first implementation guessed all/mine/following/followers, which would have been rejected on every write.

    theme is not validated at all — "not-a-theme", "sepia", "SYSTEM" and "" were each accepted and stored verbatim with a 200. Any client can put an account into a theme no client can render, so Android is deliberately the conservative side.

    latitude/longitude cannot be unset — null, empty string and "null" all 400, and omission means "leave unchanged". That is an API gap; see #130.

    The spec's request-side types are a generator artifact. It types maxMessageLength, messagesPerPage, showPreviews etc. as string while typing isPrivateAccount as boolean, and the live response returns all of them as their natural JSON types. The app sends natural types, now asserted in tests.

    One item was not implementable: the web's Permissions section has an Email visibility setting with no corresponding field on GET /api/user or PATCH /api/user/update. Worth confirming whether that is an API gap or a web-only concept.

    Follow-up still open: #104 (consolidate the now-three readers/writers of account preferences behind one owner).

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

    P1Big hole in a shipped featurearea:settingsSettings & preferencesepicA feature area tracked as a parent issueparityClosing 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