cgalo5758 1d0e2be9f0 Show the member a paid plan paused under a grant, with Cancel, Keep and Pay invoice
Tenth section of #269's change. When a grant holds the ladder a
subscription pays for and Stripe has confirmed the console's pause, the
member's Products page draws the paid plan's own card: "Paused while
Pro is granted" (M0), with ", payment due" when the subscription is
past_due or unpaid (M1, then Pay invoice and Cancel plan, and no
suspension line), or ", moves to Basic on {date}" when a downgrade was
scheduled before the grant (M8). The card offers Cancel plan, whose
confirmation reads "Plus ends on {date}; Pro stays granted." (M2), or
"Your subscription ends on {date}; Plus stays granted." under a grant
of the subscription's own tier (M9), followed by "The unpaid invoice
stays due." when payment is due (M7). A cancellation scheduled shows
the ladder heading's "Cancels on {date}" badge and Keep plan; on a
ladder a grant holds the badge carries no title, as on a suspended
plan, because the grant keeps delivering past the date. A pause Stripe
has not confirmed keeps the existing lines (M5). A paying row with no
period end shows the existing "Billing details are still being
processed." line and no control.

Cancel plan cancels at the period end (decision 16), Keep plan clears
only cancel_at_period_end, and Pay invoice opens the paying
subscription's open invoice: the plan-change resolver falls back to
the paying subscription when no subscription holds the ladder
(resolveSubscriptionOnLadder), with its product and a suspended
position for past_due, unpaid and paused, and the hosted-invoice route
lists that subscription's open invoices. No move sets or clears the
pause. The Stripe mock answers GET /v1/invoices.

Sandbox check (task 10.1, on a test clock with the console's restricted
key): Stripe accepts cancel_at_period_end=true and then false on a
subscription paused with behavior void and the marker, creates no
invoice, keeps the pause and the marker, and voids the next renewal.

docs/stripe.md and docs/plan-management.md describe the card and its
moves.

Tests: TestMemberPlansGolden states paid-plus-under-granted-pro (with
M0 and Cancel plan), its past-due, cancellation-scheduled,
downgrade-scheduled, paused and unconfirmed forms, granted-plus-own-tier,
and paid-retired-plus-under-granted-pro; the 22 earlier states' .json
gain three zero-valued fields and no .html changes.
TestPaidPlanCardUnderAGrant, TestCancelBodyOnThePaidCard (a tier with
the same name included), TestCancelBadgeOnAPaidCardUnderAGrant,
TestPlansOfferPaidMoveGate's paidDue, TestPlanUnpaidInvoiceForAPausedPlan,
TestCancelAPausedSubscription and TestKeepAPausedSubscription (the
pause stays), TestAPastDuePayingSubscriptionIsNotCancelledImmediately.

Review: no blocker or major. Five minors applied: the own-tier case read
from the card's relation instead of the tier's name, which is no
identity; the cancel and keep tests given the console's pause; the
paying row with no period end; two stale doc comments; and the badge's
title, false on a grant-held ladder, dropped as on a suspended
plan. Nine nits applied; payingByLadder, left test-only, is replaced
by the functions it composed.

Breaks: 22 of 22 caught. Full suite on reset databases: 4930 pass, 14
skip. make screens: no demo state reaches the paid card, so no capture
of this section's changes; hand captures of the seven states and both
confirmations sit beside the change's screens.
2026-10-28 16:50:11 -05:00
…
…
…
…
…
…
…
…
…

member-console

One system for memberships and the hosted services they pay for.

member-console is open-source software for offering hosted services on a paid membership. In one place it handles the pieces that otherwise get stitched together by hand — who each member is, what they're entitled to, what they pay — then turns that into the actual, metered services running on their behalf, kept in sync as members join, upgrade, and leave. New kinds of service attach through a shared contract instead of reshaping how membership or billing work, so the offering can grow on one foundation.

It has two sides: an operator panel where staff run the service, and a member panel where members sign in to manage their own plan and workspace.

Developed by the Wiki Cafe Multistakeholder Cooperative, and built for any organization to run.

Operator overview — at-a-glance deployment counts, recent activity, and system status

The operator landing surface

Status: pre-production. The engine is feature-complete for its first service tiers, but this is not yet a hardened, turnkey deployment. Expect rough edges in first-run setup. docs/production-deployment.md sequences a real path to a running production instance, but it is a self-hoster's guide to follow and adapt, not a one-command install — the test stack remains the fastest way to see the console running. See status/ for the honest state of every milestone.

License: AGPL-3.0-only, with commercial licensing available — see LICENSE and COMMERCIAL.md.

What it does

  • Governance spine — identity (via any OIDC provider) → organization → workspace, with auto-provisioning of a default workspace for new members.
  • Entitlements — grants resolve to numeric limits (e.g. FedWiki site count and storage) materialized per resource pool; plan ladders model upgrade/downgrade paths with a generic transition primitive.
  • Billing — Stripe is the billing execution engine. Products, prices, customers, subscriptions, and invoices are mirrored via a webhook pipeline; the console never holds card data.
  • Integrations — an integration contract (manifest, namespaced resource keys, lifecycle verbs) lets a new hosted service conform without reshaping the operator panel or entitlement layer. FedWiki (wiki site provisioning) and Discourse (forum group membership) are the two conforming integrations today.

Architecture

  • Go 1.23, server-rendered HTMX multi-page app — no SPA framework — under a strict Content-Security-Policy (script-src 'self', style-src 'self'; all JS and CSS is self-hosted, no inline <script>/style=).
  • PostgreSQL with a schema-ownership boundary between core and integrations: the console's own data lives in a single core schema, and each integration owns its schema (fedwiki, discourse, stripe) and its own migration ledger — so adding one renumbers nothing (core-first is the only ordering rule). Queries are generated with sqlc; migrations run with goose.
  • Temporal for durable workflows (provisioning, integration sync, billing sweeps).
  • OIDC for authentication — member-console is identity-provider-agnostic and works with any OIDC-compliant IDP (the test stack ships Keycloak).

Full documentation is indexed in docs/, grouped by audience (developer / admin / user). Highlights: deployment architecture, hosting, building an integration, database management, and Stripe.

Running it

What you need:

  • At least one conforming integration — FedWiki (wiki site provisioning) and Discourse (forum group membership) are the two available today (see "What it does" above); a deployment with neither has no product to actually deliver to a paying member. See fedwiki-setup.md and discourse-setup.md.
  • An OIDC identity provider — any OIDC-compliant provider; the console authenticates members and operators against it and never stores passwords itself. See identity-provider-setup.md.
  • PostgreSQL, Valkey, and Temporal — the console's own data store, session store, and durable-workflow engine (provisioning, integration sync, billing sweeps). See database-management.md and deployment-architecture.md.
  • Stripe — optional, only needed to sell paid products; a deployment offering only free or unmetered products can skip it. See stripe.md.

First run, in order:

  1. Deploy the console and the dependencies above — see docs/production-deployment.md for the sequenced path from a built image to a running instance.
  2. Sign in as an operator (the account holding the operator-member role configured on the identity provider).
  3. Follow the in-app setup checklist at /operator/setup, which walks through everything still needed to reach a deliverable product.

Quickstart (local development)

Prerequisites: Docker (with Compose), Go 1.23+, and make.

The test stack brings up Postgres, Valkey, Temporal, and Keycloak in containers, then runs the console from source against them. All commands run from the test/ directory:

cd test
./bootstrap-stack.sh              # generate a per-worktree .env with collision-free ports
docker compose up -d              # Postgres, Valkey, Temporal, Keycloak
set -a; . ./.env; set +a          # load the generated host ports / secrets
go run .. start --config mc-config.yaml

Integrations are opt-in, not baked into the stack: a FedWiki farm or a live Discourse forum is composed by adding its name to the COMPOSE_PROFILES knob in the generated test/.env (and uncommenting that integration's MC_* block in the same file). The console runs fine with neither.

bootstrap-stack.sh prints the URL table it allocated. With default ports the console is at http://member-console.localhost:9481; sign in to the operator panel as alice / password.

On a fresh stack the console serves before Temporal is up and connects to it in the background, so the first start needs no re-run. Until it connects, the actions that need Temporal answer that they are not available.

See test/AGENTS.md for the full stack contract (idempotency, Stripe webhook constraints, teardown, running multiple worktrees concurrently).

Project status & roadmap

See status/ for the development roadmap, milestones, and notes. Substantial changes are tracked as OpenSpec proposals under openspec/.

Contributing

Contributions are welcome — see CONTRIBUTING.md for the development workflow, building and testing, and the project conventions.

Security

To report a vulnerability, see SECURITY.md. Please do not open a public issue for security reports.

License

member-console is free software, licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-only). See LICENSE for the full text.

AGPLv3 is and will remain the default license for this project. If you use, modify, or deploy member-console — including over a network — you must comply with the AGPLv3, which includes making the corresponding source available to users of the service.

If the AGPLv3 does not fit your needs — for example, you want to embed member-console in a proprietary product or run it as a hosted service without the AGPL's source-sharing obligations — a separate commercial license is available. See COMMERCIAL.md.

As the sole copyright holder, Christian Galo can offer member-console under both the AGPLv3 and separate commercial terms. Contributions are accepted under a Contributor License Agreement that preserves that ability (CLA.md; how to sign is in CONTRIBUTING.md), and commercial licenses fund continued development. Anything already published under the AGPLv3 stays under the AGPLv3; the public license is not withdrawn retroactively.

Third-party components redistributed in this repository keep their own licenses. See NOTICE.

S
Description
Member console application for users to create, acccess, and manage their accounts associated with the Wiki Cafe MSC.
Readme AGPL-3.0
27 MiB
Languages
Go 91.4%
HTML 3.6%
PLpgSQL 2.9%
Shell 1.3%
JavaScript 0.4%
Other 0.3%