A name, a tagline, a logo, a favicon and the launcher icons derived from it; the Middle-earth strings as data; themes as token sets; and a stylesheet for what none of that reaches. All four are on one page, in one settings group. The snapshot is a Jinja global over a process-level cache, because render() has no session and four render paths never reach it at all -- the sign-in page, the error pages, the offline page and the SSE fragments. A context value would have had to be threaded through every one and would still have missed those. It being a global is also what lets mark() branch on an uploaded logo without any of its six call sites learning about branding; the macro that renders the sidebar link is called brandlink now, because a macro imported as `brand` shadows the global for the whole template and took out every page at once. Defaults in code and overrides in the database, as the prompt fragments do, with one difference stated in the module: an empty fragment means off, an empty flavour string means the shipped wording. And blanked rather than dropped -- settings_store.update merges, so an omitted key leaves what was stored last time and "I typed the default back in" would store something different from "I changed nothing". A custom theme sets a handful of tokens and inherits the rest, and the inheritance is a CSS fact: tokens.css matches [data-base="shire"] as well as [data-theme="shire"], so a custom light theme lands on parchment rather than four light colours on near-black. Values are validated on read rather than on save, because a theme written straight into the settings table still has to produce a stylesheet that parses -- a `}` in a value ends the rule and silently breaks every rule after it. The soft variants are derived from the accent, or a changed accent leaves focus rings in the old hue and reads as half-working. /branding.css is a route, not an inline block: an external stylesheet has no HTML context to escape from. The link carries a content hash, so a save is not left to the browser's cache, and it is deliberately outside the service worker's precache list, which is versioned by the release. The instance name moved off /admin/general rather than being duplicated there. An upgrade keeps it: the general row is read as a seed exactly while the branding row has never mentioned the name, which is `key in row` and not `row[key] is truthy` -- the two read alike would resurrect the old name underneath a cleared one. The theme list stops being a hard-coded pair in five places. Every failure mode in that area is silent, so it is driven under a DOM stub as well as tested. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
118 lines
4.6 KiB
HTML
118 lines
4.6 KiB
HTML
{% extends "admin/_layout.html" %}
|
|
{% from "_macros.html" import icon %}
|
|
{% set section = "schedules" %}
|
|
|
|
{% block title %}Scheduling - {{ brand.name }}{% endblock %}
|
|
{% block heading %}Scheduling{% endblock %}
|
|
|
|
{% block admin_content %}
|
|
<p class="admin-lede">
|
|
A <strong>schedule</strong> runs a piece of work because time has passed
|
|
rather than because somebody asked just now — a daily summary, a check every
|
|
Monday, a reminder in an hour. Each one has its own chat and replies into it,
|
|
or files a report. People make their own under <strong>Scheduled</strong>;
|
|
what you decide here is whether the feature exists and what it may spend.
|
|
</p>
|
|
|
|
<div class="alert">
|
|
{{ icon("shield", "icon--sm") }}
|
|
<span>
|
|
This is the one thing here that spends model time with nobody watching. A
|
|
schedule pointed at a chat that can run commands would run them unattended,
|
|
so a scheduled task is never an agent chat — but everything else a model can
|
|
reach, it can reach on a timer. Give <strong>Schedule work</strong> under
|
|
Groups & permissions to the people who should have it; it is off for
|
|
everybody by default.
|
|
</span>
|
|
</div>
|
|
|
|
{% if saved %}
|
|
<div class="alert alert--success">{{ icon("check", "icon--sm") }} <span>Saved.</span></div>
|
|
{% endif %}
|
|
|
|
<form method="post" action="/admin/schedules" class="form-grid">
|
|
|
|
<section class="card">
|
|
<h2 class="card__title">Switch</h2>
|
|
<div class="field">
|
|
<label class="checkbox">
|
|
<input type="checkbox" name="enabled" value="true" {{ 'checked' if values.enabled }}>
|
|
<span>Let scheduled work run</span>
|
|
</label>
|
|
<p class="field__hint">
|
|
Off by default. Turning this off stops everything firing and deletes
|
|
nothing — schedules keep their place and resume when it is turned back
|
|
on.
|
|
{% if total %}
|
|
There {{ "is" if total == 1 else "are" }} {{ total }}
|
|
schedule{{ "" if total == 1 else "s" }} on this instance,
|
|
{{ active }} of them not paused.
|
|
{% endif %}
|
|
</p>
|
|
</div>
|
|
</section>
|
|
|
|
<section class="card">
|
|
<h2 class="card__title">How often it looks</h2>
|
|
<div class="field">
|
|
<label class="field__label" for="tick">Check for due work every</label>
|
|
<input class="input" type="number" id="tick" name="tick_seconds" min="5" max="300"
|
|
value="{{ values.tick_seconds }}">
|
|
<p class="field__hint">
|
|
Seconds. This is how late a run can be, not how often anything happens:
|
|
the finest a schedule can be set to is one minute, so anything under
|
|
that buys nothing. One indexed query per tick.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="field">
|
|
<label class="field__label" for="min-interval">Nothing may repeat faster than</label>
|
|
<input class="input" type="number" id="min-interval" name="min_interval_seconds"
|
|
min="60" max="86400" value="{{ values.min_interval_seconds }}">
|
|
<p class="field__hint">
|
|
Seconds. A floor on how often one schedule may come round. Raise it if
|
|
people are setting things to run more often than the work takes.
|
|
</p>
|
|
</div>
|
|
</section>
|
|
|
|
<section class="card">
|
|
<h2 class="card__title">What it may spend</h2>
|
|
<div class="field">
|
|
<label class="field__label" for="per-user">Schedules per person</label>
|
|
<input class="input" type="number" id="per-user" name="max_per_user" min="1" max="200"
|
|
value="{{ values.max_per_user }}">
|
|
<p class="field__hint">
|
|
Refused at the point of creation, with the reason. Existing schedules
|
|
over a lowered limit keep running; only new ones are refused.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="field">
|
|
<label class="field__label" for="concurrent">Runs at once</label>
|
|
<input class="input" type="number" id="concurrent" name="max_concurrent" min="1" max="20"
|
|
value="{{ values.max_concurrent }}">
|
|
<p class="field__hint">
|
|
Fifty schedules due at nine o'clock must not open fifty replies against
|
|
one endpoint. The rest wait their turn rather than being dropped.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="field">
|
|
<label class="field__label" for="queued">Turns that may pile up in one chat</label>
|
|
<input class="input" type="number" id="queued" name="max_queued" min="1" max="50"
|
|
value="{{ values.max_queued }}">
|
|
<p class="field__hint">
|
|
A schedule that comes round faster than its chat can answer would build
|
|
a backlog for ever. Past this, a run is skipped and says so on the
|
|
schedule rather than joining the queue.
|
|
</p>
|
|
</div>
|
|
</section>
|
|
|
|
<div class="btn-row">
|
|
<button class="btn btn--primary" type="submit">Save</button>
|
|
</div>
|
|
</form>
|
|
{% endblock %}
|