(MoSCoW method)

MUST

• basic happy path:
  1. Someone modify an artifact, I receive a notification.
  2. In my MUA I reply to the email by writing a comment.
  3. The email is sent and after delivery a new changeset is created with the comment I just entered, as if I were using the web ui.
• the emitter is identified via a token as the "Form" header can be forged
• it ignores the update of the artifact if the token validation is failing
• This feature is enable/disable at site level

SHOULD

• It should treat the message as text/plain or html according to sent mail
• It strips the quoted content (most users won't remove the tuleap notification message)

COULD

This is not part of estimation

• the emitter can revoke its token
• send a bounce to the emitter if the update fails (expired token)
• be packaged (rpm + deb)

WONT

• create new artifacts
• update the fields

What headers have to be sent

Emails sent from Tuleap contains those headers:

    MessageID: userid-artifactid-hash-randomid@tuleap.tld
    Reply-to: artifacts@tuleap.tld

When user reply to the message, the reply contains a reference to the MessageID (tested with mutt, to be tested with outlook, thunderbird and gmail).

   References: <userid-artifactid-hash-randomid@tuleap.tld> <…> <…>

Then just add an entry in aliases to be able to parse the incoming email.

    forge__XXXX: "| /path/to/script/… "

How to generate the hash

The hashish email is given by the class Tracker_Artifact_MailGatewayRecipientFactory.

Change on trackers

Mail generation in trackers must be done user by user instead of "group of user"