Feature #7052
closedFeature #6227: Incorporate new info from Negistry into group db and reporting
Link report to each group which owns it
Added by Rajmund Hruška over 3 years ago. Updated over 2 years ago.
100%
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.
Updated by Rajmund Hruška over 3 years ago
- Target version changed from Backlog to 2.8
Updated by Rajmund Hruška over 3 years ago
- Status changed from New to In Progress
- To be discussed changed from No to Yes
Updated by Rajmund Hruška over 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.
Updated by Radko Krkoš over 3 years ago
- Related to Feature #7221: Referential integrity for database arrays added
Updated by Rajmund Hruška over 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?
Updated by Rajmund Hruška over 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.
Updated by Rajmund Hruška over 3 years ago
- Status changed from Feedback to In Progress
Updated by Pavel Kácha over 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.
Updated by Radko Krkoš over 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.
Updated by Rajmund Hruška over 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.
Updated by Rajmund Hruška over 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.
Updated by Radko Krkoš about 3 years ago
- Related to deleted (Feature #7221: Referential integrity for database arrays)
Updated by Rajmund Hruška over 2 years ago
- Status changed from Resolved to In Review
Merged into devel.
Updated by Pavel Kácha over 2 years ago
- Status changed from In Review to Closed