Owner notices: the stall, one webhook path from env to Discord (#171)

Rollout note: the owner_notices table starts empty, so the first pass after deploy sends for conditions already true — correct per one-row-per-episode; say so rather than have it reported as a bug. Prod step: create the webhook, set DISCORD_WEBHOOK_URL on the deployment, redeploy — unset is silent by design, and without that step the feature ships dark. Security invariants preserved: the webhook address is a secret in the class of TOKEN_KEY (never logged, never on a config-printing line), and the owner gate is unchanged.
2026-08-23 00:06:39 +07:00
parent 5a32943528
commit 7b22460f5e
13 changed files with 785 additions and 18 deletions
@@ -4,14 +4,16 @@ import (
 	"log"
 	"net/http"
 	"strconv"
-	"time"

+	"bookmarkmanager/backend/internal/latest"
 	"bookmarkmanager/backend/internal/store"
 )

 // ownerWindow is the staleness boundary the Series list's "not checked in
-// 12h" filter compares against. Declared once; later admin tickets read it.
-const ownerWindow = 12 * time.Hour
+// 12h" filter compares against. It reads latest.OwnerWindow — the one place
+// the class-level twelve hours lives, shared with the owner-notice
+// conditions (issue #171).
+const ownerWindow = latest.OwnerWindow

 // adminView is the shared shell data for an administrative page and the roster
 // fragment returned after a Reader action.