Ben Stull
1dab24eef0
Integrates the multi-project work so far — the §22 design drafts, M1 (the schema spine), and M2 (project-scoped authorization + the §22.7 resolver) — on top of the v0.32.0 retire/§13 changes that landed on main meanwhile. Integration decisions: - Renumbered the M1 projects migration 025_projects.sql -> 026_projects.sql. v0.32.0 shipped 025_retired_state.sql, which rebuilds cached_rfcs and predates the project_id column; running projects *after* the retire rebuild is required so project_id survives on a fresh database (the runner applies *.sql in filename order). Comment/doc references bumped to match. - Resolved the get_rfc conflict in api.py by composing both gates: compute the viewer once, apply the §22.5 visibility gate, then v0.32.0's §13.7 retired-entry owner-only check. - api_graduation.py / api_discussion.py auto-merged cleanly (M2's threaded viewer/visibility gate coexists with the new retire endpoints + retired state). Full suite 401 passed on a fresh DB. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
41 lines
1.6 KiB
Python
41 lines
1.6 KiB
Python
"""Project registry — the §22 multi-project layer.
|
|
|
|
A deployment hosts one or more projects (§22.1). Through Slice M1 the only
|
|
project is the migration-seeded `default` one (the N=1 case, §22.13); the git
|
|
registry mirror that lets a deployment declare more projects lands in M3 and
|
|
will grow this module. For now this holds just the §22.13 step-1 backfill:
|
|
completing the default project's row from deployment config, which pure-SQL
|
|
migration 026 could not read.
|
|
"""
|
|
from __future__ import annotations
|
|
|
|
from . import db
|
|
from .config import Config
|
|
|
|
DEFAULT_PROJECT_ID = "default"
|
|
|
|
|
|
def seed_default_project(config: Config) -> None:
|
|
"""Fill the default project's content_repo from config.
|
|
|
|
Migration 026 seeds `default` with content_repo NULL because SQL cannot
|
|
read the environment. This sets it from META_REPO (the pre-multi-project
|
|
single-corpus repo) the first time the configured app boots, so the row
|
|
accurately names the corpus the existing rows belong to. Idempotent: only
|
|
touches the row while content_repo is still unset, so a later registry
|
|
mirror (M3) that has populated it is never clobbered.
|
|
|
|
The display `name` is deliberately left as-is: the deployment's
|
|
user-visible name lives in the frontend build (VITE_APP_NAME) today and
|
|
moves to the registry + GET /api/deployment in M3 (§22.9); the backend has
|
|
no authoritative name to backfill from yet.
|
|
"""
|
|
db.conn().execute(
|
|
"""
|
|
UPDATE projects
|
|
SET content_repo = ?, updated_at = datetime('now')
|
|
WHERE id = ? AND content_repo IS NULL
|
|
""",
|
|
(config.meta_repo, DEFAULT_PROJECT_ID),
|
|
)
|