signal-bot/signal_bot/manage/app.py
Krzysztof kuhy Rudnicki da016e1b94
Some checks failed
CI / check (push) Has been cancelled
CI / web (push) Has been cancelled
!dodaj lands in a queue; the management page approves it into the album
A photo sent to the chat no longer enters the album by itself. pack_add
strips it, checks it against the album and the queue, and writes it to
pending/ with a sidecar naming the people and labels the sender proposed;
the reply is "czeka na zatwierdzenie". The management page lists the queue
above the tagger, with the proposal pre-ticked, and Approve moves the file
in, mints the labels, records approved_at and asks the bot to rebuild its
table through /_reload -- the same publish path every other data change
takes, so PackHolder.reload is gone. A reload the bot refuses is reported
on the page, not rolled back: the photo is in the album either way.

The personal-data gate now reads pending/*.json too, so a label that is
still waiting for approval is forbidden in the tree already. The e2e run
boots the management page beside the bot with the same environment,
proves the queue is stripped and never reaches media/, approves it through
the real routes, and has !losowe answer with the photo afterwards without
a restart; exiftool is found through media_strip.locate() there rather
than PATH, which lacks vendor_perl on Arch.

!gadaj is dropped from !odcisz: it was within a typo of !dodaj, and the
nearest-command suggestion must never be a coin toss.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-04 22:55:39 +02:00

64 lines
2.1 KiB
Python

# Copyright (c) 2026 Krzysztof Rudnicki. MIT licence.
"""The management application, assembled.
A second process rather than more routes on the bot's own app. Two reasons,
and both are about blast radius: this one can rewrite ``.env``, and the bot's
port already serves ``/_selftest``, which posts for real into a real group.
Keeping them apart means the surface that can reconfigure the bot is only
listening while somebody has the page open.
Order is load-bearing. The guard goes on first so it sees every request; the
API routers are registered next; the static catch-all is registered last,
because ``/{path:path}`` would otherwise shadow every route after it.
"""
from __future__ import annotations
from typing import TYPE_CHECKING
from fastapi import FastAPI
from signal_bot.manage import (
assets,
guard,
routes_actions,
routes_album,
routes_aliases,
routes_analytics,
routes_commands,
routes_env,
routes_pending,
routes_status,
routes_suggestions,
)
if TYPE_CHECKING:
from signal_bot.manage.deps import ManageDeps
DEFAULT_CONTAINER = "signal-api"
def build_app(deps: ManageDeps, *, container: str = DEFAULT_CONTAINER) -> FastAPI:
"""The whole page, bound to one bot and one album.
Args:
deps: Everything the app is pointed at.
container: The docker container signal-cli runs in.
Returns:
An application ready for uvicorn, or for a test client.
"""
app = FastAPI(title="signal-bot", docs_url=None, redoc_url=None, openapi_url=None)
guard.install(app, deps.port)
app.include_router(routes_status.router(deps))
app.include_router(routes_env.router(deps))
app.include_router(routes_actions.router(deps, container))
app.include_router(routes_album.router(deps))
app.include_router(routes_suggestions.router(deps))
app.include_router(routes_analytics.router(deps))
app.include_router(routes_commands.router(deps))
app.include_router(routes_aliases.router(deps))
app.include_router(routes_pending.router(deps))
assets.install(app, deps.dist_dir)
return app