Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persönliche Einstellungen für die Blockliste im Anrufbeantworter berücksichtigen #91

Open
haumacher opened this issue Nov 3, 2024 · 0 comments

Comments

@haumacher
Copy link
Owner

Der Anrufbeantworter hat keine Beschränkung bezüglich der Blocklist-Größe. Aber die Mindestanzahl von Votes für eine Nummer, ab der diese als SPAM betrachtet wird, sollte berücksichtigt werden - genauso wie die Einstellung, ob Nummern über Wildcards gesperrt werden sollen.

haumacher added a commit that referenced this issue Nov 30, 2024
When a user wants to detect ranges of phone numbers that obviously
belong to the same SPAM source, there must be an easy way to decide
whether a certain number belongs to such block. To accomplish this, two
additional database tables are maintained with aggregation information.
SPAMREPORTS_10 and SPAMREPORTS_100 with aggregate information of blocks
of size 10 and blocks of size 100 respectively.
haumacher added a commit that referenced this issue Nov 30, 2024
Consolidated number information from SPAMREPORTS, OLDREPORTS, RATINGS,
RATINGHISTORY, SEARCHES, and SEARCHHISTORY into NUMBERS and
NUMBERS_HISTORY. All relevant info for a phone number is now available
from a single database row. This makes the decision which numbers are
"most active" more easy.
haumacher added a commit that referenced this issue Nov 30, 2024
haumacher added a commit that referenced this issue Nov 30, 2024
This makes access to historic information much more easy.
haumacher added a commit that referenced this issue Nov 30, 2024
haumacher added a commit that referenced this issue Nov 30, 2024
haumacher added a commit that referenced this issue Nov 30, 2024
haumacher added a commit that referenced this issue Dec 1, 2024
haumacher added a commit that referenced this issue Dec 1, 2024
* Added logging if creation fails.
* Use generated keys lookup for newly created revision number.
* Adjusted migration setting the sequence correctly starting with the
next revision instead of restarting with 1.
haumacher added a commit that referenced this issue Dec 2, 2024
Since the history is not complete (only 365 days are stored) the
historic information must be reconstructed from current numbers, not
aggregated from first stored revision.
haumacher added a commit that referenced this issue Dec 2, 2024
A number that is found to be part of a number block is only archived, if
all numbers of the block are archived. This is achieved by updating a
"last-ping" column of all numbers in the block for each search or vote
against a number in the block.
haumacher added a commit that referenced this issue Dec 2, 2024
Looking up top current searches must not involve history lookup.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant