Filter-V2
ProfanityBlocker Release Notes |
Hello there,
We are glad to inform you that the latest version Filter-V2 of ProfanityBlocker is out. Below is the list of JIRA issues that were part of this upgrade.
Summary -
New Feature
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-51 | DeepSense class thresholds, probability tuning for clients | Interpret probabilities from the class result, and allow users to set sensitivity thresholds for how confident and strict the DeepSense filter is, that the content is bad.
|
Done | Dashboard, DeepSense, Filter |
Improvements
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-137 | Redis, celery and Kafka - Database optimisations | With the use of the Chrome extension, we have observed a significant increase in the number of requests made to the filter, often reaching a thousand within a 30-minute span. Improvements:
|
Done | Dashboard, Filter |
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-131 | DeepSense class thresholds needs request history to store thresholds for request history | Since clients can set probabilities for the class result, reproducing results from false positives will require us to know the class thresholds for the request at the time it was made. Save in request history table (DB). Request history is only kept for 30 days.
|
Done | DeepSense, Filter |
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-90 | Better align filter and bot request history recording | Improve synchronization between the filter service and the Discord bot for recording request history. Previously, both the filter service and the Discord bot were independently creating request history entries, resulting in duplicate entries. Furthermore, the fields in these entries did not match, leading to inconsistencies in the displayed data in the request history views. To address this issue, we have implemented a solution. The filter service now includes the request ID it generates, and the Discord bot reads this ID to update the corresponding record with additional information, rather than creating a new entry in the database. This ensures better alignment between the filter service and the Discord bot in recording request history, eliminating duplicate entries and ensuring consistent data in the request history views. |
Done | Discord Bot, Filter |
Tasks
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-81 | PoC: custom model criteria | At a high level: Implement custom model training per client.
As per |
Done | Dashboard, Discord Premium, Filter, Hybrid, InsightGuard |
Subtasks
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-80 | PoC DeepSense | Implement DeepSense filter |
Done | DeepSense, Filter |
Bugs
Priority | Key | Summary | Description | Status | Component/s |
---|---|---|---|---|---|
PB-108 | Filter and bot should return an error code if licence does not exist, and message owner | We now return a service errorcode if the licence does not exist. The bot already had an error code for this - I also tweaked the message, used a different code. |
Done | Discord Bot, Filter |
Looking for more nitty gritty details? Take a look:
Number of issues resolved: 31
Looking forward to hear your feedback.
Thanks,
Team ProfanityBlocker