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 revisionPrevious revision
Next revision
Previous revision
mantisbt:reporting_via_email [2007/04/24 20:15] aristedesmantisbt: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 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 36: 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://
Line 43: Line 49:
  
 http://www.bugzilla.org/docs/3.0/html/api/email_in.html http://www.bugzilla.org/docs/3.0/html/api/email_in.html
 +
 +__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 55: 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.1177460107.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki