Updates for existing issues.
Prev Implementation of email raise/update issues Next

Updates for existing issues.

To be a (possible) reply to an existing issue,the header tags and/or the pseudo header tags are present.

Checks are then made to ensure that the 'extracted' issue details from the message subject or header tags, together with the email address of the sender match with the details recorded in the existing issue within the database, IF it exists. If the 'requested' issue does not exists, or is 'CLOSED' or is not identified as being originally identified as by the message sender, the message is rejected.

There are options to control the strength of the email reply detection. Three options are available:

  • Strict: Accepts only the exact format that email notification uses. Which means "anything [Issue: xxxxxxxxxx] anything here". The full text is required, and the issue id has to be the exact length (def 10 chars). In addition the custom header fields have to be present in the reply. Spaces before and after the issue identifier are optional.

  • Balanced: As Strict only the custom header fields may or may not be present. Spaces before and after the issue identifier are optional.

  • Relaxed: Accepts email notification formatted subjects but also [xxxxxxxxxx] in the subject line. Custom header fields may or may not be present. Spaces before and after the issue identifier are optional.

A lot of email clients (e.g. Thunderbird) by default *appends* replies to the original text, and it is not desirable that this information should be added to existing issues, since it will cause un-necessary duplication. For that reason the message should include a 'reply above this line' (the precise text is a configuration option) string. If a user makes a mistake and does not enter text in the correct manner an empty reply may be generated, and in this situation the message should be discarded.

The message contents are appended to the issue progress field, immediately preceded by a line separator and the date and sender Name (extracted from the message) in HTML format.

[Note]Note

The script only fetched 'UNSEEN' messages from the mail server. In the event of an error being encountered upon processing the message, i.e. An issue may be in the state of being updated (edited), in which case the issue could not be updated, then the message would be left upon the mail server, even if it is configured to remove messages after processing.

[Tip]Tip

The act of retrieving the email message from the server will often cause the email server to mark the message as 'SEEN' or 'READ', which means that if the next 'cron script' run tries to retrieve the message it will not be 'fetched'. To reprocess a message it is necessary to enter the email server and mark the desired messages as 'UNSEEN' or 'UNREAD', in which case they will be picked up by the 'cron script' and re-processed upon its next run.

[Caution]Caution

If the option to delete processed emails is set, then all emails that have been successfully processed will be automatically removed from the email server and will be unavailable for re-processing.

Prev Up Next
Implementation of email raise/update issues Home Custom Fields