Anonymous | Login | Signup for a new account | 2021-01-20 09:05 GMT | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000624 | SiT! | templates | public | 2009-03-31 21:21 | 2011-02-14 13:18 | ||||
Reporter | timfederwitz | ||||||||
Assigned To | kieran | ||||||||
Priority | normal | Severity | feature | Reproducibility | have not tried | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 3.45 | ||||||||
Target Version | 3.90beta1 | Fixed in Version | Current GIT | ||||||
Summary | 0000624: Incident Update Email Template to include the latest update made | ||||||||
Description | I would like a way to include the latest update made to an incident in the email that gets sent out that there was an update to the incident. The only reason I am asking for this feature is because another help desk app I use provides this, and I it very useful. The reason being that I get to see the update in an email instead of having to log into the web site to review what was updated... especially if it is just the customer saying that they need to look into something and get back to me. Also, I have a trigger setup to email when there is an update... but I may be mobile and not have the bandwidth or opportunity to get into the web site and look, yet my email gets delivered to my BlackBerry, so I could read it if it was in the email. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
![]() |
||||||
|
![]() |
|
ivan (administrator) 2009-03-31 21:38 |
Thanks Tim, I can definitely see this being useful |
nicdev (developer) 2009-04-16 18:49 |
Hi Ivan, Not sure if this was forgotten, but it is almost what we wanted for bug 411... It could be nice to have a tickbox (or 2) to say "include last update" OR "include entire case history" ... Thanks |
kieran (administrator) 2009-04-16 20:01 |
This is a fairly simple one, should we limit the amount of updates though? I wouldn't fancy getting trying to read an email with 100+ updates in it? |
(0000923) timfederwitz (reporter) 2009-04-16 20:11 |
If you're looking for user feedback ;-) I like the idea to have checkboxes to 1) enable/disable; 2) Include only latest update; 3) Include entire history (I would probably not use this myself); then possibly a sub-checkbox or field to limit the number of history to include (like, "Last=10" or something) |
nicdev (developer) 2009-04-20 08:29 |
Hi Ivan/Kieran, I am tending to agree with timfederwitz. We have had many discussions in our team about this one, and it seems to remain on the checkbox idea. The most important is selectivity, for eg. The first update is quite important because it has the original claim/complaint of the customer. Then also the entire history (not the reassignments and stuff) is important for referring to another person or engineer not in the sit system. So from our POV, the checkbox idea with the following suggestions: Box 1: Original customer mail Box 2: Last update Box 3: Last 6 correspondences (this one may be configurable by the config page?) Box 4: Entire case history and by default we should not include updates that are hidden from the protal in this equation.. Hope this helps some.. |
ivan (administrator) 2009-04-20 11:20 |
How about 4 new template variables {{firstupdate}} {{lastupdate}} {{recentupdates}} - This one configurable from config page {{allupdates}} That way you can define what you want to show by editing the email template. I'm all for it being configurable but I can't work out where a checkbox could go? |
kieran (administrator) 2009-04-20 12:13 |
Ivan took the words out of my mouth, it's not obvious where to put the checkbox yet. There will be a way to configure things on triggers like this in future but it's a fair bit of work and it won't be this release cycle. |
(0000945) timfederwitz (reporter) 2009-04-20 12:41 |
Ivan's proposal works for me. I don't think a checkbox is necessary (personally). It's just what came to mind when thinking about how to configure it. ;-) |
nicdev (developer) 2009-04-20 13:00 |
For sure, in fact just after posting the note, i was thinking the same thing ;-) In fact this is a better solution because we can pre-make several templates to be selected when we click "email" and then you just pick the correct template from the dropdown list. I second that :-D |
nicdev (developer) 2010-01-14 10:35 |
Hi All, Just to raise this again as it has been along time since it was discussed .. what do you guys think for a target version? |
nicdev (developer) 2010-01-20 08:38 |
As a feedback i have created a few template variables, and they are working fine, but there is another dimension we did not take into account here which became evident once we started testing yesterday. If i send the case history to for instance our R&D team, it works great, but now when the engineer responds by clicking "reply" the entire case history + his comments are put into the case log, and now it becomes a bit difficult ... The case becomes extremely unreadible, and difficult to manage due to the huge updates. So in the end we believe by solving the issue we had (forwarding the entire case history) we have created another bigger problem... Anybody's inputs are welcome. For now we are thinking in the direction of creating a sort of function that creates a pdf of the case history that can be sent as an attachment when the template is selected... |
kieran (administrator) 2010-04-10 21:16 |
Added in git commit http://gitorious.org/sit/sit/commit/b75f4e9279b8c8909ce31428980323f28d783cde [^] Can be used via the {updatetext} trigger variable. By default it will include one update, adding a trigger parameter e.g. 'numupdates = 5' will add 5 and 'numupdates = -1' will add all (use with caution!) |
![]() |
|||
Date Modified | Username | Field | Change |
2009-03-31 21:21 | timfederwitz | New Issue | |
2009-03-31 21:38 | ivan | Note Added: 0000878 | |
2009-03-31 21:38 | ivan | Status | new => confirmed |
2009-04-16 18:49 | nicdev | Note Added: 0000921 | |
2009-04-16 20:01 | kieran | Note Added: 0000922 | |
2009-04-16 20:11 | timfederwitz | Note Added: 0000923 | |
2009-04-16 20:47 | ivan | Relationship added | related to 0000411 |
2009-04-20 08:29 | nicdev | Note Added: 0000938 | |
2009-04-20 11:20 | ivan | Note Added: 0000940 | |
2009-04-20 12:13 | kieran | Note Added: 0000944 | |
2009-04-20 12:41 | timfederwitz | Note Added: 0000945 | |
2009-04-20 13:00 | nicdev | Note Added: 0000946 | |
2010-01-14 10:35 | nicdev | Note Added: 0002284 | |
2010-01-20 08:38 | nicdev | Note Added: 0002293 | |
2010-04-10 21:16 | kieran | Note Added: 0003009 | |
2010-04-10 21:16 | kieran | Assigned To | => kieran |
2010-04-10 21:16 | kieran | Status | confirmed => resolved |
2010-04-10 21:16 | kieran | Resolution | open => fixed |
2010-04-10 21:16 | kieran | Fixed in Version | => Current GIT |
2010-04-10 21:16 | kieran | Target Version | => 4.0 |
2011-02-14 13:18 | ivan | Fixed in Version | Current GIT => 3.90beta1 |
2011-02-14 13:18 | ivan | Fixed in Version | 3.90beta1 => Current GIT |
2011-02-14 13:18 | ivan | Target Version | 4.0 => 3.90beta1 |
Copyright © 2000 - 2021 MantisBT Team |