SiT! Bugs - SiT!
View Issue Details
0000035SiT!incidentspublic2008-07-11 16:172013-07-13 13:13
ivan 
 
normalfeaturehave not tried
confirmedopen 
 
4.0 
0000035: Status changes in body text
As is stands, when a status is changed, an update like the following is put
into the update body:

Status: Active -> Awaiting Customer Action

This is bad because a) we can't search this b) we can't i18n it and c) the
portal users can see these updates, which differ from the external
statuses.

We currently store the currentstatus (most of the time, see SF#1930157) so
we can easily work this out on the fly without entering it into the update
body.


Date: 2008-06-21 19:22
Sender: kieran_hogg
Logged In: YES
user_id=1872958
Originator: YES

was quicker than I thought, test away!
                            

Date: 2008-06-21 19:12
Sender: kieran_hogg
Logged In: YES
user_id=1872958
Originator: YES

Okay, this won't work as it stands, I'll try and fix but it might get
reverted and put off til next release.
                            

Date: 2008-06-21 18:36
Sender: kieran_hogg
Logged In: YES
user_id=1872958
Originator: YES

I've just commited a fix for this, status changes are done in the log
rather than the body now. I'd like some feedback on this as it changes
something that's been the same for a long time. Also, despite the changes
being for i18n purposes, ironically we can't i18n it (without sounding
wooden) until next release, but it wasn't i18ned before so nothing lost.
Providing people like this change, for 3.35, we can do:

"New Status (Active) by Joe Bloggs"
pros: all the words are i18ned
cons: sounds wooden and probably won't make sense when translated

"Set to Active by Joe Bloggs"
pros: reads better
cons: not i18ned
                            
No tags attached.
related to 0000742resolved paulh Consolidate SLA updates and their text 
has duplicate 0000002closed  Seperate incident status 
related to 0001160assigned ivan 2 strings that are supposed to be the same are not 
child of 0001887confirmed  [META] Store more metadata about updates on incidents 
Issue History
2008-07-11 16:17ivanNew Issue
2008-07-17 13:20ivanAssigned To => kieran
2008-07-17 13:20ivanStatusnew => assigned
2008-07-17 13:20ivanTarget Version => 3.40
2008-10-07 10:54paulhNote Added: 0000107
2008-10-07 10:54paulhTarget Version3.40 => 3.45
2008-10-07 11:00ivanRelationship addedhas duplicate 0000002
2008-11-29 23:32kieranTarget Version3.45 => 3.50
2009-05-20 13:11ivanNote Added: 0001085
2009-05-20 13:11ivanSeveritytweak => feature
2009-05-23 17:48kieranNote Added: 0001093
2009-05-23 17:48kieranAssigned Tokieran =>
2009-05-23 17:48kieranTarget Version3.50 =>
2009-06-18 09:27kieranRelationship addedrelated to 0000742
2010-03-20 11:57ivanRelationship addedrelated to 0001160
2010-04-02 13:27paulhStatusassigned => confirmed
2010-04-10 20:08ivanTarget Version => 4.1
2011-02-14 13:54ivanTarget Version4.1 => 3.90beta1
2011-04-18 20:35paulhNote Added: 0003758
2011-07-05 12:15ivanNote Added: 0004092
2011-07-05 12:15ivanTarget Version3.90beta1 => 4.0
2013-07-13 13:13paulhRelationship addedchild of 0001887

Notes
(0000107)
paulh   
2008-10-07 10:54   
Could probably come up with something fancy using the incidentstatus on updates though need to be careful of:

* reverse order logs
* Paging, would need to get one either side and only show some
(0001085)
ivan   
2009-05-20 13:11   
Changing this to a feature request, it's not really a bug is a change of design
(0001093)
kieran   
2009-05-23 17:48   
Not a priority atm.
(0003758)
paulh   
2011-04-18 20:35   
1a810ee895c937780de6969933e53de99b4b47ac goes someway to not hard coding the SLA update sin the body
(0004092)
ivan   
2011-07-05 12:15   
Bumping to v4.0 to help us meet our Roadmap targets for 3.90