#4756 %{recipient.ticket_link} is still not working in canned responses (v1.11)

[Anonymous]

Originally created by: InToSSH

Prerequisites

• [x] Can you reproduce the problem in a fresh installation of the "develop" branch?
• [ ] Do you have any errors in the PHP error log, or javascript console?
• [ ] Did you check the osTicket forums?
• [x] Did you perform a cursory search to see if your bug or enhancement is already reported?

For more information on how to write a good bug report

Description

When I add the %{recipient.ticket_link} to a canned response, then use this response as Post Reply on a ticket, the end users gets only the name of the actual variable and not the correct link.
This has been an issue in the past [#1459] , but still not fixed.
It has nothing to do with [#2201] , the variable is saved correctly in the DB.

Steps to Reproduce

1. Add %{recipient.ticket_link} to a Canned response
2. Create a ticket / let a user create a ticket by sending in an email
3. Reply to this ticket with a canned response
4. Check the reply email delivered to the end user

Expected behavior: Showing the actual tokenized link in the email for user to be able to open the ticket status.

Actual behavior: Shows the var name in email

Versions

v1.11 (d4e240b)
7.1.20-1+ubuntu18.04.1+deb.sury.org+1

Canned response:

Delivered email:

[Anonymous]

Originally posted by: InToSSH

I looked at the default templates as I noticed that it uses this variable aswell.. And I found that it contains this: <a href="%%7Brecipient.ticket_link%7D">#%{ticket.number}</a>. So I tried to use this escaped version in the canned response %%7Brecipient.ticket_link%7D and it works fine. Maybe there is some workaround left in the code from when the [#2201] was an issue after the var was incorrectly saved in to the DB as escaped?

[Anonymous]

Originally posted by: JediKev

@InToSSH

Okay, so please bear with me as this will be a slightly lengthy explanation:

The variables in canned responses originally were not meant to be replaced upon load (as seen here). However, I see we added this bit of code to allow replacing variables when loading the canned response in the reply box later on (most likely in 1.10.x). This works for all other link variables except the recipient link variable as the recipient object is not passed, ergo it cannot load the recipient link. I have a pull request that fixes this particular issue here:
[#4759]

Now, this led me to another issue where placing a variable in the response body itself (ie. not in a canned response but typing it out manually) is supposed to be replaced when the response is sent (variables in canned responses are supposed to be replaced on load but if not, for some reason, they are supposed to be replaced when the response is sent as well). This does not happen, in fact, none of the variables are replaced when added to the response body independently. The reason variables in the response body do not work independently is because the %{response} variable in the Response/Reply Template is replaced with the actual response body and the actual response body doesn't go through any functions to detect/replace any of the variables. This is not intended as all available variables should be replaced when the response is sent. I have an idea of how to fix this just need to run this by a few people. So a fix is coming soon for this one.

Cheers.

[Anonymous]

Originally posted by: InToSSH

@JediKev thanks for a great explanation :) I see where the problem is coming from now. I understand %{recipient} cannot be replaced beforehand as it's fetch when sending the actual email as it might contain more than one "email object" for each recipient. Then there is the problem with "two layers" of replacing the vars, once on the reply/canned response level, then this gets packed into a single var %{response} and it is passed to an email template, where its vars are replaced. And this is not a problem when vars in the reply are replaced automatically when the canned response is inserted, because it's no longer a var, but string. Anyway this escaped version is working for me now so no need to rush :) Thanks again.