pal-e-docs

Review: App Store rejection: Register button error on iPad (Guideline 2.1(a))

review-1684-2026-07-03 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type (Bug)
  • [x] Lineage
  • [x] Repo
  • [x] What Broke
  • [x] Repro Steps
  • [x] Expected Behavior
  • [x] Environment
  • [x] Acceptance Criteria
  • [x] Related
All required sections for template-issue-bug are present and well-written.

Traceability

  • [x] story:app-store-submission label present
  • [ ] story note MISSING — [SCOPE] No app-store-submission entry exists in the project-landscaping-assistant user-stories section. Create user story entry on project-landscaping-assistant.
  • [x] arch:keycloak label present
  • [ ] arch note MISSING — [SCOPE] No arch-keycloak note exists in pal-e-docs. Create architecture note arch-keycloak for the Keycloak realm/client/theme component.
  • [x] Forgejo issue — #290, open

File Targets

  • [x] docs/app-store-review/2026-07-02-rejection-v1.0.md — verified: exists, documents all three rejection issues including the Register button error (Issue 2)
  • [x] keycloak-theme/landscaping/login/resources/css/login.css — verified: exists (340 lines). Styles the #kc-registration link but does NOT hide it. Also styles #kc-register-form::before with the plant icon, meaning the registration form is part of the themed experience.
  • [ ] Keycloak realm config — ISSUE: The recommended fix (registrationAllowed: false) lives in pal-e-services/terraform/k3s.tfvars, not in this repo. No specific file path given in the issue.

Repo Placement

MISMATCH. The issue says ### Repo: ldraney/landscaping-assistant and is filed on that repo. However, the recommended fix ("disable registration in Keycloak realm settings") is a Terraform change in pal-e-services/terraform/k3s.tfvars (line ~72: registration_allowed = true). Two possible fix paths exist:
  • Terraform fix (pal-e-services): Set registration_allowed = false in k3s.tfvars, then tofu apply. This removes the Register link at the Keycloak realm level.
  • CSS fix (landscaping-assistant): Add #kc-registration { display: none !important; } to keycloak-theme/landscaping/login/resources/css/login.css, then deploy the updated ConfigMap via pal-e-platform. This hides the link visually but leaves registration enabled.
Either way, at least two repos are involved. If option 1, the issue should be filed on pal-e-services (or a companion issue created there). If option 2, the theme CSS change is in landscaping-assistant but the ConfigMap deploy requires pal-e-platform. The issue needs to clarify which fix path and list all affected repos.

Dependencies

  • Board item #1683 (Forgejo #289) — sibling App Store rejection bug (arch:ios-pipeline), in backlog. No blocking relationship.
  • Board item #1685 (Forgejo #291) — sibling App Store rejection feature (story:app-store-submission), in backlog. No blocking relationship.
  • Board item #1507 (pal-e-services#122, done) — previous Keycloak client config fix (root_url update). NOT a duplicate — different issue.
  • No items currently in in_progress that block or are blocked by this ticket.

Acceptance Criteria

Three criteria listed. Assessment:
  • "No Register link/button visible on Keycloak login page" — verifiable by navigating to the login page
  • "Login flow works correctly on iPad (no error messages)" — verifiable but requires iPad or iPad simulator, which is appropriate given the rejection context
  • "Existing login with demo credentials still works" — verifiable via standard login test
Missing criteria:
  • Update docs/keycloak-setup.md to reflect the registration policy change (currently documents registration_allowed = true as intentional)
  • Clean up theme CSS if registration is fully disabled (remove #kc-register-form::before styling on line 122)

Blast Radius

ARCHITECTURAL CONFLICT. The ticket proposes disabling registration, but docs/keycloak-setup.md (line 83-84) explicitly documents registration_allowed = true as an intentional design decision:
"registration_allowed = true: new users self-register as clients (the default role on signup per user-stories-auth.md). This is the 'solo client' onboarding flow."
docs/user-stories-auth.md also references the Client role as "Default role on signup," implying self-registration is part of the product design.
Disabling registration would abandon the client self-registration flow entirely. This may be acceptable (the app currently manages users via admin), but the ticket does not acknowledge this tradeoff. A human decision is needed: is self-registration being deferred or permanently removed?
If the intent is to defer (re-enable later when registration works correctly), the CSS hide approach is safer. If the intent is to remove permanently, the Terraform approach is correct but requires doc updates across keycloak-setup.md and user-stories-auth.md.

Decomposition Assessment

1-2 file targets across 1-2 repos, 3 acceptance criteria, estimated agent work under 5 minutes. No decomposition needed.

Recommendation

  • [SCOPE] Human decision needed: Is client self-registration being permanently removed or temporarily deferred? This determines the fix path (Terraform vs CSS) and documentation scope. docs/keycloak-setup.md and docs/user-stories-auth.md both document self-registration as intentional.
  • [BODY] Clarify fix path: Terraform (registration_allowed = false in pal-e-services) vs CSS (#kc-registration { display: none } in landscaping-assistant). List all affected repos for the chosen path.
  • [BODY] Add acceptance criterion: update docs/keycloak-setup.md registration_allowed rationale to reflect the new state.
  • [BODY] If Terraform path chosen, file a companion issue on pal-e-services or move this issue there.
  • [SCOPE] Create user story entry app-store-submission on project-landscaping-assistant user-stories section.
  • [SCOPE] Create architecture note arch-keycloak for the Keycloak realm/client/theme component.