Feature #7744
closed
Reports with relapse could be linked to reports which started the silencing
Added by Pavel Kácha 6 months ago.
Updated about 2 months ago.
Category:
Development - Core
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.)
- Assignee set to Rajmund Hruška
- Target version changed from Backlog to 2.13.2
- Status changed from New to In Progress
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.
- Status changed from In Progress to In Review
- Status changed from In Review to In Progress
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.
- Status changed from In Progress to Resolved
- Status changed from Resolved to In Review
- Status changed from In Review to Closed
Also available in: Atom
PDF