Feature #7257
closed
Feature #6227: Incorporate new info from Negistry into group db and reporting
Feature #7052: Link report to each group which owns it
Store email addresses to which the report was sent
Added by Rajmund Hruška over 3 years ago.
Updated over 2 years ago.
Description
The reports are now linked to multiple groups (#7052). But some groups may have disabled the option for sending emails and some groups may change the reporting email addresses in the future. We should therefore store the information to which email addresses the report was sent to.
- Related to Bug #7220: Erroneous values in mentat_main/reports_events/mail_to added
- Status changed from New to Feedback
- To be discussed changed from No to Yes
Currently, Mentat already stores to which email addresses was the report actually sent. The information is stored in mentat_main
database, table reports_events
, column mail_to
. The only possible issue is that this column stores values from both 'to' and 'cc' headers. Is it OK like this or should the email addresses be separated into 2 columns?
Rajmund Hruska wrote in #note-2:
Currently, Mentat already stores to which email addresses was the report actually sent. The information is stored in mentat_main
database, table reports_events
, column mail_to
. The only possible issue is that this column stores values from both 'to' and 'cc' headers. Is it OK like this or should the email addresses be separated into 2 columns?
I think we have already discussed this, but it got lost in the wells of time.
There are two types of information:
- Which group the report is related to, important for permissions - so members of the group can see the report itself and listed in the Reports view. Here the information about to/cc is not important.
- Who were the real adressees of the report, the real email header. That does not need to be indexable/searchable, just viewable, and has not high prio as a feature. I's the info, which can be crammed into JSON structure within report itself.
So question is what info is mentat_main
/reports_events
/mail_to
related to?
Pavel Kácha wrote in #note-3:
Rajmund Hruska wrote in #note-2:
Currently, Mentat already stores to which email addresses was the report actually sent. The information is stored in mentat_main
database, table reports_events
, column mail_to
. The only possible issue is that this column stores values from both 'to' and 'cc' headers. Is it OK like this or should the email addresses be separated into 2 columns?
I think we have already discussed this, but it got lost in the wells of time.
There are two types of information:
- Which group the report is related to, important for permissions - so members of the group can see the report itself and listed in the Reports view. Here the information about to/cc is not important.
- Who were the real adressees of the report, the real email header. That does not need to be indexable/searchable, just viewable, and has not high prio as a feature. I's the info, which can be crammed into JSON structure within report itself.
So question is what info is mentat_main
/reports_events
/mail_to
related to?
As I wrote in #7220#note-7, mail_to
stores actual email addresses that the report went to.
After discussion:
Emails different from resolved (thus different target than group contact) may arise from mail_to/mail_cc/mail_bcc or mail_test_mode configuration directives, or from redirect field on group reporting settings. All these are meant as admin tool, possibly for debugging or testing, and it does not make much sense to show them to users. In metadata tab of the reports we should thus show resolved emails ("where report should have travelled to"), not overriden ones.
It can be implemented as new column (mail_cc) (straightforward to use, migration needed), or as prefixes ("to:a@b.cz", "cc:c@d.cz") (backwards compatible).
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
- To be discussed changed from Yes to No
I decided to store emails with prefixes in the mail_to column. With that being done, I think this issue is resolved.
- Status changed from Resolved to In Review
- Status changed from In Review to Closed
Also available in: Atom
PDF