You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 09ac1e0
Browse filesBrowse the repository at this point in the historyBrowse files
Let the maintainer revoke an approval, and refuse duplicate approvals
Once a number was published through spam_numbers_approved.json nothing
could take it back: deleting the entry left the maintainer_review evidence
in the row for two years, and the not-spam candidate filter read raw
sources, so a reviewed row became a candidate whose correction was then
skipped as authoritative. A number listed twice with two dates flipped its
evidence and bumped the database version on every merge.
Approvals are now validated up front. A duplicate number stops the merge
naming it, and so does a reviewed row whose entry was deleted. An entry
with "revoked": true and a revoked_at date strips the review's evidence,
source and description before the quorum recheck; a row nothing else backs
is unpublished, and its community reports go back to the pending ledger as
one report on the row's last day (only within the 30-day window). The
candidate filter reads canonical source ids. Production data merges with
no change.
Tests: new assert_maintainer_approval_can_be_revoked covers revoke, the
filter, duplicates, a deleted entry and unchanged versions on rerun. The
existing broken-approval loop wrote a file holding only the broken entry;
dropping the other reviewed entries is now an error of its own, so the
loop no longer proved the named entry was the fault. Each case now keeps
them listed and checks for its own message.
Copy file name to clipboardExpand all lines: data/README.md
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ This directory contains the spam number database that the CallShield app pulls f
18
18
-`spam_domains_approved.json`: Optional maintainer approval input for domain
19
19
candidates. Add reviewed names to its `approved` array. An invalid shape
20
20
stops the extractor.
21
-
-`spam_numbers_approved.json`: Numbers the maintainer checked by hand, usually a spam report filed as a GitHub issue for a number no imported source covers. Each entry gives the number, a `type`, the `reviewed_at` date, an https `reference` to the report and a note on what the review found. The merge publishes each one with a `maintainer_review` evidence record, and an entry it can't check stops the merge
21
+
-`spam_numbers_approved.json`: Numbers the maintainer checked by hand, usually a spam report filed as a GitHub issue for a number no imported source covers. Each entry gives the number, a `type`, the `reviewed_at` date, an https `reference` to the report and a note on what the review found. The merge publishes each one with a `maintainer_review` evidence record, and an entry it can't check stops the merge. So does a number listed twice. To take an approval back, keep the entry and add `"revoked": true` with a `revoked_at` date. Deleting the entry stops the merge, because it would leave the review in the row
-`not_spam_review.json`: Generated community false-positive review candidates
24
24
-`merged_report_ids.json`: Ids of reports merged in the last 14 days, so a report the app resends after its original was merged counts once. The ids are random and already appear in the report files
@@ -239,6 +239,12 @@ it goes in `spam_numbers_approved.json` with a link to the report. The merge
239
239
then publishes it, keeping the pending community reports in its count, and the
240
240
review is the row's own evidence, so later reports can't demote it.
241
241
242
+
A revoked approval comes off at the next merge. The row keeps whatever its
243
+
other sources say and loses the review's evidence and description. A row the
244
+
review alone was holding up is unpublished, including one that only community
245
+
reports back. Those reports go back to the pending ledger, counted as one day's
246
+
reports on the row's last day, so the usual gate decides whether it returns.
247
+
242
248
Every evidence record carries `expires_at_epoch_ms`, and phones stop matching
243
249
a downloaded number or range once its last record expires, so a row
244
250
stays live while any of its evidence is. The manifest's
Copy file name to clipboardExpand all lines: data/spam_numbers_approved.json
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
{
2
-
"about": "Numbers the maintainer checked by hand against public complaint sites, usually after a spam report filed as a GitHub issue. merge_community_reports.py publishes each one with a maintainer_review evidence record. Every entry needs the number, a type, the review date and a link to the report.",
2
+
"about": "Numbers the maintainer checked by hand against public complaint sites, usually after a spam report filed as a GitHub issue. merge_community_reports.py publishes each one with a maintainer_review evidence record. Every entry needs the number, a type, the review date and a link to the report. One entry per number. To take an approval back, keep its entry and add \"revoked\": true and a revoked_at date.",
0 commit comments