SiT! Bugs
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000049SiT!otherpublic2008-07-11 17:292012-02-11 16:59
Reporterkieran 
Assigned Topaulh 
PrioritynormalSeveritymajorReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version3.90beta1Fixed in VersionCurrent GIT 
Summary0000049: Custom incident reference
DescriptionCurrently the incident number in square brackets is used in emails to
identify which incident emails are destined for.

We should allow this to be customised, for example by adding a prefix

[ABC12345]

or by changing the delimiters perhaps

{12345}

Or some other schema.

As it is there is potential for two installations of SiT to get upset if
they send emails to one another.
Tagsmajorimpact
Attached Files

- Relationships
related to 0000204closed Add support for YYMMDDX incident numbers 
related to 0001328resolvedivan Inbound email limited to recognise only up to incident # 99999 
child of 0000010assignedivan [META] Basic Escalations 

-  Notes
User avatar (0000150)
nicdev (developer)
2008-11-03 15:44

 I agree, and our engineers team said the same, that the date in the incident number is very useful. I have seen this implemented somewhere ... but i cannot find it right now..
User avatar (0000919)
ivan (administrator)
2009-04-16 17:10

 Bumping this to 3.50 as there is now a greater possibility that two installations of SiT may talk to each other soon... which could go rather badly due to clashing incident numbers.
User avatar (0004404)
nicdev (developer)
2012-01-11 13:06

 Hi All,

Update to this issue for an event that happened 11/01/2012:

One of our customers uses SiT! and when he sent us a service request, we created his incident from his email (let's say as incident "[5234] Please help me solve my problem").
Our reply was obviously logged in their SiT install and given it's own incident number (Let's say "[5136] [5234] Please help me solve my problem").
When he replied to our initial email, his reply update went into incident 5136 instead of incident 5234. The contact required an urgent response and phoned one hour later quite upset that we had not responded to his incident update (the user that has his incident (5234) is not the same user that owns incident 5136!!
The user was obviously not responsible for this error ...

Apart from this scenario I think other possibilities of errors exist ...
User avatar (0004440)
paulh (administrator)
2012-02-11 16:59

 as of ab895a8183b5185cd89f88acb0e95d9f0131551d this is now complete, you can specify a prefix and define what characters enclose the incident number

- Issue History
Date Modified Username Field Change
2008-07-11 17:29 kieran New Issue
2008-07-17 13:16 ivan Status new => confirmed
2008-07-17 13:16 ivan Target Version => 3.70
2008-11-03 15:44 nicdev Note Added: 0000150
2009-04-16 17:10 ivan Note Added: 0000919
2009-04-16 17:10 ivan Target Version 3.70 => 3.50
2009-05-27 21:46 paulh Relationship added related to 0000204
2009-05-30 14:51 ivan Target Version 3.50 => 3.60
2009-08-21 14:28 kieran Target Version 3.60 => 4.0
2010-04-10 22:56 ivan Status confirmed => assigned
2010-04-10 22:56 ivan Assigned To => ivan
2010-04-10 22:57 ivan Relationship added child of 0000010
2010-11-30 21:06 paulh Relationship added related to 0001328
2011-02-14 13:21 ivan Target Version 4.0 => 3.90beta1
2012-01-11 13:06 nicdev Note Added: 0004404
2012-01-11 13:16 ivan Severity feature => major
2012-01-11 13:16 ivan Tag Attached: majorimpact
2012-01-24 12:32 ivan Assigned To ivan =>
2012-01-24 12:33 ivan Assigned To => paulh
2012-02-11 16:59 paulh Note Added: 0004440
2012-02-11 16:59 paulh Status assigned => resolved
2012-02-11 16:59 paulh Resolution open => fixed
2012-02-11 16:59 paulh Fixed in Version => Current GIT

Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker