[otrs] Add grid columns to CustomerTicketOverview, AgentTicketZoom, etc.

[Bogdan Iosif]

Hi,

I run OTRS 3.1.10 and would like to add a column to CustomerTicketOverview.

I looked at SysConfig but wasn't able to find any support to customize anything in CustomerTicketOverview.

Web search yielded the following relevant hits:
* http://lists.otrs.org/pipermail/otrs/2012-August/038407.html # customizing grid from CustomerTicketOverview
* http://forums.otterhub.org/viewtopic.php?f=60&t=5156 # customizing grids from agent dashboard and AgentTicketZoom

Both solutions involve modifications to .DTL and, possibly, .PM files. Thus, they need to be maintained across OTRS version upgrades and require dev-level involvement.

QUESTION 1: Is there an easier way to customize those grids?

QUESTION 2: Did anything change in v3.2 to ease these customizations? (A post from@Mike_B on the forum thread gave me some hope in this direction)

Thanks,

/bogdan

[Michiel Beijen]

Hi,

In OTRS 3.1 and up, you can specify additional dynamic fields (which
are implemented as 'free text fields' in OTRS 3.0) in this overview.

Which fields did you want to add?

> ---------------------------------------------------------------------
> OTRS mailing list: otrs - Webpage: http://otrs.org/
> Archive: http://lists.otrs.org/pipermail/otrs
> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[Bogdan Iosif]

This is interesting if it can be done via configurations. Can you please give me some link to where it's documented, I wasn't able to find a View in SysConfig that corresponds to CustomerTicketOverview.

In my case, I think I won't be able to use a field already implemented by the Ticket because I need to show the time elapsed since the last agent update (for us, it's more relevant than the current "Age" column). At the db level I know how to compute this value but I'm trying to minimize changes at the app server level.

[Michiel Beijen]

It's here:

http://doc.otrs.org/3.2/en/html/Ticket.html#Ticket:Frontend::Customer::TicketOverview

So you can define in SysConfig which fields you want to have displayed.
If you want to 'minimize changes' what you probably can do best is
create an OTRS Ticket Event Module that updates a new dynamic field
you create, whenever the ' last changed by agent' timestamp needs to
be updated. In that case all you'll add to OTRS is one event module --
ref: http://doc.otrs.org/developer/3.1/en/html/otrs-module-layers.html#ticketevent

--
Mike

[Bogdan Iosif]

I found Ticket -> Frontend::Customer::TicketOverview on my QA env (v3.2.3). Thanks! (It doesn't exist in my prod env (v3.1.10) so maybe this is new for v3.2?)

Assuming I want to avoid adding yet another dynamic field (I already have plenty) the only remaining option is to perform modifications similar to those in my initial links?

[Michiel Beijen]

It could be new for 3.2... I'm not sure actually.

And yes, if you don't want to use another dynamic field you should
make other modifications. But I'd recommend using dynamic fields,
because that would keep your system more standard.

--
Mike

[Bogdan Iosif]

> that would keep your system more standard

I'm 100% for this goal but unfortunately I won't be able to use your suggestion with Event Modules because it turned out I'll need to compute the value on my new column as the difference between the moment when the page is shown and the moment when the ticket was last changed.

Event modules won't save me in this case. Right?

[Gerald Young]

:) There's a way to do this. 

> I'll need to compute the value on my new column as the difference between the moment when the page is shown and the moment when the ticket was last changed.

Create a dynamic date field and make it mandatory. Clicking a checkbox should make it "work" (we can make it read only via javascript in the code later, or just hide the value entries...

Then your column is create_time minus this dynamic date field.

I've suggested this (or something like it) also for an alternative to CAPTCHA. The idea there being that the difference in time between the display of a registration form and the submission of the displayed form should be > about 5 seconds, which would, in theory, mean a human is filling in the blanks instead of a script.

[Bogdan Iosif]

I'm sorry, I don't get it.

I'll re-summary the need: In customer interface (Frontend::Customer::TicketOverview, i.e. the main grid that shows after customer login), show a new column, after Age, that displays the time elapsed between the moment the grid is shown and the moment the ticket was last changed.

Can this problem be saved with dynamic fields? How?! :)

[Gerald Young]

oh. No. The time elapsed is usually the total age of the ticket from inception. Of course, you could just show the actual date of last change and then use javascript to provide the difference between then and now.

[Bogdan Iosif]

Aha. OK, thanks. Good point with using JavaScript.

So then please confirm the following answers to my original 2 questions:

Q 1: Is there an easier way to customize those grids?

    A 1: NO. For my specific requirement, I need to customize the .DTL / .PM files (I read something about being able to override those shipped with OTRS instead of actually modifying them directly)

Q 2: Did anything change in v3.2 to ease these customizations? (A post from@Mike_B on the forum thread gave me some hope in this direction)

    A 2: Only change is dynamic fields can now be configured to be shown in that grid (However, other Ticket fields (e.g. Queue) can't be shown simply from configurations)

[Gerald Young]

A1: Confirmed, though you can somewhat mitigate overwrites within a given minor release (3.2.x) by placing your customs in its own theme

A2: Confirmed. BUT M and L might be more informative than S so ...

[Bogdan Iosif]

"BUT M and L might be more informative than S so ... "

I don't see any option for M / L / S for customer ticket overview interface. Is this something that can be enabled?

[Gerald Young]

I don't see it, either. I'm sorry about the confusion. I don't look at customer side practically ever, so I don't know what it shows or doesn't. 

IMO, the queue is rather unimportant to the customer, as it doesn't have anything particular to do with progressing the ticket, which as a customer, is practically the only thing I'd care about. Yes, it's interesting to know which folder holds my ticket but I don't care.

In general, most everything that happens with lateral movement of the ticket (Queue, Owner change, even priority) is pretty much not something the customer needs to know. 

The Queue is just a folder. It's important only on the Agent side. Yes, really. 

The Owner isn't important until the Owner talks to the customer. 

The priority isn't of critical importance when it's changed and can be a point of contention if it doesn't reflect the customer's view of the seriousness of the ticket. 

This is, of course, just my opinion, but think on it. 

[Bogdan Iosif]

Thanks a lot for the replies.

"think on it"

I sure do. Opinions are strongly influenced by context. For example, if you use OTRS to work with customers "at large" over the Internet, I think everything you said holds true very strongly.

However, when you are an enterprise business, bound by SLAs, using OTRS to interact with your precious (literally) few customers then when they ask for something perceived as trivial (like the column described by me) then you can tell them they don't need it (and endure the backslash which can be just the straw that broke the camel's back due to a 1000 other things you told them they don't need in your mainstream products) or you can just try your best to satisfy their needs and keep your costs in check.

When your OTRS customers are actually other people in the same organization as you are, then you have a whole other ball game.

Just philosophy. No preaching. :)

[Gerald Young]

:) Understood. :)