Recently we had subtickets linked to a parent ticket.
The parent ticket was updated through the mail to ticket extension.
The user/contact linked was correct.
However, the logic in the datamodel adds the actual text from the latest entry under the user who triggers the update (which, in the case of our cron job, is my account). So instead of the caller's account, the "cron job user account" gets linked.
Below the relevant part which causes this incorrect behavior.
It may also go the other way (child > parent ) if I'm not mistaken.
To broaden the discussion: are there plans to revise the logs?
I wrote a custom handler to even just be able to sort/reorder a set of log entries.
It would make more sense if they're stored as separate records rather than one big field?
public function UpdateChildRequestLog() { $oLog = $this->Get('public_log'); $sLogPublic = $oLog->GetModifiedEntry('html'); if ($sLogPublic != '') { $sOQL = "SELECT UserRequest WHERE parent_request_id=:ticket"; $oChildRequestSet = new DBObjectSet(DBObjectSearch::FromOQL($sOQL), array(), array( 'ticket' => $this->GetKey(), ) ); while($oRequest = $oChildRequestSet->Fetch()) { $oRequest->set('public_log',$sLogPublic); $oRequest->DBUpdate(); } } $oLog = $this->Get('private_log'); $sLogPrivate = $oLog->GetModifiedEntry('html'); if ($sLogPrivate != '') { $sOQL = "SELECT UserRequest WHERE parent_request_id=:ticket"; $oChildRequestSet = new DBObjectSet(DBObjectSearch::FromOQL($sOQL), array(), array( 'ticket' => $this->GetKey(), ) ); while($oRequest = $oChildRequestSet->Fetch()) { $oRequest->set('private_log',$sLogPrivate); $oRequest->DBUpdate(); } } return true; }
Any feedback please?
Another reason to revise logs: it would be easy to just add an extra field to such a record to keep track of the Message ID.
Could be used for a variety of extensions: emails, messages from other systems, ...
The idea of changing the way of how log entries are stored (and split then up into multiple database records) sounds pretty interesting to me.
Especially compared to CMDBChangeOp objects log entries are stored pretty "flat" currently.
I could image, a new way of storing those entries could offer a lot of opportunities in the future. Thumbs up from my site :-)
I think this could be considered as there's plan to bring caselog entry edition and it would be useful in order to ease anonymization of caselog entries.
Product team and especially @cisou could take this idea into account when planning aforementioned tickets
Hello,
N°3552 should solve the first problem you mentioned about having the cron user associated to the caselog, instead of the user corresponding to the processed mail. Can you confirm this Jeffrey ?
You did had comments in https://github.com/Combodo/iTop/commit/c9e887a2645fb19a42a4b040e010b1e70fe84367, one of the commits made for this fix
About caselog edition, and the way they are persisted, there is an old ticket in Combodo private DB : N°1365. This is a long discussion, I prefer to exclude this from this ticket, and deal only about the user associated to the caselog.