mantisbt:reporting_via_email
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:reporting_via_email [2006/12/10 10:24] – apang | mantisbt:reporting_via_email [2013/12/26 13:05] (current) – Remove v* and p* bad words. vboctor | ||
---|---|---|---|
Line 7: | Line 7: | ||
* Making sure that users don't spoof the email FROM address to impersonate other users. | * Making sure that users don't spoof the email FROM address to impersonate other users. | ||
* Support different types of email formats and protocols (e.g. POP3). | * Support different types of email formats and protocols (e.g. POP3). | ||
- | * Making sure a company keeps control on the issues in their bug tracker (i.e. make sure no one can report a single issue that has viagra | + | * Making sure a company keeps control on the issues in their bug tracker (i.e. make sure no one can report a single issue that has spam links). |
+ | |||
+ | __giallu__ | ||
+ | |||
+ | '' | ||
===== Brainstorming ===== | ===== Brainstorming ===== | ||
- | * Support some sort of way to annotate email messages (e.g. setting attributes other than summary, description and project). | ||
- | * Disallow/ | ||
- | * Unknown users should require a reply validation hash to prevent spamming of the issue tracker. | ||
* The reporting by email feature should be disabled by default. | * The reporting by email feature should be disabled by default. | ||
- | * Ability to retrieve email messages from POP3 accounts. | ||
- | * Support for one email account per project or one for all projects. | ||
* Use one dummy account to associate with all emails, in this case the originating email address should be included in the issue description. | * Use one dummy account to associate with all emails, in this case the originating email address should be included in the issue description. | ||
* When an event triggers a notification to the reporter of the issue, this should cause an email to be sent to the email address from which the issue was reported. | * When an event triggers a notification to the reporter of the issue, this should cause an email to be sent to the email address from which the issue was reported. | ||
- | * If a user replies to a notification related to an issue, then the new part in the reply should be added as a note. Inline, replies are not supported. | ||
- | * Erring on the side of caution, if there are inline replies, the entire message should be stored. | ||
* Attachments to emails or replies to notifications should be added as attachments. | * Attachments to emails or replies to notifications should be added as attachments. | ||
* Handle mime/ | * Handle mime/ | ||
+ | |||
+ | ===== Incoming email ===== | ||
+ | |||
+ | * Ability to retrieve email messages from POP3 accounts. | ||
+ | * Support for one email account per project or one for all projects. (//Ari Maniatis// I don't think this is needed | ||
+ | |||
+ | __giallu__ | ||
+ | |||
+ | '' | ||
+ | |||
+ | ===== Annotating tasks (meta-data) ===== | ||
+ | |||
+ | A mechanism to allow various fields (project, category, priority, etc) to be set in a task would be useful. | ||
+ | |||
+ | * Support some sort of way to annotate email messages (e.g. setting attributes other than summary, description and project). | ||
+ | * Using a catch-all Mantis email address, route email by destination address: | ||
+ | * new@bugs.mantisbt.org - creates a new bug (default project) | ||
+ | * project@bugs.mantisbt.org - creates a new bug in that project, default category | ||
+ | * project.category@bugs.mantisbt.org - creates a new bug in that project and category | ||
+ | * substitute space for underscore character appearing in name, e.g., Feature_Requests becomes " | ||
+ | |||
+ | |||
+ | //Ari Maniatis:// | ||
+ | I don't believe the above is particularly important. The main use for email submission is for customers who can't be expected to use a task tracking system, particularly when the tasks are system admin or sales requests. If the customer/ | ||
+ | |||
+ | If automated collection of this metadata is important, I'd suggest a template block at the top of the incoming email rather than trying to overload the email address with meaning. In fact, even better would be to follow the existing Bugzilla format. It has been well thought through and the compatibility would be useful. | ||
+ | |||
+ | http:// | ||
+ | |||
+ | __giallu__ | ||
+ | |||
+ | '' | ||
+ | Moreover, I wonder how you can expect a sysadmin to create all those email addresses just for mantis usage. IMHO everything should work with a single email address | ||
+ | '' | ||
+ | |||
+ | ===== Replying to existing tasks ===== | ||
+ | |||
+ | 123@bugs.mantisbt.org - comments and attachments to issue 000123 | ||
+ | * permits email conversation by replying to (or CC' | ||
+ | * simplifies code for email-to-bugid lookup (performance) | ||
+ | * explicit references handles cases where subject line is changed/ | ||
+ | |||
+ | //Ari Maniatis// | ||
+ | Again, rather than overloading the email address with meaning, I'd suggest overloading the subject. There is considerable precedent for this approach: | ||
+ | '' | ||
+ | Naturally we'd need to look beyond " | ||
+ | |||
+ | __giallu__ | ||
+ | '' | ||
+ | |||
+ | * If a user replies to a notification related to an issue, then the new part in the reply should be added as a note. Inline replies are not supported. | ||
+ | * Erring on the side of caution, if there are inline replies, the entire message should be stored. This might be difficult to detect since many mailers reformat the quoted text considerably (eg. Outlook ugh...). Once solution is to put " | ||
+ | |||
+ | ===== Identifying users ===== | ||
+ | |||
+ | * Preference to disallow/ | ||
+ | * Unknown users should require a reply validation hash to prevent spamming of the issue tracker. | ||
* Support looking up a Mantis account based on an email. | * Support looking up a Mantis account based on an email. | ||
* In the case where there are multiple users with the same email, then we should do the following: | * In the case where there are multiple users with the same email, then we should do the following: | ||
Line 29: | Line 83: | ||
* Prefer accounts that were used to logged in rather than the ones that never logged in. | * Prefer accounts that were used to logged in rather than the ones that never logged in. | ||
* Select the account with least privilege, this is to handle the scenario where a user has an administrator and a developer or manager account. | * Select the account with least privilege, this is to handle the scenario where a user has an administrator and a developer or manager account. | ||
- | * When a user reports | + | * When a user reports |
* An idea to avoid spam is to send back an email that requests a certain interaction that the user needs to do. This would probably stop bots but not manual spamming. | * An idea to avoid spam is to send back an email that requests a certain interaction that the user needs to do. This would probably stop bots but not manual spamming. | ||
* Submissions from unregistered users: | * Submissions from unregistered users: | ||
Line 35: | Line 89: | ||
* Email address verification through confirmation email or PGP signature (if message was signed) | * Email address verification through confirmation email or PGP signature (if message was signed) | ||
* Restrict anonymous notes/ | * Restrict anonymous notes/ | ||
- | * Using a catch-all | + | |
- | * new@bugs.mantisbt.org - creates | + | //Ari Maniatis:// |
- | * project@bugs.mantisbt.org - creates a new bug in that project, default category | + | * Why do multiple Mantis users have the same email address? Can it be made a requirement |
- | | + | |
- | * substitute space for underscore character appearing in name, e.g., Feature_Requests becomes " | + | |
- | * 123@bugs.mantisbt.org - comments and attachments | + | |
- | * permits | + | |
- | * simplifies code for email-to-bugid lookup (performance) | + | |
- | * explicit references handles cases where subject line is changed/ | + | |
mantisbt/reporting_via_email.1165764298.txt.gz · Last modified: 2008/10/29 04:31 (external edit)