Skip to content

Fix mobile group peer-visibility HTTP method compatibility #254

Description

@stef-k

Problem

WayfarerMobile's reachable peer-visibility update currently sends:

PATCH /api/mobile/groups/{groupId}/peer-visibility

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.

Release sequencing

Activity

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

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions