Project

General

Profile

Actions

Feature #7052

closed

Feature #6227: Incorporate new info from Negistry into group db and reporting

Link report to each group which owns it

Added by Rajmund Hruška about 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
04/29/2021
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
To be discussed:
No

Description

Currently, one report is linked to one group in the database. But, as soon as #6227 is finished, the same report will be sent to multiple groups.


Subtasks 1 (0 open1 closed)

Feature #7257: Store email addresses to which the report was sentClosedRajmund Hruška04/29/2021

Actions
Actions #1

Updated by Rajmund Hruška about 3 years ago

  • Target version changed from Backlog to 2.8
Actions #2

Updated by Pavel Kácha about 3 years ago

  • Target version changed from 2.8 to 2.9
Actions #3

Updated by Rajmund Hruška about 3 years ago

  • Status changed from New to In Progress
  • To be discussed changed from No to Yes
Actions #4

Updated by Rajmund Hruška about 3 years ago

  • To be discussed changed from Yes to No

My solution is to create a new table mapping many-to-many relation between report and groups. Based on the meeting from 2021-03-19, I will need to create a script which migrates old reports to match new database schema.

Actions #5

Updated by Radko Krkoš almost 3 years ago

  • Related to Feature #7221: Referential integrity for database arrays added
Actions #6

Updated by Rajmund Hruška almost 3 years ago

  • Status changed from In Progress to Feedback

I noticed that in the original database design (prior to making changes to solve this issue), deleting a group results in deleting reports linked to this group. As now the relationship between groups and reports is many to many, the behavior should be a bit different. The report should only be deleted if all groups linked to that report are deleted. As far as I know, this can only be solved by trigger. Another option is to just keep the reports in the database.

I assume that deleting groups is quite rare. My question is, should I implement this trigger or keep the report even if all groups linked to this report are deleted?

Actions #7

Updated by Rajmund Hruška almost 3 years ago

Rajmund Hruska wrote in #note-6:

I noticed that in the original database design (prior to making changes to solve this issue), deleting a group results in deleting reports linked to this group. As now the relationship between groups and reports is many to many, the behavior should be a bit different. The report should only be deleted if all groups linked to that report are deleted. As far as I know, this can only be solved by trigger. Another option is to just keep the reports in the database.

I assume that deleting groups is quite rare. My question is, should I implement this trigger or keep the report even if all groups linked to this report are deleted?

Actually, I think that implementing a trigger is simpler than implementing handling reports without any groups linked to that report.

Actions #8

Updated by Rajmund Hruška almost 3 years ago

  • Status changed from Feedback to In Progress
Actions #9

Updated by Pavel Kácha almost 3 years ago

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

Actions #10

Updated by Radko Krkoš almost 3 years ago

Pavel Kácha wrote in #note-9:

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

I agree. As a rule of thumb, CASCADE DELETE should be reserved for cases where:
- The referenced data would not be accessible otherwise,
- The data is decomposed into multiple tables, so the record would be incomplete.
Preferably both.

I believe this is neither of those cases.

Actions #11

Updated by Rajmund Hruška almost 3 years ago

Pavel Kácha wrote in #note-9:

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

I thought that you might suggest preserving reports without any groups linked. I will handle it then.

Actions #12

Updated by Rajmund Hruška almost 3 years ago

  • Subject changed from Link report to each group to which it is sent to Link report to each group which owns it
  • Status changed from In Progress to Resolved

Rajmund Hruska wrote in #note-11:

Pavel Kácha wrote in #note-9:

Actually I don't like that destructive behaviour implicitly. Admin may decide to delete group as a simple solution to some screwup ("ok, let's just delete the screwed group altogether and create/import it anew"), and cascading behaviour may not be completely obvious, and after that admin is really screwed. I'd not trigger cascade delete - at most the orphaned reports will stay in db accessible only by admin through mentat/reports/search, and determined admin can repair the screwup by manually reassigning them to some group.

I thought that you might suggest preserving reports without any groups linked. I will handle it then.

I finished implementing this feature and it seems that there is no problem with reports without any groups. In the web interface, such reports have the field with abuse groups empty.

The code is in the same branch as the code for issue #6227 (hruska-feature-#6227-negistry).

Also, this issue deals only with linking abuse groups and reports. The information about which email addresses actually received the report is the subject of issue #7257.

Actions #13

Updated by Radko Krkoš almost 3 years ago

  • Related to deleted (Feature #7221: Referential integrity for database arrays)
Actions #14

Updated by Rajmund Hruška about 2 years ago

  • Status changed from Resolved to In Review

Merged into devel.

Actions #15

Updated by Pavel Kácha about 2 years ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF