From 5f1afde64eb682489ad120bd9490c67e91a301ad Mon Sep 17 00:00:00 2001 From: MrAlders0n Date: Sun, 2 Aug 2026 10:04:36 -0400 Subject: [PATCH] docs(admin): say what pending state actually costs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "This can cause data inaccuracies. Use with caution." named no consequence, so an admin had nothing to weigh. Replaced with the real cost: a Pending repeater doesn't associate coverage, so pings heard while it waits stay unlinked — and approving it later doesn't backfill them, which is the part that bites. Points at Reassociate Repeater for recovering them. Matching change made to both pending help texts in the panel (dev 24aa606). Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01KojjSrgSQQJW7Z8b3eakEA --- docs/admins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admins.md b/docs/admins.md index 0743b96..47f42e5 100755 --- a/docs/admins.md +++ b/docs/admins.md @@ -320,7 +320,7 @@ That catalog is what makes [Pending Repeater Links](#pending-repeater-links) wor When enabled, newly discovered repeaters will enter a **Pending** state instead of **Active**. Pending repeaters are hidden from the map until an admin reviews and approves them, and are resolved automatically once they have been in the queue for 3× the stale timer — see [Pending repeater resolution](#pending-repeater-resolution) for exactly how that decision is made. In multiregion mode, this setting is configured per-region under Region-Specific Settings. !!! warning "Data Inaccuracy Warning" - New repeaters will not display on the map until approved. This can cause data inaccuracies. Use with caution. + Pings are not associated to a repeater until it has been approved and set to **Active**. Any coverage heard while it sits Pending stays unlinked, and approving it later does not backfill those pings — use **Reassociate Repeater** in the Tools tab if you need them attached. #### Disable Duplicate ID Detection Logic