Page MenuHomePhabricator

OTRS: autoresponses have incorrecting greeting line since last update
Closed, ResolvedPublic

Description

See e.g: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=9503781#11278208

Article 2 (the autoresponse) says:
Dear 'permissions-commons@wikimedia.org',
instead of
Dear John Doe,

I assume this is a bug within OTRS that should be reported upstream, but if possible a fix should be applied as soon as possible.

Related Objects

Event Timeline

Krd created this task.Oct 19 2016, 6:24 AM
pajz added a subscriber: pajz.Oct 19 2016, 7:20 AM

Which <OTRS_...> variable in the corresponding autoresponse (Admin panel -> Auto responses) generates the 'permissions-commons@wikimedia.org' bit?

That auto response (i.e. en-permissions-commons-mail received) says

Dear <OTRS_CUSTOMER_REALNAME>,

etc etc etc

and <OTRS_CUSTOMER_REALNAME> is defined as

To get the realname of the ticket's customer user (if given).

I think this is http://bugs.otrs.org/show_bug.cgi?id=4640. Fixed 22 days ago and not yet in a release.

pajz added a comment.Oct 19 2016, 4:15 PM

We should probably remove this line alltogether (or replace it with something non-personalized) until we have that fixed. "Dear 'permissions-commons@wikimedia.org'," is very confusing indeed.

That line is quite in a few auto responses. It might make more sense to try to apply that patch locally and see if it solves our issue. I 'll try to do that and see if it works

DatGuy added a subscriber: DatGuy.Oct 20 2016, 4:02 PM

Could it be switched to something more similar to the German permission queue? (Haven't checked if it's changed on the main English Commons queue yet)

Krd added a comment.Oct 20 2016, 5:43 PM

@DatGuy: Please discuss the content of the message on OTRS wiki.

Added a patch of my own and problem fixed

Test case:

https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=9511408#11287029

I 'll send a PR to OTRS

Trijnstel closed this task as Resolved.Nov 20 2016, 6:16 PM

I've checked a few random tickets in permissions-commons and can confirm that it's resolved. Closing this bug report now.

I Did a test after the upgrade to 5.0.19 (tracked in T165284) and this has finally been correctly fixed upstream and my patch is no longer required.