Skip to content

ROU-12729: Fix configuration behavior when respectUserPosition is set to false#257

Merged
rugoncalves merged 4 commits into
devfrom
ROU-12729
Apr 22, 2026
Merged

ROU-12729: Fix configuration behavior when respectUserPosition is set to false#257
rugoncalves merged 4 commits into
devfrom
ROU-12729

Conversation

@rugoncalves
Copy link
Copy Markdown
Contributor

This PR is for fixing an issue caused by the introduction of a safeguard for respecting the user pan action. This produced incorrect behavior in a specific scenario:

  1. Developer enables only respectUserZoom (position respect is off).
  2. User manually changes the zoom level → _zoomChanged = true.
  3. Something external updates the map center programmatically (e.g. a marker position changes) → refresh is called.
  4. Because respectUserChange was true (zoom flag is on) and hasZoomOrPositionChanged was true (zoom changed), the condition evaluated to true.
  5. As a result, position was overwritten with the current map center instead of the new programmatic value, so the map never re-centred.

The root cause is that hasZoomOrPositionChanged aggregated both _zoomChanged and _positionChanged into a single boolean, conflating two independent concerns. A zoom change alone was enough to prevent a programmatic position update from taking effect, even when respectUserPosition was disabled.

Test Steps

  1. Open the sample page
  2. Set the toggle with label "Respect user zoom" to true
  3. Zoom out
  4. Change the position of the marker (e.g. click on Philadelphia)

Previously erroneous result: The map center doesn't change, and the zoom changed by the user is kept.
Expected result: The map gets centered in the marker, and the zoom changed by the user is kept.

Checklist

  • tested locally
  • documented the code
  • clean all warnings and errors of eslint
  • requires changes in OutSystems (if so, provide a module with changes)
  • requires new sample page in OutSystems (if so, provide a module with changes)

Copilot AI review requested due to automatic review settings April 20, 2026 11:48
@rugoncalves rugoncalves requested a review from a team as a code owner April 20, 2026 11:48
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes an OSMap refresh edge case where enabling only respectUserZoom could inadvertently prevent programmatic center updates, by separating “respect user position” logic from zoom-change state and applying the corrected guard consistently across providers.

Changes:

  • Update Leaflet and Google provider refresh() logic to respect the current center only when the user has panned and respectUserPosition is enabled.
  • Simplify the framework abstraction by removing the combined hasZoomOrPositionChanged getter and introducing a focused respectUserPosition runtime condition.
  • Add an ADR documenting the problem scenario, decision, and resulting implementation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
src/Providers/Maps/Leaflet/OSMap/OSMap.ts Adjusts refresh center selection to avoid blocking programmatic center updates when only zoom is respected.
src/Providers/Maps/Google/OSMap/OSMap.ts Mirrors the Leaflet fix for Google Maps refresh center selection, with null-safe center retrieval.
src/OSFramework/Maps/OSMap/AbstractMap.ts Removes the combined change-state getter and introduces a position-specific runtime guard.
docs/adr/ADR-0004-Fix-RespectUserZoom-Only-Breaking-Map-Center-Refresh.md Documents the bug, constraints, and the chosen fix approach.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/OSFramework/Maps/OSMap/AbstractMap.ts Outdated
Copy link
Copy Markdown
Contributor

@os-davidlourenco os-davidlourenco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rugoncalves rugoncalves added the bug Something isn't working label Apr 22, 2026
@sonarqubecloud
Copy link
Copy Markdown

@rugoncalves rugoncalves merged commit 139d66a into dev Apr 22, 2026
11 of 15 checks passed
@rugoncalves rugoncalves deleted the ROU-12729 branch April 22, 2026 07:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants