feat(settings): move Position Estimation to global Settings

[Yeraze]

Relocates the Position Estimation settings out of the per-source Automation tab and into the global Settings UI.

Why

Position estimation (issue #3271/#3349) is a single global, cross-source batch job:

• one set of keys (position_estimation_enabled / _frequency_hours / _lookback_hours),
• one scheduler (positionEstimationScheduler) pooling traceroute + neighbor observations across all Meshtastic sources.

But it was rendered in the per-source Automation tab, which:

1. Implied per-source config — you reach that tab by opening a specific source (e.g. "RAK4631"), so editing the global estimator there was misleading.

2. Mismatched the backend permission model — the endpoints are gated by settings, not automation:

   • GET /api/settings/position-estimation/status → settings:read (server.ts:6558)
   • POST /api/settings/position-estimation/run-now → settings:write (server.ts:6568)
   • save via POST /api/settings → settings:write

   So a user with automation:read but no settings:write could open the section and then hit permission errors on Save/Recalculate.

3. Was hidden for mqtt_bridge sources and depended on which source you opened — wrong for an app-wide feature. (This is the same root issue behind the closed fix(automation): add Position Estimation to the Automation section nav #3359, which only added a quick-link in the old, wrong location.)

Change

• Add PositionEstimationSection to SettingsTab under GLOBAL_SECTIONS (settings-position-estimation), rendered + nav-linked in the global Settings tab (mode="global", reached via the Dashboard ⚙️ → /settings).
• Gate it on hasPermission('settings', 'write') to match the backend (admin short-circuits).
• Remove the section (and its import) from the Automation tab in App.tsx.

Testing

• New static-source invariant test (PositionEstimationSettings.move.test.ts) — SettingsTab.tsx/App.tsx are too large to render in jsdom, so it asserts: section is global-only (in GLOBAL_SECTIONS, not SOURCE_SECTIONS), rendered + nav-linked + permission-gated in SettingsTab, and gone from the Automation tab. 4 passed.
• Full suite: 6134 passed, 0 failed. tsc --noEmit clean.

Notes

• The component's i18n keys remain automation.position_estimation.* (still resolve correctly); renaming them to settings.* would churn 9 locale files for no functional gain.
• Supersedes fix(automation): add Position Estimation to the Automation section nav #3359 (closed).

🤖 Generated with Claude Code

[github-actions]

Claude finished @Yeraze's task —— View job

---

PR Review: Position Estimation Settings Migration

Reviewing this pull request for code quality, best practices, potential issues, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Examine changed files in detail
• Analyze architectural decisions
• Review code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Review Summary

This PR successfully addresses a UX/UI architectural issue by moving the Position Estimation settings from the per-source Automation tab to the global Settings UI. The change is well-motivated and properly implemented.

✅ Strengths

Architectural Alignment

• Correctly addresses the mismatch between global functionality and per-source UI placement
• Aligns frontend UI with backend permission model (settings:read/settings:write vs automation)
• Proper placement in GLOBAL_SECTIONS vs SOURCE_SECTIONS in SettingsTab.tsx:99-101

Code Quality

• Clean, minimal changes - only what's necessary for the move
• Proper permission gating with canWriteSettings (SettingsTab.tsx:174 and SettingsTab.tsx:1836)
• Maintains existing component API - no breaking changes to PositionEstimationSection itself
• Good commenting explaining the architectural decision (lines 98-100 in SettingsTab.tsx)

Testing

• Excellent static source testing approach for components too large to render in jsdom
• Comprehensive test coverage ensuring the move is bidirectional (removed from old location, added to new)
• Tests verify both presence/absence in correct section arrays and actual rendering
• Good use of helper function setLiteral() for parsing Set literals from source code

✅ Security & Performance

Security

• Maintains existing permission boundaries - no security regressions
• Proper CSRF protection maintained via useCsrfFetch
• No new attack surfaces introduced

Performance

• Minimal performance impact - just a component relocation
• No additional API calls or data fetching changes
• Existing component caching and optimization preserved

✅ Best Practices Adherence

Repository Guidelines

• Follows CLAUDE.md guidelines for component movement
• Aligns with multi-source architecture principles (global vs per-source)
• Maintains existing i18n key structure to avoid unnecessary churn

React Patterns

• Proper hook usage maintained in PositionEstimationSection
• Appropriate conditional rendering with permission checks
• Navigation integration follows existing patterns

🔍 Minor Observations

Translation Keys (Not an issue, but worth noting)

• The component still uses automation.position_estimation.* i18n keys rather than settings.*
• As noted in the PR description, this is intentional to avoid churning 9 locale files
• Keys still resolve correctly and functionality is unchanged

Test Approach

• Static source testing is a pragmatic solution for large components
• Could potentially be supplemented with integration tests, but current approach is sufficient
• Test placement in src/components/ follows the pattern of testing component organization

📊 Test Coverage Assessment

The test suite comprehensively covers:

1. ✅ Correct section categorization (global vs source)
2. ✅ Component rendering in new location
3. ✅ Navigation link generation
4. ✅ Permission gating verification
5. ✅ Removal from old location
6. ✅ Import statement verification

This level of coverage is appropriate for a component move operation.

✨ Recommendation

APPROVE - This is a well-executed refactoring that:

• Solves a legitimate UX/architectural issue
• Maintains backward compatibility
• Includes appropriate test coverage
• Follows repository conventions
• Has no security or performance concerns

The change makes the UI more intuitive by placing global functionality in the global settings area, which will improve user experience especially for users with limited permissions or when working with MQTT bridge sources.

[github-actions]

Claude finished @Yeraze's task —— View job

---

PR Review: Position Estimation Settings Migration

Reviewing this pull request for code quality, best practices, potential issues, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Examine changed files in detail
• Analyze architectural decisions
• Review code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Review Summary

This PR successfully addresses a UX/UI architectural issue by moving the Position Estimation settings from the per-source Automation tab to the global Settings UI. The change is well-motivated and properly implemented.

✅ Strengths

Architectural Alignment

• Correctly addresses the mismatch between global functionality and per-source UI placement
• Aligns frontend UI with backend permission model (settings:read/settings:write vs automation)
• Proper placement in GLOBAL_SECTIONS vs SOURCE_SECTIONS in SettingsTab.tsx:99-101

Code Quality

• Clean, minimal changes - only what's necessary for the move
• Proper permission gating with canWriteSettings (SettingsTab.tsx:174 and SettingsTab.tsx:1836)
• Maintains existing component API - no breaking changes to PositionEstimationSection itself
• Good commenting explaining the architectural decision (lines 98-100 in SettingsTab.tsx)

Testing

• Excellent static source testing approach for components too large to render in jsdom
• Comprehensive test coverage ensuring the move is bidirectional (removed from old location, added to new)
• Tests verify both presence/absence in correct section arrays and actual rendering
• Good use of helper function setLiteral() for parsing Set literals from source code

✅ Security & Performance

Security

• Maintains existing permission boundaries - no security regressions
• Proper CSRF protection maintained via useCsrfFetch
• No new attack surfaces introduced

Performance

• Minimal performance impact - just a component relocation
• No additional API calls or data fetching changes
• Existing component caching and optimization preserved

✅ Best Practices Adherence

Repository Guidelines

• Follows CLAUDE.md guidelines for component movement
• Aligns with multi-source architecture principles (global vs per-source)
• Maintains existing i18n key structure to avoid unnecessary churn

React Patterns

• Proper hook usage maintained in PositionEstimationSection
• Appropriate conditional rendering with permission checks
• Navigation integration follows existing patterns

🔍 Minor Observations

Translation Keys (Not an issue, but worth noting)

• The component still uses automation.position_estimation.* i18n keys rather than settings.*
• As noted in the PR description, this is intentional to avoid churning 9 locale files
• Keys still resolve correctly and functionality is unchanged

Test Approach

• Static source testing is a pragmatic solution for large components
• Could potentially be supplemented with integration tests, but current approach is sufficient
• Test placement in src/components/ follows the pattern of testing component organization

📊 Test Coverage Assessment

The test suite comprehensively covers:

1. ✅ Correct section categorization (global vs source)
2. ✅ Component rendering in new location
3. ✅ Navigation link generation
4. ✅ Permission gating verification
5. ✅ Removal from old location
6. ✅ Import statement verification

This level of coverage is appropriate for a component move operation.

✨ Recommendation

APPROVE - This is a well-executed refactoring that:

• Solves a legitimate UX/architectural issue
• Maintains backward compatibility
• Includes appropriate test coverage
• Follows repository conventions
• Has no security or performance concerns

The change makes the UI more intuitive by placing global functionality in the global settings area, which will improve user experience especially for users with limited permissions or when working with MQTT bridge sources.

[Yeraze]

Position estimation (issue #3271) overhaul covering relocation, a max-accuracy cutoff, and map-toggle gating.

1. Move to global Settings

Position estimation is a single global, cross-source batch job (one set of position_estimation_* keys, one scheduler pooling all Meshtastic sources). It was rendered in the per-source Automation tab, which implied per-source config, mismatched the backend (its endpoints are gated by settings:read/settings:write, not automation), and was hidden for mqtt_bridge sources.

• Moved PositionEstimationSection into the global Settings tab (SettingsTab, mode="global", reached via Dashboard ⚙️ → /settings), added to GLOBAL_SECTIONS, gated on hasPermission('settings','write') to match the backend.
• Removed it (and its import) from the Automation tab.
• Supersedes fix(automation): add Position Estimation to the Automation section nav #3359 (closed).

2. Maximum Acceptable Accuracy cutoff

The "huge circles" on the map are honestly-computed but large — dominated by the 5 km single-anchor default (DEFAULT_SINGLE_ANCHOR_KM). Rather than store low-confidence guesses:

• New global setting position_estimation_max_uncertainty_km (0 = no limit).
• The scheduler reads it and passes maxUncertaintyKm to recomputeAll, which discards any solved estimate whose uncertainty radius exceeds the ceiling and deletes that node's stale estimate.
• Exposed as a km input in the Position Estimation settings section; the last-run summary reports how many were discarded.

3. Gate uncertainty circles behind "Show Accuracy"

The estimated-position uncertainty circles were tied to Show Estimated Positions. They're now gated by the existing Show Accuracy map toggle (showAccuracyRegions) — so one control governs every accuracy overlay (precision-bits rectangles + estimated circles). The estimated markers stay under Show Estimated Positions; both are required so a circle never renders without its marker.

Verified: no unit/render bug

Traced the pipeline — uncertaintyKm (km) → served in km → * 1000 once → Leaflet <Circle radius> (meters). Correct, single conversion. The circles were large because the values are large, not a units error.

Testing

• New: scheduler threads maxUncertaintyKm through (incl. 0=no-limit default); service discards over-threshold estimates + clears stale rows, keeps within-threshold, treats 0 as unlimited; static-invariant test for the global-Settings relocation.
• Full suite: 6138 passed, 0 failed. tsc --noEmit clean.

Notes

• i18n: the section's labels use inline t(key, 'default') fallbacks (the automation.position_estimation.* keys were never in en.json — pre-existing), so the new labels follow the same precedent.

🤖 Generated with Claude Code

[github-actions]

Claude finished @Yeraze's task —— View job

---

PR Review: Position Estimation Settings Migration

Reviewing this pull request for code quality, best practices, potential issues, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Examine changed files in detail
• Analyze architectural decisions
• Review code quality and best practices
• Check for potential bugs or issues
• Assess performance considerations
• Review security concerns
• Evaluate test coverage
• Provide comprehensive feedback

Review Summary

This PR successfully addresses a UX/UI architectural issue by moving the Position Estimation settings from the per-source Automation tab to the global Settings UI. The change is well-motivated and properly implemented.

✅ Strengths

Architectural Alignment

• Correctly addresses the mismatch between global functionality and per-source UI placement
• Aligns frontend UI with backend permission model (settings:read/settings:write vs automation)
• Proper placement in GLOBAL_SECTIONS vs SOURCE_SECTIONS in SettingsTab.tsx:99-101

Code Quality

• Clean, minimal changes - only what's necessary for the move
• Proper permission gating with canWriteSettings (SettingsTab.tsx:174 and SettingsTab.tsx:1836)
• Maintains existing component API - no breaking changes to PositionEstimationSection itself
• Good commenting explaining the architectural decision (lines 98-100 in SettingsTab.tsx)

Testing

• Excellent static source testing approach for components too large to render in jsdom
• Comprehensive test coverage ensuring the move is bidirectional (removed from old location, added to new)
• Tests verify both presence/absence in correct section arrays and actual rendering
• Good use of helper function setLiteral() for parsing Set literals from source code

✅ Security & Performance

Security

• Maintains existing permission boundaries - no security regressions
• Proper CSRF protection maintained via useCsrfFetch
• No new attack surfaces introduced

Performance

• Minimal performance impact - just a component relocation
• No additional API calls or data fetching changes
• Existing component caching and optimization preserved

✅ Best Practices Adherence

Repository Guidelines

• Follows CLAUDE.md guidelines for component movement
• Aligns with multi-source architecture principles (global vs per-source)
• Maintains existing i18n key structure to avoid unnecessary churn

React Patterns

• Proper hook usage maintained in PositionEstimationSection
• Appropriate conditional rendering with permission checks
• Navigation integration follows existing patterns

🔍 Minor Observations

Translation Keys (Not an issue, but worth noting)

• The component still uses automation.position_estimation.* i18n keys rather than settings.*
• As noted in the PR description, this is intentional to avoid churning 9 locale files
• Keys still resolve correctly and functionality is unchanged

Test Approach

• Static source testing is a pragmatic solution for large components
• Could potentially be supplemented with integration tests, but current approach is sufficient
• Test placement in src/components/ follows the pattern of testing component organization

📊 Test Coverage Assessment

The test suite comprehensively covers:

1. ✅ Correct section categorization (global vs source)
2. ✅ Component rendering in new location
3. ✅ Navigation link generation
4. ✅ Permission gating verification
5. ✅ Removal from old location
6. ✅ Import statement verification

This level of coverage is appropriate for a component move operation.

✨ Recommendation

APPROVE - This is a well-executed refactoring that:

• Solves a legitimate UX/architectural issue
• Maintains backward compatibility
• Includes appropriate test coverage
• Follows repository conventions
• Has no security or performance concerns

The change makes the UI more intuitive by placing global functionality in the global settings area, which will improve user experience especially for users with limited permissions or when working with MQTT bridge sources.