# Applications

Immutable onboarding submissions, the consumer wizard, and back-office review.

Source: https://docs.champagne.dev-ukab.fr/en/applications

An application begins as an anonymous completion of a club onboarding, with no person or
account required. The consumer creates a draft for a club and advances through one
ordered block at a time. Its URL identifies the draft; reading or advancing it also requires its scoped
application token. A new browser session can recover access by verifying the mailbox. Completing the last block submits the application. The back
office lists applications for a club next to the action for editing its onboarding.

Starting an application copies the onboarding revision, questions, options, and signature
documents. Drafts and submitted applications therefore
remain readable when an administrator edits the source onboarding. Answers are keyed by stable
block IDs inside that snapshot.

Every onboarding contains exactly one required **Applicant name** block and one required
**Email verification** block. The entered name is shown in the back office's **Applicant**
column. Before it is completed, the UI displays **Application in progress**.

Payment and document-signature steps are explicit, required after-approval steps. Payment opens
Stripe Checkout for the plan selected in the application and the club's connected merchant. The
step advances only after Champagne receives the signed paid webhook and verifies that exact
application Checkout session. On return from Checkout, payment confirmation uses the scoped
application access token: applicants do not need to sign in as members before their
account setup is complete. While the paid webhook is pending, the consumer checks
every two seconds; an error stops automatic checks and offers a retry. Document signature uploads the snapshotted club PDF to Yousign, redirects
the verified applicant to its hosted signing flow, and advances only after Champagne confirms the
stored Yousign signer is signed. Email verification
sends a random six-digit code that expires after ten minutes. Development messages are
delivered to the local Mailpit inbox printed by `make dev` or `make worktree-up`.

Submitted applications may be **Accepted** or **Rejected**. Both actions require confirmation
in a dialog before any change or email is sent; rejection allows an optional internal reason.
Acceptance atomically creates a person from the name, verified email, and collected address, copies ordinary
answers into additional information, and links that person to the originating application.
Acceptance and rejection send an email to the applicant. A rejection may include an optional
reason, which appears on the application detail page and in its status history.
The current rejection email does not include this internal reason.
Every applicant advance and reviewer update checks the application revision, preventing
two stale clients from silently overwriting one another.

Set `YOUSIGN_API_KEY` in the API's ignored `.env.local` during local development and as a secret
environment variable in hosted environments. Local development defaults to the sandbox URL in
`config.mk`; override `YOUSIGN_API_URL` in `config.local.mk` for another endpoint. Set
`YOUSIGN_API_URL=https://api.yousign.app/v3` in the hosted runtime for a production key. `CONSUMER_ORIGIN` supplies
the exact return origin, and local `.localhost` origins are accepted for development. Yousign
custom redirect URLs require an eligible paid plan. Sandbox requests use Yousign's supported
embedded flow, which emits a completion event before Champagne verifies the signer and returns to
the application; production requests use Yousign's hosted redirects.

See [Application operations](/en/graphql/applications) for the complete API contract.

## Decision history [#decision-history]

The application detail page includes **Status history**, ordered chronologically, with
transition dates, action origins and the reason recorded for a rejection.
A rejected application can be accepted directly after confirmation; accepted applications remain final.
The former **Under review** step is no longer available. Its existing history entries are retained;
applications still in that old state appear as **Submitted** and can be accepted or rejected.

Staff decisions record the authenticated actor ID and name. Applicant access uses
a scoped application token or the linked member session; older actor details may be absent. Older applications display an explicit incomplete-history
notice; no dates or authors are reconstructed. See [Status transitions and history](/en/graphql/applications#status-transitions-and-history)
for the allowed transitions, atomic persistence and API fields.

## Finding applications [#finding-applications]

Use **Filters** beside the search field to select one or more statuses and an optional submission-date
range (UTC). No selected status means all statuses. **Apply filters** updates the list; **Cancel** discards edits; **Reset** clears
the draft filters and takes effect when applied. The button counts active filters.
Filters and name/email search are combined on the server and stored in the page URL.
The list shows up to 200 newest matches and asks you to narrow the search if that limit is reached.