User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:reporting_via_email

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
mantisbt:reporting_via_email [2007/04/14 05:51]
aristedes break up into logical unit and add notes
mantisbt:reporting_via_email [2013/12/26 13:05] (current)
vboctor Remove v* and p* bad words.
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 ​links). ​ A company doesn'​t want their customers to login to their bugtracker and find porn and viagra related ​issues.+   * 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). ​ A company doesn'​t want their customers to login to their bugtracker and find spam issues.
  
  
 +__giallu__
 +
 +''​ Do we really think mantis can control/​avoid SPAM when google itself can't? If a company receives spam, the problem is on the mail server, not on the mantis installation.''​
  
 ===== Brainstorming ===== ===== Brainstorming =====
Line 24: Line 27:
    * Support for one email account per project or one for all projects. (//Ari Maniatis// I don't think this is needed ​ - it is trivial for most Mantis admins to arrange for several email addresses to be delivered into the same POP account)    * Support for one email account per project or one for all projects. (//Ari Maniatis// I don't think this is needed ​ - it is trivial for most Mantis admins to arrange for several email addresses to be delivered into the same POP account)
  
 +__giallu__
 +
 +''​Could we start from a tenfold easier scenario like: ability to process an email from the standard input? did I say, pretty please?''​
  
 ===== Annotating tasks (meta-data) ===== ===== Annotating tasks (meta-data) =====
Line 35: Line 41:
      * project.category@bugs.mantisbt.org - creates a new bug in that project and 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 "​Feature Requests"​        * substitute space for underscore character appearing in name, e.g., Feature_Requests becomes "​Feature Requests"​
 +
  
 //Ari Maniatis:// //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/​user can be taught to send emails to a range of complex addresses, then they will probably be able to use a web submission form. Also, in almost every case we need to be able to categorise the task, set priorities, etc ourselves since the customer would mostly get it wrong (everything they submit is super-high priority!). So the workflow involves us editing every incoming task regardless. 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/​user can be taught to send emails to a range of complex addresses, then they will probably be able to use a web submission form. Also, in almost every case we need to be able to categorise the task, set priorities, etc ourselves since the customer would mostly get it wrong (everything they submit is super-high priority!). So the workflow involves us editing every incoming task regardless.
  
-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:+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.
  
-''​[project] my big project''​ +http://​www.bugzilla.org/​docs/​3.0/​html/​api/​email_in.html 
-''​[priority] high''​ + 
-''​[category] documentation''​+__giallu__ 
 + 
 +''​+1 to what Ari said and +100 to using an established format like the one proposed. 
 +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 ===== ===== Replying to existing tasks =====
Line 56: Line 67:
 ''​[bug 1234] broken on IE 7''​ ''​[bug 1234] broken on IE 7''​
 Naturally we'd need to look beyond "​re:",​ "​aw:"​ and similar prefixes. Naturally we'd need to look beyond "​re:",​ "​aw:"​ and similar prefixes.
 +
 +__giallu__
 +''​ 123@b.m.o implies we would need an email address for each bug: not really desiderable ''​
  
    * 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. ​ Hence, the note will be extracted from the top of the message. We should check for and remove the most common reply separators such as "on .+ replied with", etc.    * 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. ​ Hence, the note will be extracted from the top of the message. We should check for and remove the most common reply separators such as "on .+ replied with", etc.
mantisbt/reporting_via_email.1176544289.txt.gz · Last modified: 2008/10/29 04:31 (external edit)