Skip to content

fix(apply): start community applications from the selected organization - #472

Open
elliotBraem wants to merge 1 commit into
mainfrom
fix/apply-org-first-form
Open

elliotBraem wants to merge 1 commit into
mainfrom
fix/apply-org-first-form

Conversation

@elliotBraem

Copy link
Copy Markdown
Contributor

Problem

Starting a community still ended on the Web Address field and
"An organization already uses this address. Choose another one." even
though #466 and #468 merged. Those PRs made the form tolerate a slug
collision with the applicant's own organization, but kept the
slug-input-first design:

  • Name prefill only happened when arriving with ?org= — every other
    entry point (nav, landing page, dashboard next steps, proposals page)
    links to bare /apply, so nothing was prefilled.
  • The session's active organization was never consulted; linking
    only kicked in after the user typed/derived a matching slug, and the
    checkSlug query raced the ownership lookup in between, flashing the
    "address is taken" error.

What changed

  • /apply resolves the applying organization up front: the ?org=
    parameter first, otherwise the session's active organization.
  • Eligibility = active status, not personal, no community already bound
    (communityProposalId), and the applicant is an owner (via
    listMembers).
  • Eligible org → name prefilled (editable), slug locked to the org
    slug, payload submitted with orgId, and the web address rendered as
    static text below the name (<slug>.<gateway>), not an input.
    checkSlug never runs, so the taken-address error is impossible.
  • Ineligible selection (personal workspace, already a community, or
    not the owner) → a "Choose an organization" prompt linking to the
    organizations page, instead of a confusing free-form slug field.
  • No organization selected → the plain free-form form with the
    existing availability checks (the nav "Start a community" bootstrap
    path for applicants with no organization).
  • A loading gate removes the query-race flashes (org/members loading ±
    checkSlug returning "taken" in the gap).
  • The "Use a different address" unlock and its i18n key were removed;
    added apply.organization.pickPrompt in en/es/fr/zh.

Tests

  • Split the suite into org-linked mode (prefilled name, locked address
    rendered as text, no checkSlug, orgId in the payload, default
    active-org path and ?org= path) and free-form mode (taken-slug
    error, no orgId, revision/legacy-org retention).
  • New prompt tests for the ineligible-org and not-owner cases.
  • pnpm run typecheck, pnpm run lint, and the full ui suite
    (1129 tests) pass.

/apply now resolves the applying organization up front — the ?org=
parameter first, otherwise the session's active organization — instead
of reactively linking whatever the user happens to type into the web
address field. An eligible org (active, not personal, no community
bound, applicant is owner) prefills the name, locks the submission to
its slug, submits the payload with orgId, and renders the resulting
web address as static text below the name instead of an input, so the
"An organization already uses this address" error can no longer
appear for the applicant's own organization. An ineligible selection
prompts the applicant to pick another organization rather than
falling back to a confusing free-form slug field; applicants with no
organization keep the plain form and its availability checks.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant