Improvement: addition of a custom ticket prefix

[mikenowak]

Currently the RT# ticket prefix is hardcoded, so these of us who would like to use a custom one are out of luck. This PR adds support for specifying custom ticket prefix via rt.ticket_prefix.

For completeness, I want to clarify that that the users willing to take a full advantagage of this would also need to adjust helpdesk_notification_mail_subject accordingly.

[mikenowak]

Sorry, a copy & paste fail - basically ConfigHelper::checkValue() returns true, or false, not the string. I will be fixing this in a moment.

[mikenowak]

@chilek, this has been fixed.

[chilek]

@miknowak: RT# is not harcoded from some time. You can always use configuration variable settings to format notifications and thus adjusting them to your requirements/needs.
So please try to use following settings:

• phpui.helpdesk_customerinfo_mail_body
• phpui.helpdesk_customerinfo_sms_body
• phpui.helpdesk_notification_mail_subject
• phpui.helpdesk_notification_mail_body
• phpui.helpdesk_notification_sms_body

%tid could be converted to %[sprintf_like_symbols]tid as for example:
%06tid would replace this symbol for ticket 345 with 000345.

Any way thanks for contribution - it is seldom seen for LMS project ;-)

[mikenowak]

@chilek, I understand what these vars are for, don't get me wrong and its not just the notifications that I am concerned about.

My primary concern is that the following line has an RT# hardcoded, so if my phpui.helpdesk_notification_mail_subject looks like [ISP#%tid] %subject, then unfortunately rtparser expects the ticket in the RT# format, so each response generates a new ticket, rather than linking the response to the already existing ticket. The offending line is this:

if (!$prev_tid && preg_match('/RT#(?<ticketid>[0-9]{6,})/', $mh_subject, $matches)) {

Hope this makes sense now, and puts this PR into perspective for you.

Sure, no problem re the contributions :)

[chilek]

@mikenowak I seen now! Let's change it to phpui.helpdesk_ticket_prefix with %tid substitution symbol value. It'll allow to customize format for user. For example:
RT#%06tid for ticket 345 will convert to RT#000345
Wouln't it be very flexible?

[chilek]

Perhaps we should go further and allow to format whole subject this way:
RT#%06tid %subject
?

[mikenowak]

@chilek, ok so as discussed in #1380, I will be implementing this as phpui.helpdesk_notification_ticketid_format.

I will stick to the ticketid format only, and ignore the %subject just as you've described in the below comment sourced from #1380.

So we would have 2-level %tid substitution:
phpui.helpdesk_notification_ticketid_format (replaces [RT#%06tid] by [RT#000345]).
phpui.helpdesk_notification_subject (replaces %tid %subject by [RT#000345] some ticket subject).

[mikenowak]

I lost focus on why we were making these changes, so I dediced to go back and look at this issue again.

I found that the real reason why the email replies are not linked to existing tickets is becasue both of the below checks in lms-rtparser.php fail.

$lastref = array_pop($reftab);
...
// check 'References'
if ($lastref) {
	$message = $DB->GetRow("SELECT id, ticketid FROM rtmessages WHERE messageid = ?",
		array($lastref));
	if (!empty($message)) {
		$prev_tid = $message['ticketid'];
		$inreplytoid = $message['id'];
	}
}

On this one it turns out that the References header in the original email from LMS has a value of Array.

References: Array

Next, which is what has been already discussed here.

// check email subject
if (!$prev_tid && preg_match('/RT#(?<ticketid>[0-9]{6,})/', $mh_subject, $matches)) {

This fails because my rt.autoreply_subject has a different prefix than the hardoded RT#.

[chilek]

On this one it turns out that the References header in the original email from LMS has a value of Array.

Which original post do you mean?
I've checked it out before the moment and references header was ok, I mean the following scenario:

1. Customer sends post to helpdesk queue email.
2. Ticket is created in LMS.
3. User replies to ticket from previous point.
4. Customer gets reply via email with valid references header (not Array).

Will you describe your test scenario?

[mikenowak]

@chilek, @interduo hi, its been a while but I got seriously distracted - the new code should do the trick - let me know if anything needs changing.

[mikenowak]

@chilek, can we merge this please?

[interduo]

Could You also use newly added ticket prefix in PR?

[interduo]

This is done by now. The code contains rt.subject_ticket_regexp_match.