Feature #7744
openReports with relapse could be linked to reports which started the silencing
0%
Description
Each report creates record(s) in relapse table. If the problem is not solved during silence period (the same record is hit during relapse period), the new report is generated during next regular report period. This report could bear the References heather with Message-ID of the original report (which spawned relapse table records).
(Also, it could reference it on the web version.)
Updated by Rajmund Hruška about 1 month ago
- Assignee set to Rajmund Hruška
- Target version changed from Backlog to 2.13.2
Updated by Rajmund Hruška about 1 month ago
- Status changed from New to In Progress
Updated by Rajmund Hruška about 1 month ago
I am not sure how to solve some edge cases.
For example, for a given source address there is generated report A with event class 1. A few minutes later reporter generates report B with event class 2. One week later (after thresholding period ends) there is report C, which contains events with both event class 1 and event class 2. Now which report it should reference? Both? I don't know how will the mail agents behave when email references 2 unrelated older emails.
Updated by Rajmund Hruška about 1 month ago
- Status changed from In Progress to In Review
Updated by Rajmund Hruška about 1 month ago
- Status changed from In Review to In Progress
Updated by Pavel Kácha about 1 month ago
I'm afraid this won't work (correctly) for email references/in-reply-to. In theory, you can have arbitrarily complex digraph made of references in email, in reality the maximum clients can do is tree (threads). I'm afraid in case of ambiguity, the mail client will take the first (in an arbitrary client notion of "first") thread match and run away with it.
Relapse-treshold link could work in web interface, where class sections can bear a hyperlink to the original culprit.
I'm afraid the most we can get from mail threading is to link together the same IP within the "case open" timeframe and shrug it off.
Updated by Rajmund Hruška about 1 month ago
- Status changed from In Progress to Resolved