feat(profile): private account toggle under a Permissions group (#34) - #105
Merged
Merged
Conversation
Add the isPrivateAccount toggle to the Settings screen, in a Permissions group that mirrors where the web files it: its Settings page lists "Account visibility" under Permissions, and /help/account and /help/people both tell users to enable Private Account in "Settings, then Permissions". Because this setting changes who can see the user's content, the consequence is spelled out next to the switch in the help centre's own words (/help/people, "Private accounts"): new follows become follow requests to approve or reject, existing followers are unaffected, non-approved followers cannot see private messages, and going public again does not re-expose content to unapproved followers. The note also points at Account, then Follow requests, which is the existing route to the approve/reject screen. The write follows the established partial-PATCH pattern: only isPrivateAccount goes on the body, it applies optimistically and rolls back when the server refuses, and an absent value reads as public so the switch never claims a privacy guarantee the server is not making. Tests: SettingsPrivateAccountTest covers the single-field PATCH, optimistic apply, rollback on failure, the no-op when unchanged and the state after a refresh; DefaultSettingsRepositoryTest asserts the wire body carries isPrivateAccount alone as a JSON boolean; SettingsScreenTest asserts the switch reflects the stored state (including after a refresh) and that the explanation is shown. Closes #34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #34. Part of epic #31.
Placement mirrors the web, verified on three pages
/help/settingslists, under an explicit Permissions heading: "Account visibility: Make youraccount private; new followers will need to request to follow you and you must approve them".
/help/account("Private account") and/help/people("Private accounts") both instruct users toenable Private Account in "Settings, then Permissions".
So: a new Permissions group at the bottom of Settings with a single Private account switch —
same placement, same name as the web.
Deliberately not added: the web's other Permissions item, "Email visibility". There is no
corresponding field on
GET /api/userorPATCH /api/user/update, so it is not implementable. Thebrowser geolocation permission that also lives in that section is #37's territory.
Inline explanation is sourced, not invented
All copy comes from
/help/people→ "Private accounts", cited in thePermissionsGroupKDoc:The note beneath covers what non-approved followers cannot see, where to approve/reject, and that
switching back to public does not automatically re-expose content to unapproved followers.
DEFAULT_PRIVATE_ACCOUNT = false— an absent value must read as public, so the switch neverpromises a guarantee the server is not making.
Follow-requests reachability
Checked, and no nav change is needed:
Routes.FOLLOW_REQUESTSis already registered and theAccount tab renders an unconditional "Follow requests" row that navigates to it. The inline note
points at "Account, then Follow requests". Worth a follow-up but not done here: that row shows no
pending count, and
GET /api/follow/{userId}/countsreturnspendingRequests, so a badge would bea genuine improvement — it touches the Account screen and its ViewModel, which is a separate change.
Verification
TDD — unit tests written first and confirmed red (unresolved
setPrivateAccount/isPrivateAccountOrDefault/DEFAULT_PRIVATE_ACCOUNT) before implementing../gradlew :app:assembleDebug testDebugUnitTest→ BUILD SUCCESSFUL; repo-wide 919 tests, 0failures across 118 classes (
:feature:profilealone: 211). 6 Compose tests compile-verified only(no emulator) — the issue's "UI reflects the current state after a refresh" requirement is
additionally covered by JVM-runnable ViewModel tests.
Also fixed in passing:
FakeSettingsRepository's merge was silently droppingisPrivateAccount.Reviewer notes
SettingsComponents.ktwas not touched — the switch reusesSettingsSwitchRowas-is, tominimise conflicts with the sibling Settings branches.
DefaultSettingsRepositoryTest.enqueueUser's parameter list; Settings: notification tray limit (notificationTrayLimit) #35 and Settings: profile location (latitude/longitude) with runtime permission #37 willlikely touch the same helper, so expect a small conflict there.
SettingsScreenis now at 10 callbacks. Left alone per instruction — an actions holder is worthdoing once the parallel Settings branches have landed.