Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Reply separator tag - fixing the behavior (need some help)

Hi everyone!
I've spent some time trying to fix the current behavior of the reply separator tag, or should I say the fact that it's located in the original email so we have part of the original email in the ticket itself, like this:
"Student's message

On 09.12.2017 21:55, Customer Support wrote:"

I've searched the forum and git for a solution but couldn't find it, so I decided to give it a shot myself.
The naive idea behind my "fix" was to replace the line "On 09.12.2017 21:55, Customer Support wrote:" with the reply separator tag, after that the system will look for the reply separator tag and cut off everything below it.
I learned enough php to do this and made changes to class.thread.php hoping it would work.
This is the code (added at line 2104):
        // Remove the part right above the separator in replies
        // Separating the body into lines and going through them
        $temporarydata = '';
        foreach(preg_split("/<br[^>]*>/i", $this->body) as &$line){
        //Check if there's a customer support email name on that line
            if (strpos($line, "Customer Support") !==false ) {
            //If there is, replace it with the separator tag
            $line = $tag;
        $temporarydata .= $line . "<br>";
        $this->body = $temporarydata;

It should split body into lines and then go though every line and check for "Customer Support", when it's found, we replace the whole line with the reply separator tag.
Then we need to recreate the body but incorporating the change and then put that into the original variable.
This doesn't produce any error but does not work in the end, the result is the same as without this code.

Please keep in mind that I have never used php before,
If anyone can see an error in my code or has any suggestions please let me know.
I wanted to get this done for all of us but this is as far as I can go for now.


  • What's the issue with the separator?
    I checked my install and it seems to leave the same metadata, consistent with your findings. So it's probably by design.  Is that an issue? 

    FYI: Your code assumes html.. which is never wise to play with using regex. Also, it only works for English, so is unlikely to get into core. And not every mail-client will include that in the same way when generating a reply. Hence the requirement of a Reply Separator tag in the first place I guess.
  • Let me explain i more detail.
    The current implementation of the reply separator tag is the easiest one possible, so not much time was spent working on that part.
    The current way it work is that is splits the message into 2 parts, one before the reply separator tag and one with the reply separator tag and everything else.
    Due to that implementation you'll always have additional "reply text" in user's messages, so instead of just getting the message you get this part as well:
    Quoting Customer support <>

    On Sunday, November 26, 2017, 1:32:02 PM GMT+1, Quoting Customer support <> wrote:

    2017-11-26 13:31 GMT+01:00 Quoting Customer support <>:

    These lines (and similar) will always be above the reply separator tag, it's just how emails and email clients work.
    Another cool thing is that the above lines will always be closest to the user's message, so they are the start of that "additional" unneeded info.
    So if we find this line, we can replace it with the reply separator tag, which will result only in the user's message getting into osticket.
    Of course we can't search for the whole line since with different languages it will be different.
    But we can search for something that's always the same and that's:
    Customer support <>

    We just have to find the line with one of these and replace it!

    My code does assumes HTML for the email body as I have no clue what it actually is, I tried simple text as well but it still doesn't work.

    This is not a major issue, it just looks ugly when you look at the tickets. I saw some users complain and ask about this and there was no solution, so I thought I could tackle it.

    As you can see I'm stuck :D
  • Ok, so this was a little more annoying than anticipated .. (mass rage inducing) .. got it working. 

    Had to listen to a ThreadEntry creation Signal and rewrite the body after it's been parsed..  then figure out how to get it back in. WTF. Couldn't do it before it got saved. And the rewriter plugin only worked on NEW MESSAGES.. not replies.. by design.. Forgot about that. 

    It works though.  When User replies useing Gmail.. no idea for other clients. 

    Couldn't be arsed getting a date regex in there. That would be far better though.  I'm thinking might work.. a bit. For English dates. Maybe times then... or "/.*<" . $emailMatchingPattern . ">.*:/";
  • edited December 2017
  • I was banging my head against the wall trying to figure this out.
    Different clients will reply differently (as can be expected) but there's a common thing that I've found.
    Whichever client (Gmail, Yahoo, or some RoundCube etc) replies the common thing is the line which has:
    in it, that line can start with a date, or some other text.
    If we can find the line with:

    and replace the whole line with reply separator we've won!

    An example would be:
    Before any changes:
    Client's message

    On 09.12.2017 21:55, Customer Support wrote:

    After changes:
    Client's message

    Reply separator tag

    That way, when osticket cuts off everything below the reply separator tag we'll be left with only client's message.
  • The problem with abstracting that is osTicket sends From many different emails (one per department and a few others on mine), but they are in the database, or just look for the line with our domain.

    If you've seen my implementation, it works without the separator, because it runs after it, reverses the text to find it from the bottom. But there's a bit of a "deletes the whole message" problem if you're matching an email address or domain and they don't send that line.

    We could also pull the thread from the $entry and locate the last sent, then we'd know what date to look for. Day level accuracy is probably enough. Only issue is number formats vary.. but only 6 ways with three numbers.. pretty doable.
    Any other context would actually be relevant, because they're responding to a previous message, not the latest. So are doing it intentionally. Hmm.

    It sure is frustrating to test!
  • It's frustrating as heck!
    I'll think about this some more, and bang my head against the wall...
Sign In or Register to comment.