PP-4542 F-012: keep a Settings support path when the triage bot is disabled#1054
Open
mauricecarrier7 wants to merge 1 commit into
Open
PP-4542 F-012: keep a Settings support path when the triage bot is disabled#1054mauricecarrier7 wants to merge 1 commit into
mauricecarrier7 wants to merge 1 commit into
Conversation
…+ legacy email when triage bot OFF `TPPSettingsView.supportSection` only rendered a Support section when `RemoteFeatureFlags.shared.isTriageBotEnabled`. The production Firebase default for `triage_bot_enabled` is FALSE, so in production the Support section vanished entirely, leaving users with no app-level support path. Add a `SupportSectionDecision` seam — a pure, fixture-free decision that maps (isTriageBotEnabled, currentAccount/supportEmail) to `.triageBot` or `.legacyEmail(address:)`. The section now ALWAYS renders: - bot ON: unchanged "Get Help" -> TriageBotSupportView row (byte-for-byte). - bot OFF: legacy "Report an Issue" row -> ProblemReportEmail.beginComposing, addressed to the current account's supportEmail, else the general fallback support@thepalaceproject.org. Empty/nil email also falls back, never a no-op. beginComposing already alerts when mail isn't configured, so the row is always safe to offer. Tests (PalaceTests/Settings/SupportSectionDecisionTests) pin all four branches as behavior assertions, incl. the critical no-supportEmail-still- reachable case. Hand mutation-verified: removing the `!email.isEmpty` guard kills the empty-email test; inverting the bot gate kills 4/5. **Scope:** Palace/Settings/NewSettings/TPPSettingsView.swift (seam + else branch + presentLegacyReportIssue/topViewController helpers) and the new test file. No change to ProblemReportEmail, RemoteFeatureFlags, or FirebaseManager. Bot-ON path verified byte-for-byte unchanged. **Not done:** no simdrive E2E pass (SwiftUI body not driven); decision covered by unit tests at the production seam. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🏗️ CodeAtlas Ledger Analysis✅ All Checks Passed♿ Accessibility (via AccessLint)
✅ No accessibility issues detected 🧪 Test Coverage (via QAAtlas)
🏛️ Architecture Analysis
🔍 Reachability Analysis
✅ No dead code detected 📊 0 files analyzed | 📦 Download Full Report Powered by CodeAtlas Ledger |
🧪 Unit Test Results📊 View Full Interactive Report ❌ 3 TESTS FAILED7131 tests | 7028 passed | 3 failed | 100 skipped | ⏱️ 7m 43s | 📊 98.6% | 📈 47.8% coverage Tests by Class — 821 classes, 3 with failures
Failed Tests (click to expand)📊 Testing Coverage BreakdownUnit Test Line Coverage (testable surfaces): 47.8% Total coverage incl. UI/lifecycle: 46.0% (18 files excluded from testable denominator — see
🔗 Interactive HTML Report | CI Run Details 📦 Downloadable Artifacts
|
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.
Problem
TPPSettingsView.supportSectionwrapped the entire main-Settings "Support" section inif RemoteFeatureFlags.shared.isTriageBotEnabledwith noelse. Thetriage_bot_enabledFirebase flag defaults to false in production (FirebaseManager.swift:105), so in production the Support section never appears — and a patron on a library without asupportEmail/supportURLhas no in-app support path at all. A kill-switch should degrade to legacy support, not delete the entry point.(Not a strict regression vs 3.1.0 — main Settings had no Support section then either — but #1032 shipped a support feature that is invisible in production with no fallback. Caught during PP-4542 manual review.)
Fix
Introduced a pure, testable seam
SupportSectionDecision.decide(isTriageBotEnabled:supportEmail:):.triageBot(the existing "Get Help" →TriageBotSupportViewrow, byte-for-byte unchanged)..legacyEmail(account.supportEmail ?? "support@thepalaceproject.org")→ a "Report an Issue" row that opens the legacyProblemReportEmailcompose flow (which already handles the no-mail-configured case with an alert).The Support section now always renders, so support is reachable for every library/config.
Tests (
SupportSectionDecisionTests, 5).triageBotregardless of email (legacy not shown)support@thepalaceproject.org(the critical "support still reachable" case)** TEST SUCCEEDED **(5/5). Mutation surface isif let/bool (not auto-mutable); hand-verified by neutralizing the fallback and the flag check → tests fail. DoD checks (name-vs-body, blast-radius, superpartner) exit 0. Bot-ON path confirmed unchanged via diff.Jira: PP-4542 (F-012)