Merge branch 'view-ui'

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/api.md

@@ -354,10 +354,20 @@ Responses add `zone`, `view`, `relative_name`, `effective_ttl`, and `text`
 | POST | `/views` | `{"name": "internal", "match_clients": ["homelab", "localhost"], "match_destinations": [], "match_recursive_only": null, "comment": "", "adopt_zones": true}` |
 | GET / PATCH / DELETE | `/views/{id}` | DELETE `?cascade=1` also deletes the view's zones |
 | POST | `/views/order` | `{"ids": [3, 1, 2]}` |
+| PUT | `/views/{id}/color` | `{"color": "green"}`; `""` for the default |
 
 `adopt_zones` moves zones that are not in a view into the new view. named
 requires every zone to be in a view as soon as one view exists.
 
+`color` is how the web UI shows the view: one of `green`, `teal`,
+`purple`, `pink`, `orange`, `yellow`, `red` and `grey`. When it's left out,
+the view uses the link colour. It isn't part of the BIND configuration, so
+`PUT /views/{id}/color` applies at once and creates no changeset. It needs
+write access to the view, and it is logged in the audit log as
+`view.color`. To colour a view that so far exists only in a changeset,
+send the request with that changeset (`?changeset=` or
+`X-Jarl-Changeset`).
+
 ### ACLs and TSIG keys
 
 | Method | Path | Body |

docs/cli.md

@@ -331,6 +331,7 @@ jarl view create external --match-clients any
 jarl view order internal external
 jarl view update external --match-clients "!homelab,any"
 jarl view delete old [--cascade]
+jarl view color internal green                # web UI colour; "default" resets it
 
 jarl acl create homelab 192.168.1.0/24 10.10.0.0/16 localhost
 jarl acl update homelab --add 10.20.0.0/16 --remove 10.10.0.0/16

docs/development.md

@@ -230,6 +230,22 @@ pre-release:
 (`VERSION=0.2.0-rc.1 scripts/gitea-release.sh notes`), and the workflow
 runs it as a check before building.
 
+### Which version a build reports
+
+The footer of the web UI, `jarld version` and `jarl --version` say what a
+binary was built from, linking to it on Gitea:
+
+* **A release**: `make` run on the commit tagged `v<VERSION>` with no
+  tracked file changed. The Makefile then sets `RELEASE_TAG`, and the
+  footer reads "Powered by Jarl v0.2.0", linking to the release. The
+  release workflow sets `RELEASE_TAG` itself.
+* **Any other build**: the commit, which Go records from git: "Powered by
+  Jarl 1a2b3c4d5e6f", linking to the commit. With uncommitted changes it
+  is marked `-modified`. The version commands print `0.2.0 (1a2b3c4d5e6f)`.
+* **No git** (a build from a source tarball): just `VERSION`.
+
+`RELEASE_TAG=v0.2.0 make` forces the first case.
+
 Pushing the same tag again (`git tag -f`, `git push -f`) re-runs it, and
 the script replaces the attachments and packages, so a failed release can
 simply be retried.

docs/views.md

@@ -130,5 +130,10 @@ On the server, `dig -b <source address>` picks which view you test.
   `jarl view list` shows it.
 * Deleting a view is refused while it still has zones, unless you pass
   `--cascade`.
+* Give each view a colour (Views → Edit → Colour, or
+  `jarl view color internal green`) to tell the zones of each view apart
+  in the zone list. The colour only affects the web UI, so it applies at
+  once, with no changeset or deploy. `jarl view color internal default`
+  goes back to the link colour.
 * Zone files are stored per view: `/var/lib/bind/jarl/internal/adbraun.lol.zone`,
   `/var/lib/bind/jarl/external/adbraun.lol.zone`.