Repository navigation
Settings & preferences parity — most of PATCH /api/user/update is unreachable from Android #31
Description
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
viewingPreference) and link previews (showPreviews) #33isPrivateAccount) #34notificationTrayLimit) #35theme) #36latitude/longitude) with runtime permission #37Adron commentedon Sep 16, 2026
All six sub-issues are done, so closing this epic.
viewingPreference) and link previews (showPreviews) #33 — Settings surface + view preferences and link previews → feat(profile): Settings surface + view preferences and link previews (#33) #93isPrivateAccount) #34 — private account toggle → feat(profile): private account toggle under a Permissions group (#34) #105notificationTrayLimit) #35 — notification tray limit (and both consumers honour it) → feat: notification tray limit — setting plus both consumers (#35) #112theme) #36 — theme synced to the account → feat(profile): sync the theme preference to the account, two-way (#36) #118latitude/longitude) with runtime permission #37 — profile location → feat(profile): profile location — coarse capture, manual entry, and an honest non-clear (#37) #130All fifteen
PATCH /api/user/updatefields are now modelled, and every one that has a meaningful Android surface has one.Four things this epic established that are worth keeping:
viewingPreferenceaccepts onlymy_messages,all_messages,followers_only,following_only— confirmed from the server's own 400. The first implementation guessedall/mine/following/followers, which would have been rejected on every write.themeis 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/longitudecannot 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,showPreviewsetc. asstringwhile typingisPrivateAccountasboolean, 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/userorPATCH /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).