v2.0.0

Settings in which every setting does something. The Settings page is rebuilt: an
appearance with named accents, the application's name and images used everywhere, a sign-in
page of your own, an email designer, roles for superusers and API keys, a history of what
backups and cron jobs did, CORS, maintenance, and more of logs, storage and import. Each
installation (the main one and every project) has its own.

Upgrading

Nothing needs doing: existing settings and superusers carry over. What behaves differently:

• The API sends CORS headers, allowing pages on any site, as PocketBase does; slonbase sent
  none before, so browsers refused cross-origin calls. To allow only some sites, list them in
  Settings → Security & limits (security.allowedOrigins).
• Emails are put in a layout (the logo, a card, the application's name and address), unless
  a template is a whole HTML document of its own. Turn it off, or change it, in Settings → Mail
  (mailLayout.enabled).
• Every superuser is an owner until you give them another role, so nobody loses access.
• Two migrations add _slonbase.assets (images, included in backups) and
  _slonbase.job_runs (the jobs' history). A backup made with 2.0 can't be restored by 1.x.
• GET /api/crons items have more fields (description, next, kind, lastRun);
  GET /api/backups items have encrypted and auto.
• The default accent is sage (the colour the dashboard already had); saved colours stay.
• For the Rust library API: RequestAuth has a role field, and logs::cleanup takes the
  maximum number of entries.

Added

• Settings, reorganized. Sections are grouped (Workspace, Delivery, Operations,
  Protection, Data), with a dot on those with unsaved changes. Links to a section (from Health's
  checks, the command palette) keep working.

• Appearance. Settings → Application has cards for the color mode (system, light, dark;
  kept per browser) and thirteen named accents (Sage, Slate, Mauve, Clay, Sand, Teal, Ocean,
  Indigo, Rose, Forest, Amber, Plum, Graphite), each with a light and a dark tone that stay
  readable (WCAG AA) in either theme, or a color of your own, with a preview to try them before
  saving. The accent is the installation's: it applies before the first paint, on the sign-in
  page too, and each project has its own.

• The application's name means something. It names the browser tab (Logs · Acme), the
  sidebar and the sign-in page, besides emails.

• Branding: images and logos. Each installation keeps a library of images (PNG, JPEG,
  WebP, GIF, ICO or SVG, up to 2 MB, up to 100) at /api/branding/assets, and chooses its logo,
  its logo on dark backgrounds and its browser icon from it. Anyone may view an image (the
  sign-in page and emails show them); only superusers upload, rename or delete them, and an
  image the settings use can't be deleted. They live in the database, so they go with backups.

• A sign-in page of your own. Settings → Login screen sets its layout (beside the code
  panel, in a card, or alone), background (plain, a grid or an image), heading, line under it,
  logo, a notice (plain text), up to three links (https: or mailto:) and whether
  "powered by slonbase" shows, with a live preview of the real page.

• A history of what ran. Automatic and manual backups and cron jobs (hooks' cronAdd and
  the backups' schedule) record each run: when, what started it, how long it took, how it
  ended (with the error when it failed) and, for backups, the file, its size and whether it's
  encrypted. The last 500 runs of each job are kept (GET /api/jobs/runs).

• Backups say whether they're encrypted (encrypted, from the file's first bytes, in
  GET /api/backups) and whether they're automatic; the page filters them and shows when the
  next automatic one runs.

• Cron jobs, at a glance: each job's schedule in words ("every day at 03:00"), its next run
  and how its last run went (GET /api/crons has description, next and lastRun), with
  its history.

• File storage shows where files are: the directory on the server (or the bucket), the free
  space there, what the uploads take (measured in the background, by collection) and
  thumbnails, which can be cleared (GET /api/settings/storage).

• CORS. Pages on other sites may call the API, as with PocketBase; Settings → Security &
  limits can restrict that to some origins (security.allowedOrigins). Until now, slonbase
  sent no CORS headers, so browsers refused such calls.

• More of Security & limits: maintenance (the API answers 503 with your message to all but
  superusers and health checks), HTTPS only (Strict-Transport-Security, when the application
  URL is https), and the largest request (128 MB by default, now a setting).

• More of Logs: paths not to log (unless they fail on the server), slow requests logged as
  warnings whatever the minimum level, and a maximum number of entries.

• Import & export: choose which collections to export (system ones too, indented or not, to
  copy or download); an import shows, collection by collection, the fields added, changed and
  removed, the rules and indexes it changes, and what Replace would delete; and the settings
  can be exported and applied elsewhere (without passwords, secrets or images).

• An email designer. Settings → Mail edits the layout around every email and each auth
  collection's messages (verification, password reset, email change, one-time password, new
  sign-in alert) as HTML, with buttons to insert placeholders, a live preview of what the
  server would send (desktop or phone width, in a sandboxed frame that runs nothing), and a
  test send from the collection's own template (the dashboard used to always send the
  superusers').

• A layout around every email (mailLayout, on by default): the logo, a card in the
  accent's color, the application's name and address. A template that's a whole HTML
  document of its own isn't wrapped.

• New placeholders in emails: {APP_LOGO} (the logo, or the application's name),
  {APP_LOGO_URL}, {ACCENT} and {RECORD:field} (the recipient's fields, escaped; hidden
  fields, the password and the token key stay empty). POST /api/settings/mail/preview
  renders an email with sample values.

• Roles for superusers. Each superuser of an installation is an owner (everything, as
  before), an admin (everything but the team, restores and deleting projects), a developer
  (collections, records, files, the SQL console when it only reads, cron jobs) or a viewer
  (looks at everything but backups' files, changes nothing). Roles are checked for every
  request, extensions' routes included; everyone may still sign in, refresh their session and
  change their own password. There's always an owner. Settings → Team lists the superusers,
  adds them and changes their roles (GET /api/team, GET /api/team/me,
  PATCH /api/team/members/{id}).

• API keys (sb_…, sent as a bearer token): for scripts, CI and servers, each acts for the
  superuser who made it, with a role up to theirs, and optionally an expiry date and IPs it
  works from. Only a hash is kept; the key is shown once. They can't make file tokens
  (POST /api/team/keys, DELETE /api/team/keys/{id}).

• Signing in to the dashboard with OAuth2: the sign-in page shows a button per provider
  set up on _superusers; only existing superusers whose verified email matches get in.

• App users: Settings → App users shows the auth collections your application signs its
  users in with: how many users, which ways to sign in are on, which OAuth2 providers are
  configured, and the redirect URL to register with providers.

Security

• Uploaded images can't run anything. An image's type comes from its bytes, not from what
  the upload says it is. SVG images with scripts, event handlers, animations, embedded
  documents, DTDs or links outside the file are refused, and every image is served with
  X-Content-Type-Options: nosniff and a sandboxing Content-Security-Policy.
• Backups' files are for owners and admins, however the request is made (with a file token
  too).

Install

• Docker: ghcr.io/ayeshrodz/slonbase:2.0.0
• Debian/Ubuntu: slonbase_2.0.0_amd64.deb / _arm64.deb
• Fedora/RHEL: slonbase-2.0.0-1.x86_64.rpm / .aarch64.rpm
• Binaries: slonbase-2.0.0-linux-{amd64,arm64}.tar.gz

Verify downloads with sha256sum --ignore-missing -c SHA256SUMS. See the installation guide.