Menu

#1972 Update parent ticket -> incorrect name in child ticket (log entry)

Unassigned
more-info-needed
None
Data model
High
2.7.5
defect
2021-09-06
2021-05-12
No

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;

}

Discussion

  • Jeffrey Bostoen

    Jeffrey Bostoen - 2021-05-28

    Any feedback please?

     
  • Jeffrey Bostoen

    Jeffrey Bostoen - 2021-07-19

    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, ...

     
  • Lars

    Lars - 2021-07-23

    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 :-)

     
  • Stephen Abello

    Stephen Abello - 2021-08-02

    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

     
    👍
    1
  • Pierre Goiffon

    Pierre Goiffon - 2021-09-06

    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.

     
  • Pierre Goiffon

    Pierre Goiffon - 2021-09-06
    • status: new --> more-info-needed
    • assigned_to: Pierre Goiffon
     

Log in to post a comment.