You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the coordinated backend base for Wayfarer #505, MobileGroupsController.SetPeerVisibility is documented and routed as:
POST /api/mobile/groups/{groupId}/peer-visibility
The Groups page switch reaches GroupsViewModel.TogglePeerVisibilityCommand, IGroupMemberManager, IGroupsService, and production GroupsService. For a selected group whose summary has OrgPeerVisibilityEnabled == true, an authenticated active member can therefore attempt the setting change and receive a method-mismatch response instead of applying it.
This is a pre-existing mobile/backend compatibility defect discovered during the coordinated #505 API audit. Raster cleanup #252 is completed and merged through PR #255. Correct this focused slice after that synchronized mobile base and before #253 Stage 1 begins.
Authoritative contract
Change WayfarerMobile's production GroupsService.UpdatePeerVisibilityAsync from PATCH to POST. Do not change Wayfarer and do not send, retry, probe, or fall back to a second verb. One user action sends at most one peer-visibility request.
Preserve the existing contract:
named WayfarerApi client and configured base address;
Authorization: Bearer <api-token> handling without exposing the token;
route /api/mobile/groups/{groupId}/peer-visibility with the existing Guid formatting;
JSON Content-Type, camel-case { "disabled": <bool> }, and the meaning of PeerVisibilityUpdateRequest.Disabled / backend OrgPeerVisibilityAccessRequest.Disabled;
propagation of the supplied cancellation token to the outbound send; cancellation-policy redesign is out of scope;
true only for a successful HTTP status and false for unauthorized, forbidden, not found, validation, transport, timeout, or server failure under the existing bounded error policy;
no response-body, token, URL, group, or user data added to diagnostics.
The backend resolves the caller from the bearer token, rejects a missing/invalid token, forbids an inactive user, requires an active membership in the requested group, returns not found for a missing group, persists the current member's OrgPeerVisibilityAccessDisabled, and returns 200 OK with { "disabled": <bool> }. The mobile service does not need to consume that response body to determine success.
The current mobile endpoint is presented only when OrgPeerVisibilityEnabled == true; the backend endpoint itself does not currently reject a group by type. Do not add mobile inference or backend Friends/Organization type enforcement in this issue. Preserve the existing server-side user/group/membership authority and treat any non-success response as failure.
UI and state behavior
Preserve the current setting meaning: switch on means visible and disabled == false; switch off means hidden and disabled == true.
GroupsViewModel commits MyPeerVisibilityDisabled and the current member record only after service success. On failure it retains the prior view-model/member state and sets the existing bounded error message. Do not add optimistic state, refresh/rollback machinery, stale-command infrastructure, UI redesign, or broader error presentation for this verb correction. A view-model test is required only if implementation changes that existing ownership or behavior.
Acceptance criteria
A focused red service test exercises production GroupsService and proves it sends PATCH where the authoritative API requires POST.
The corrected production service sends exactly one authenticated POST request to the unchanged route for one call.
That focused production-service test also verifies the existing JSON disabled boolean shape and, where the handler seam exposes it naturally, the bearer header and forwarded cancellation token; do not build a status matrix.
Existing service success/failure coverage remains green: successful status returns true; non-success and existing bounded transport/server failures do not report success.
Do not use or extend the copied TestGroupsService as proof of production request behavior. Narrowly adapt the relevant existing tests to instantiate production GroupsService; unrelated test-copy cleanup is out of scope.
Update the stale PATCH endpoint XML comments on IGroupsService and PeerVisibilityUpdateRequest to POST. No user documentation or Unreleased changelog entry is required because user-visible behavior and the public setting meaning are unchanged.
The reachable GroupsViewModel workflow continues to call the corrected service without UI/state redesign.
No backend, authentication redesign, schema, migration, provider, credential, configuration, packaging, installation, deployment, or publication change.
Scope and regression boundaries
This is a one-method production correction. Do not add a generic endpoint-compatibility framework, exhaustive HTTP-status matrix, backend integration infrastructure, browser/emulator/device harness, retry layer, compatibility probe, or unrelated cleanup.
Current released mobile remains incompatible with the current/new backend for this action because it sends PATCH. Corrected mobile is compatible with the current backend candidate because it sends the authoritative POST. Available backend history and current web self-service use support POST; no concrete supported released backend requiring PATCH has been identified. Do not add hypothetical old-server fallback.
The change must not affect authentication generally; Location or Timeline synchronization; cursor state; Trips, Places, Segments, Regions, or Areas; activity; visits; SSE; routing; offline data; persistence; or migrations.
The dormant unused SubscribeToUserAsync SSE endpoint mismatch remains explicitly excluded. No production caller reaches it; retain it for the final Wayfarer #505 API compatibility audit unless a reachable owner is discovered.
Proportional validation
Run the focused production GroupsService peer-visibility tests first.
Run the repository's Release test/Core build flow and complete test suite because GroupsService is shared and repository policy uses that suite as the ordinary code gate.
Run git diff --check.
Do not require Android compilation: changing an HttpMethod and source XML comments introduces no MAUI/platform compilation risk. Invoke it only if implementation unexpectedly changes a MAUI/platform seam, and report that scope change.
After independent review passes, require the GitHub Actions test check to succeed on the exact PR head before merge.
Problem
WayfarerMobile's reachable peer-visibility update currently sends:
PATCH /api/mobile/groups/{groupId}/peer-visibilityAt the coordinated backend base for Wayfarer #505,
MobileGroupsController.SetPeerVisibilityis documented and routed as:POST /api/mobile/groups/{groupId}/peer-visibilityThe Groups page switch reaches
GroupsViewModel.TogglePeerVisibilityCommand,IGroupMemberManager,IGroupsService, and productionGroupsService. For a selected group whose summary hasOrgPeerVisibilityEnabled == true, an authenticated active member can therefore attempt the setting change and receive a method-mismatch response instead of applying it.This is a pre-existing mobile/backend compatibility defect discovered during the coordinated #505 API audit. Raster cleanup #252 is completed and merged through PR #255. Correct this focused slice after that synchronized mobile base and before #253 Stage 1 begins.
Authoritative contract
Change WayfarerMobile's production
GroupsService.UpdatePeerVisibilityAsyncfromPATCHtoPOST. Do not change Wayfarer and do not send, retry, probe, or fall back to a second verb. One user action sends at most one peer-visibility request.Preserve the existing contract:
WayfarerApiclient and configured base address;Authorization: Bearer <api-token>handling without exposing the token;/api/mobile/groups/{groupId}/peer-visibilitywith the existingGuidformatting;Content-Type, camel-case{ "disabled": <bool> }, and the meaning ofPeerVisibilityUpdateRequest.Disabled/ backendOrgPeerVisibilityAccessRequest.Disabled;trueonly for a successful HTTP status andfalsefor unauthorized, forbidden, not found, validation, transport, timeout, or server failure under the existing bounded error policy;The backend resolves the caller from the bearer token, rejects a missing/invalid token, forbids an inactive user, requires an active membership in the requested group, returns not found for a missing group, persists the current member's
OrgPeerVisibilityAccessDisabled, and returns200 OKwith{ "disabled": <bool> }. The mobile service does not need to consume that response body to determine success.The current mobile endpoint is presented only when
OrgPeerVisibilityEnabled == true; the backend endpoint itself does not currently reject a group by type. Do not add mobile inference or backend Friends/Organization type enforcement in this issue. Preserve the existing server-side user/group/membership authority and treat any non-success response as failure.UI and state behavior
Preserve the current setting meaning: switch on means visible and
disabled == false; switch off means hidden anddisabled == true.GroupsViewModelcommitsMyPeerVisibilityDisabledand the current member record only after service success. On failure it retains the prior view-model/member state and sets the existing bounded error message. Do not add optimistic state, refresh/rollback machinery, stale-command infrastructure, UI redesign, or broader error presentation for this verb correction. A view-model test is required only if implementation changes that existing ownership or behavior.Acceptance criteria
GroupsServiceand proves it sendsPATCHwhere the authoritative API requiresPOST.POSTrequest to the unchanged route for one call.disabledboolean shape and, where the handler seam exposes it naturally, the bearer header and forwarded cancellation token; do not build a status matrix.true; non-success and existing bounded transport/server failures do not report success.TestGroupsServiceas proof of production request behavior. Narrowly adapt the relevant existing tests to instantiate productionGroupsService; unrelated test-copy cleanup is out of scope.PATCHendpoint XML comments onIGroupsServiceandPeerVisibilityUpdateRequesttoPOST. No user documentation or Unreleased changelog entry is required because user-visible behavior and the public setting meaning are unchanged.GroupsViewModelworkflow continues to call the corrected service without UI/state redesign.Scope and regression boundaries
This is a one-method production correction. Do not add a generic endpoint-compatibility framework, exhaustive HTTP-status matrix, backend integration infrastructure, browser/emulator/device harness, retry layer, compatibility probe, or unrelated cleanup.
Current released mobile remains incompatible with the current/new backend for this action because it sends
PATCH. Corrected mobile is compatible with the current backend candidate because it sends the authoritativePOST. Available backend history and current web self-service use supportPOST; no concrete supported released backend requiringPATCHhas been identified. Do not add hypothetical old-server fallback.The change must not affect authentication generally; Location or Timeline synchronization; cursor state; Trips, Places, Segments, Regions, or Areas; activity; visits; SSE; routing; offline data; persistence; or migrations.
The dormant unused
SubscribeToUserAsyncSSE endpoint mismatch remains explicitly excluded. No production caller reaches it; retain it for the final Wayfarer #505 API compatibility audit unless a reachable owner is discovered.Proportional validation
GroupsServicepeer-visibility tests first.GroupsServiceis shared and repository policy uses that suite as the ordinary code gate.git diff --check.HttpMethodand source XML comments introduces no MAUI/platform compilation risk. Invoke it only if implementation unexpectedly changes a MAUI/platform seam, and report that scope change.testcheck to succeed on the exact PR head before merge.Release sequencing
maincontaining that merge.