mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-02 21:03:34 +03:00
Connor Yoh
4624643289
The self-hosted account-link modal was a bare Supabase login form subtitled "the account this server should bill against", which frames linking as the moment an admin starts paying rather than what they gain by it. Nothing in the product mentioned the free credits, teams, the processor, pipelines or policies, and nothing reassured them that manual PDF tools stay free. Replaces it with a three-step Connect flow on the portal's own FlowModal and StepModalHeader: what you unlock, sign in, then routes into the features just unlocked. All five existing entry points route through UIContext.openLinkModal and so pick this up unchanged. Two copy constraints are load-bearing. The free grant is seeded per team at team creation and is NOT granted by linking, so step 1 states it as a property of a new account and step 3 shows the wallet's real freeRemaining rather than a hardcoded 500. Teams are qualified as free at five users and under, matching the free tier limit the server already reports. SSO is left off the slide until its gating is settled. Also adds accountLinkAvailable to the app config. The account-link endpoints 404 when the feature flag is off, which the client cannot tell apart from "not linked yet", so nothing can prompt anyone to link until this is told to it explicitly. Read from the environment because :core cannot depend on :proprietary. OAuth buttons are now hidden unless VITE_SAAS_OAUTH_ENABLED is set. Supabase honours a redirectTo only when it matches the project's allow-list, and a customer origin never will be, so the round trip finished on the SaaS site and the instance never received a session. Email and password work regardless. Step 2 is isolated in its own component on purpose: steps 1 and 3 do not care how the credential is obtained, so a pairing-code flow can replace the middle step without touching either.