Add Ticket/Email Body to Statistics Reports

[kidfrom77]

Hi,

I'm trying to customize my stats. I would like to add a new "Attribute to be printed" in "Statistics", this could be found in Step 2 when you edit your stat. In this new Attribute I need to show the body of the tickets/email as a column when I export the report. We've been playing with Kernel/System/Stats/Dynamic/TicketList.pm without any luck. We did find in Tickets --> Notification Management --> New Ticket that "OTRS_CUSTOMER_EMAIL" is the string we need.

OTRS Version: 3.0.6

Please could you assist me with this?

[crythias]

tickets don't have bodies. Articles do. And considering an article might be several pages in length, not to mention that you might have a hundred articles for a ticket, is this going to help you in a statistics report?

[kidfrom77]

Hi crythias,

When OTRS receives an email it creates a ticket and inserts the email into it. What I want to do is to have that email information in a column when I export statistics. I know, my boss is asking me for a nonsense thing, because the report will be hughe. But, is this really possible?

Thanks in advance!

[crythias]

Yes but you will have to build it.

[kidfrom77]

I really appreciate your prompt response. Would it be too annoying if I ask you to give me any tip to do this? Or the file or string I have to know to start building it. I found "ArticleMailContent" and tried to add it to Kernel/System/Stats/Dynamic/TicketList.pm but nothing happened.

Thanks in advance!

Omar.

[crythias]

Start with a modified version of otrs/bin/otrs.GenerateStats.pl and learn how to grab the article body/ies from the API and insert them ... somehow.
Again, think about what you're trying to do. If you put this as a column, you're going to have to squeeze it somehow to fit the rest of the data. If you need to put it on the "next" row, that may help, but your alignment is going to be mucked up because of width management of the PDF generator. There's no spanning rows and this is a table, AND this "only item on next row" is column one, which means your stats column one is going to be as wide as your document, or your "body" column will squeeze out all other data.

I've been there, and had to modify the PDF generator to try to ignore the alternate row for cell size modifications, but it isn't a trivial task, and since it requires messing with core code, I almost gave up.

Now, if you export as csv, you might have a better chance at what you want, but still...