Some of our SLAs refer to a planned release date in the future (e.g. next release on 2015-12-12) but not a time amount (e.g. 5d)
For minor issues our customers prefer to have them bundled into one release to save acceptance testing efforts.
So a release date will be agreed upon, and the respective issues' SLAs will then be linked to that release date.
This kind of SLA would be broken if either the release (as a whole) is not ready at the scheduled date or the problem is not fixed within the agreed release (but probably later).
=> To configure a certain amount as SLA target would not work: The SLA due date does not depend on the date of a certain state transition, but is exactly the date of the next scheduled release.
- Add a configuration option for the TTS "SLA Value" to use a configurable date field of the issue as SLA due date
- Updates on the values of the above date field should trigger a recalculation of the related SLAs
- Configured "Pause Status" should be ignored when using a fixed due date (as they make no sense with a fixed due date)
- Working hours should also be ignored when using a fixed due date for the same reasons
- For each SLA definition in TTS it is acceptable to have either "SLA Value" or fixed due date configuration available