Osticket: Let agents reply to new tickets via email

How would you propose that agent collision be handled?
(two agents replying to the same ticket in rapid succession)
Or ticket locking?
Or ticket assignment?

You might be interested in a mod I did to do exactly what you want. It's been running for a couple of years now and I've had no problems with it. I modified class.ticket.php and class.thread.php. You can get them here: http://we.tl/4X0cUWgNtZ

The mods are marked betweed "// LUIS MOD" and "// END LUIS MOD". In class.thread.php you'd need the two mods, but in class.ticket.php you'd only need "// LUIS MOD: postResponse function, to add staff email replies as Responses, not Notes".

I wish I could turn these mods into plugins, so I don't need to copy-paste all the stuff whenever I update.

Hi @molul is your mod working for 1.9.12 ? Are you able to post it again as I can't find any other mods as current as yours. This seems like it should really be a standard setting available in osticket.

Sure! Here it is:
luis-mod.zip

Hope it helps!

Thanks for sending that through, I tried copying just the "LUIS MOD" section into the existing files but it didn't work as there are a few other differences in the files. I then tried replacing the entire files with the ones you posted and it works. Which version are these created for?
Thank you for this, hopefully osticket eventually include this as an option in the admin panel in a future release.

Oh! Sorry for that. It was created for 1.9.x (don't remember exactly which one) and then later ported to 1.9.8 just by copying and pasting the "//LUIS MOD" parts.

I wish I knew how to convert these mods into plugins, so I could easily update to newer versions.

This works perfectly, one thing I was wondering. Is it at all possible for you to make it assign it to the member responding via email? For collision purposes have it check if it is already assigned before assigning it. I'm just looking to have it trigger the assignment email alert for the other team members notifying them that one of us is looking at it. This will help us when we are not at our desk but are able to assist an issue.

Well, I guess there would be a way, by matching the agent email and running the neccessary commands, but I'm afraid I don't know how :(

It would be so cool having this as a regular feature in osTicket. I mean, agents responding to ticket by email, and assigning tickets from that email.

With regards the above mod, I tried on 1.9.14 version and the functionality with the emails works as expected. The problem is that I lost the functionality to edit the ticket via the web interface any ideas ?

Oops. No idea, I'm afraid :( I'm using 1.9.12 and I have no problems.

it worked, I replaced the file in the beginning using your files and the edit functionality broke on web interface, but after i retried by adding only the sections between "// LUIS MOD comments and it worked. Thanks molul !!

Oh, that makes sense. Glad to know you managed to get it working!

molul,

I added your mods to an implementation I'm doing and it works wonderfully. Thanks for your contributions! Quick question -- how difficult would it be to have the response email send to the team assigned to the ticket as well rather than just the submitter?

Thanks again!

So glad that it's useful for you :)

About your question, I'm afraid I don't know. It's been a long time since last time I used this mod, and I haven't investigated how emails are sent to teams :(

I figured it out.

I copied the following code from the postMessage function in class.ticket.php and added it to the postResponse function you made:

    //If enabled...send alert to staff (New Message Alert)
    if($cfg->alertONNewMessage()
            && ($email = $dept->getAlertEmail())
            && ($tpl = $dept->getTemplate())
            && ($msg = $tpl->getNewMessageAlertMsgTemplate())) {

        $msg = $this->replaceVars($msg->asArray(), $variables);

        //Build list of recipients and fire the alerts.
        $recipients=array();
        //Last respondent.
        if($cfg->alertLastRespondentONNewMessage() || $cfg->alertAssignedONNewMessage())
            $recipients[]=$this->getLastRespondent();

        //Assigned staff if any...could be the last respondent
        if ($cfg->alertAssignedONNewMessage() && $this->isAssigned()) {
            if ($staff = $this->getStaff())
                $recipients[] = $staff;
            elseif ($team = $this->getTeam())
                $recipients = array_merge($recipients, $team->getMembers());
        }

        //Dept manager
        if($cfg->alertDeptManagerONNewMessage() && $dept && ($manager=$dept->getManager()))
            $recipients[]=$manager;

        // Account manager
        if ($cfg->alertAcctManagerONNewMessage()
                && ($org = $this->getOwner()->getOrganization())
                && ($acct_manager = $org->getAccountManager())) {
            if ($acct_manager instanceof Team)
                $recipients = array_merge($recipients, $acct_manager->getMembers());
            else
                $recipients[] = $acct_manager;
        }

        $sentlist=array(); //I know it sucks...but..it works.
        foreach( $recipients as $k=>$staff) {
            if(!$staff || !$staff->getEmail() || !$staff->isAvailable() || in_array($staff->getEmail(), $sentlist)) continue;
            $alert = $this->replaceVars($msg, array('recipient' => $staff));
            $email->sendAlert($staff, $alert['subj'], $alert['body'], null, $options);
            $sentlist[] = $staff->getEmail();
        }
    }

This did the trick for us.

Cool! :D

It would be so cool having this as a regular feature in osTicket. I mean, agents responding to ticket by email, and assigning tickets from that email.

Hint* Hint* osTicket

@ets-phill could you please post a diff file for these changes ? 👍
I'm working with v1.10

Yes, I need this exatly functionality for version 1.10. I think this would be a regular in OsTicket to.

Has anyone update this for v1.10? Thanks.

Currently, with version 10, when an agent replies to a ticket by email, it posts the response to an internal note, and no one gets a copy of it. If the system can read the agent's email response and post it to an internal note, why can't it also send the response to the ticket creator?

Or is this what the attached file is meant to do?

Okay, I just looked through the attached zip files and through the v. 10 files I have on my server and see that there's been a lot of work on these and don't know if it's possible to use this code on this version. Anyone have any ideas for that?

Yes, a diff would be good. I can't get traction with this system because busy one-man departments want to be able to handle things from their inbox. So, once clients figure this out, they end up resorting to direct emails again instead of the ticket system.

I've tried and that code cannot be applied just using diff command

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

2017-03-09 21:47 GMT+01:00 scslogin notifications@github.com:

Yes, a diff would be good. I can't get traction with this system because
busy one-man departments want to be able to handle things from their inbox.
So, once clients figure this out, they end up resorting to direct emails
again instead of the ticket system.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-285478201,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH4imYl9ZLZr5-OmDMA782syzAXFXv2ks5rkGV1gaJpZM4FVyBD
.

Hello,
anyone on this thread ?

@rayfoss please check this question.
thanks.

Really would like to see this updated for v.10.

@scslogin you mean updated for v1.11? 1.10 is and has been out for some time.

@ntozier, I was actually talking about 1.10, current stable. This code described in this thread doesn't fit with 1.10. Too much new code.

Modification I created working with v1.10 - it also assigns the ticket to the person replying if ticket is unassigned. I've only been using this for a couple days, but so far it seems to be OK.

https://pastebin.com/RiAxWHbP

Well, I have applied the patch very easily:
1) download the patch file attached
reply.txt

2) go in the "include" dir of your osTicket installation
3) run the command patch < reply.txt

Done 👍
I've performed one single test for now and seems cool, so it works from me!

Nice work, @acetwenty8. It would be _so helpful_ if this could be merged into the main code and enabled/disabled with an option box in the admin interface. With various people going through the trouble of creating patches for multiple versions of osTickets, it seems like this is a scenario that is very real for multiple people.

@acetwenty8 Thanks for the mod.. Im sure I am doing something wrong can someone help me? I ran the patch and the 2 files were modified but nothing seems to have changed. Is there something else I need to do? Right now if an agent reply, a new ticket is created.

@jayb80 There's nothing else you have to do after the patch is applied. How are you replying to the ticket thread through email? The way it works is, agents reply to the 'New Ticket Notificaiton' email, and it gets posted back to the ticket thread as a agent reply, rather than an internal note (which is the default behavior).

Hi,
I have doawnloaded and done what theCloud wrote. But if I run the command "patch < reply.txt" I get the following output / error ->

web/include# patch < patch.txt
(Stripping trailing CRs from patch; use --binary to disable.)
patching file class.ticket.php
(Stripping trailing CRs from patch; use --binary to disable.)
patching file class.thread.php
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 417 with fuzz 1.

What to do?

Thanks for your response!

Hello,
Maybe the file was saved on windows and then applied to Linux ?

Hi, yes - I downloaded via Windows and copied to a Linuxbox afterwords. I downloaded again now directly with wget to the box and patched the two original files once again ->

(Stripping trailing CRs from patch; use --binary to disable.)
patching file class.ticket.php
(Stripping trailing CRs from patch; use --binary to disable.)
patching file class.thread.php
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 417 with fuzz 1.

Maybe you (or anybody else) could send me the patched two files in a zip (or to download here)? I am using the latest OST 1.10 (downloaded the day before yesterday).

Thanks so much!

Walhalla

@walhallaRV I had the same issue, what i ended up doing to fix the isue was simply adding a line to the end of the reply.txt file.

I opened the reply.txt file in vi. went to the last line of the file and added a line then saved.

Then ran:
patch < reply.txt

I hope this helps.

BINGO ->
(Stripping trailing CRs from patch; use --binary to disable.)
patching file class.ticket.php
(Stripping trailing CRs from patch; use --binary to disable.)
patching file class.thread.php

THANK YOU VERY MUCH!!! sometimes tiny things cause ... :)

Cheers Walhalla

Tested and is working great. Thanks to the people here for this solution!

But I dont understand why OST is ignoring now for much time the requests of many people regarding this feature!!! They wouldnt have to do many things - just implement those lines of code other people wrote. At least as an option ("on my own risk").

Thank you so much for this solution which OST isnt able to realize and your help. GREAT JOB!!!

Walhalla, who is happy now!

Well,
Let's be fair: the product is one of the best around and it's free.
Sometimes customers take priority over community and thus developers must accomplish business requirements.

Anyhow, I'm sure osTicket will thank the developers for developing and testing this and add it to the final product.

Let's give them some time or just spinoff :-)) ahah

There are many requests regarding this for several years now. The only comment / answer: "we will think about it."

If there would be any technical reason to not implement it - would be nice if one of them would answer and explain why it is impossible. Some years ago I read an answer like this anywhere (dont remember): "We dont need, so we will not work on it ..."?!

If there would be no possibillity to answer by email - OK. But the fact that customers can answer by email - only agents cant do this ... I never understood.

But OK - thanks you and the guys here it is resolved!!! THANK YOU very much once again ...

Walhalla

OST is mainly an open source ticketing system, it's supported by its community and a few developers who devote their personal time to OSTicket. They are working on OSTicket for free or barely any compensation at all. Thousands use OSTicket and request features, this is how newer versions come out, but since so many features are requested or those features are really crazy in the code aspect, it takes time to implement. Features do get added, it may happen in a major release that's one version away, or two. It depends on what is needed most. One way is to see how much the community wants a feature, which this email one is a major request.

With all that said, I am sure this will be implemented in the near future, please just be patient and keep requesting features you wish to see in later editions of OSTicket.

On Apr 20, 2017, at 11:09 AM, walhallaRV notifications@github.com wrote:

There are many requests regarding this for several years now. The only comment / answer: "we will think about it."

If there would be any technical reason to not implement it - would be nice if one of them would answer and explain why it is impossible. Some years ago I read an answer like this anywhere (dont remember): "We dont need, so we will not work on it ..."?!

If there would be no possibillity to answer by email - OK. But the fact that customers can answer by email - only agents cant do this ... I never understood.

But OK - thanks you and the guys here it is resolved!!! THANK YOU very much once again ...

Walhalla

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It is OT here and I really dont want to discuss here. But we sent two of our customers to them and they pay monthly lots of money. So I think that the developers get payed too?! Further: they only would need to copy this patch from here, implement in a RC/beta for testing, ready, As I read, this patch exists since V 1.7?

I could understand if they would have answered only one time: "It is impossible to implement this feature." But responding "Will think about this." for years without any decision? Those clients asked several times too. Why do they ask for Feature Requests ... and dont respond?

But anyway - I found this solution, dont have to understand the politics of them, wont make any update and I am happy!!!

Hi,

i was looking for this solution but i am not a devolper myself. Is there anyone who whats tho help me to get the right files to make this working? its version 1.10.

Kind regards!!!!

J

Save an animal, get a developer :-)

Il giorno sab 22 lug 2017 alle 20:48 j070nl notifications@github.com ha
scritto:

Hi,

i was looking for this solution but i am not a devolper myself. Is there
anyone who whats tho help me to get the right files to make this working?

Kind regards!!!!

J

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-317178224,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH4iilh9QVzNKJ3inWp6muFBLUGBtRFks5sQeGWgaJpZM4FVyBD
.

>

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Are you one?

It would be great to have this as an option in osTicket. Thanks for the patch @TheCloud !

@TheCloud Thanks for the reply.txt file. Running the patch has worked perfectly on 1.10 and is sending email to the customers when staff submit responses. Great!

As the original requester, I am glad that the community/product users have created a little modification, but I must ask the project maintainers if they still see the potential of including the feature into the product, as default?

Might give some others some closure to a feature they want with osTicket.

@voarsh It is something that is on our development roadmap for future versions, yes, but it is not going to be implemented right away. With something like this, we will most likely use the idea of the pull request as a base and then write the official feature in our coding style/vision. Once we finish development on the feature we will most likely push it here for the community to test for us. Then after it has been fully tested and approved it will be merged into the core codebase and will be apart of the next version. I hope this clears things up for you. Cheers.

Thanks for the patch, works great!

Just one question - is it possible to implement this also for the "Ticket Assigned to you" Email?

Scenario: I assign a ticket to an agent. This agent is notified by email and replies to that email. Unfortunately this creates a new ticket instead of a new reply to the existing ticket/client.

Is that possible? This would be awesome!
Thanks guys

@TheCloud I think one of the real challenges which osTicket has is the lack of true clear direction on what is next and how mods and alterations are to be submitted. For example is this feature best suited as a plugin or as an added feature to "core". If this is something which is best suited as a plugin - great. Then as a group we need to port it to one. Otherwise given the large swell of support for this and the fact that its been years I see this as needed.

As OSS projects grow they often look to active and dedicated community users to step up and help with code review, feature assessments, road maps and design. There is so much GOOD code which is falling behind with this product that I fear it is losing traction it otherwise could be gaining. If a small group were to be formed and details hashed out I believe the backlog of code and better clarity of what should be core vs what should be a plugin can be addressed cleanly and quickly.

Hi,
does this replay-patch work with the version 1.10.4 too? Anybody applied / tested / works?

Thanks for your fast response!

Walhalla

It should be working with 1.10.x - let us know if not... it’s unmantained
piece of code

Il giorno gio 18 ott 2018 alle 03:55 walhallaRV notifications@github.com
ha scritto:

Hi,
does this replay.patch with the version 1.10.4 too? Anybody applied /
tested / works?

Thanks for your fast response!

Walhalla

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-430848296,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH4ivLGLj2zFUk4fGrRLc4LI7UoGcNcks5ul9-kgaJpZM4FVyBD
.

>

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

This is awesome. Just patched and it works great. Thank you so much @TheCloud !!

Anyone got this to work under the newest version? Patching worked fine, but didn't seem to change anything.

Anyone got this to work under the newest version? Patching worked fine, but didn't seem to change anything.

How did you test ? Did you reply via email to a ticket ?

@bevergit You need to edit class.thread and class.ticket manually, the line #'s have changed since this was released.

unfortunately it doesn't work with 1.11, i can't get $mailinfo['userClass'] to equals 'S' it always equals 'M'... kinda sad

any updates for v1.12? Was hoping I could implement this feature. This is proving to be a very missed feature.

Dan,
it seems that OSTicket is not really interested in listening the community
requirements :-)

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Il giorno mer 19 giu 2019 alle ore 17:16 Dan notifications@github.com ha
scritto:

any updates for v1.12? Was hoping I could implement this feature. This is
proving to be a very missed feature.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/osTicket/osTicket/issues/2242?email_source=notifications&email_token=AAA7RCS7GPKBINUUWVH3VGTP3JEVZA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYCGO3A#issuecomment-503605100,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA7RCXNJBKUKAJBDC7YIW3P3JEVZANCNFSM4BKXEBBQ
.

I have tried to add the @mudul MOD into v1.12 for a few days, now agent can reply via email.
However, the system treat the reply as user reply (i.e blue color on the system), and does not send alert email to the ticket creator/collaborators. (2nd reply in below image actually is an agent reply via email.)

The last reply is made by the agent account at the osticket platform, so it just works properly.

Overall code structure is quite difference between original MOD v1.9 and the newest v1.12.
I just stuck here and can't figure out which part I should modify.
I have attached the v1.12 class.ticket.php & class.thread.php with this comments.

Can anyone please give me some hints? or share your MOD for v1.12?

Thanks a lot.
V1.12_thread&ticket.zip

I am just getting around to testing v1.12.
If I get it working - I'll let y'all know.
-Ace

I have created an updated patch for v1.12 which appears to be working. It is not in my production instance, but my tests indicate it is working okay now (I think). There were some changes to the email parsing logic and thread handling which is why the old patch did not work anymore.

I think someone asked at one point will this patch work with replying to ticket assigned email. I do not use this, but it appears that it does work as well.

This mod is totally unsupported, and I do not guarantee it will be updated or fixed ever. But if you see any major bug while using v1.12 (not any other version) with this patch installed - please try to make a post here so I can be aware.

ace.patch.txt

-Ace

@acetwenty8
It is working fine! Thank you so much!

Hi @acetwenty8,

I applied your file and update and it seems to work correctly. It's able to compare and detect the agent emails and do what it should.
But in our environment, when we reply to the end user, we use the tech support email. Which, in osTicket, is assigned as the system email.
When we reply using that, it gets ignored by the code so no message is added to the ticket.
Is there a way to make the code verify for the system email as well?

Thank you,
Leco

@lecobarros I'm not clear what is system mail, but I think this is meaning the email address which osTicket check to receive new tickets from the user. I do not believe what you are saying was working in previous versions of the patch - correct?

From what I remember working with the code, they have checks specifically to prevent this. Most likely, because you could create an infinite email loop with this situation. I would probably not recommend to disable the checks for that reason.

In the class.thread.php within the postEmail function, I believe it is this code here.

        // Don't process the email -- it came FROM this system
        elseif (Email::getIdByEmail($mailinfo['email'])) {
            return false;
        }

@acetwenty8, that's the email address I'm talking about, yes. And this is the first time I try that patch, but based on your explanation, you're right, that's probably the check that prevents it.

It makes sense that it could create an infinite loop. But we disabled all the auto replies, so that could prevent it. But I'll think more about it, if we should do it or not.

Thank you for the help with this!

@acetwenty8 and @vincentchan925,

From what you guys tested, are the email from collaborators being treated correctly?
On my end, those are not adding to the thread.

@acetwenty8 and @vincentchan925,

From what you guys tested, are the email from collaborators being treated correctly?
On my end, those are not adding to the thread.

Yes, collaborators are treated correctly.
They are added into the ticket automatically.

I tweaked the class.thread.php and class.ticket.php files to include the latest code offered by Ace, but when I do that, the osTicket login process breaks. It no longer displays our logo, and while the login credentials are received and correctly authorized, the technician is never redirected away from /scp/login.php to /scp. If the technician manually attempts to go to /scp after authenticating, it works, but obviously something in the code has gone wonky. We're on v1.12.2

If someone would be willing to provide some guidance or a copy of their working files, I'd be ever so grateful!

@njohn858

It was not tested with v1.12.2, only 1.12

It sounds like you may be trying to edit the files manually, and there's a high chance of errors while doing that. You should use the patch command to apply the diff I created.

-Ace

Ah. That might take care of it - I'll give it a try! Thanks!

Forgive my ignorance, but I don't know how to use the patch command....could you provide some guidance or point me to a tutorial or something like that?

@acetwenty8

For future reference, if you want to make a more "easy to follow" mod you should fork the repo, make a branch on your fork, and link people to the branch. If people don’t know how to use branches, you can then actually provide a link to a diff or patch instead of manually making one and uploading it as a file.

Skeleton of branch diff link:
https://github.com/osTicket/osTicket/compare/osticket:<branch-name>...<account-name>:<branch-name>.diff

Working example of branch diff link:
https://github.com/osTicket/osTicket/compare/osticket:develop-next...jedikev:issue/redactor-quicknotes.diff

(If you want to link to a patch instead of a diff simply replace .diff with .patch.)

This way if anyone has issues with your mod they can create an issue on your fork so the original issue thread is not cluttered with non-supported mod issues that are unrelated to the original issue at hand.

Cheers.

Thank you acetwenty8
Tested working on 1.12.2

we are working with osticket v1.14.1
this feature dose not work

please help
@acetwenty8 @molul

working with 12.5

Thank you for letting know

Il giorno lun 6 gen 2020 alle 01:28 lyk2020 notifications@github.com ha
scritto:

working with 12.5

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/osTicket/osTicket/issues/2242?email_source=notifications&email_token=AAA7RCUHI4E6DVU6E7ZALSLQ4J3MPA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEDWDI#issuecomment-570964749,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA7RCSFIUH7OHR22YNEGRDQ4J3MPANCNFSM4BKXEBBQ
.

>

Julien Buratto
Tel:+39.335.6359.515

I've just upgraded my old installation with GIT repository which reports to be: 1.12-git and patched the with the file + patch command. I'm not very good at GIT, can anyone help in the process of sending this modification to github ?

@acetwenty8

For future reference, if you want to make a more "easy to follow" mod you should fork the repo, make a branch on your fork, and link people to the branch. If people don’t know how to use branches, you can then actually provide a link to a diff or patch instead of manually making one and uploading it as a file.

Skeleton of branch diff link:
https://github.com/osTicket/osTicket/compare/osticket:<branch-name>...<account-name>:<branch-name>.diff

Working example of branch diff link:
https://github.com/osTicket/osTicket/compare/osticket:develop-next...jedikev:issue/redactor-quicknotes.diff

(If you want to link to a patch instead of a diff simply replace .diff with .patch.)

This way if anyone has issues with your mod they can create an issue on your fork so the original issue thread is not cluttered with non-supported mod issues that are unrelated to the original issue at hand.

Cheers.

Could you help me to make a easy fix "step by step" with GIT ? :-D

Hi all,

Any updates for this to work on v1.14.2?

As a one-man-show, being able to use a mobile device to reply to clients quickly would really make a difference! - Why can't this be a setting to enable/disable functionality?

Thanks!

wonder if this can be done by plugin,

A setting would be really nice. +1 @davewatson91

Created a fork with https://github.com/osTicket/osTicket/issues/2242#issuecomment-513056652 's patch applied

https://github.com/YurkoWasHere/osTicket/tree/1.15.x_patched

Seems to work in 1.15.x
This cannot be written as a plugin since it fundamentally changes how messages are processed

Use the patch manually

Howto apply patch from shell

put ace.patch.txt from post in include/ folder then from shell run
patch -p0 < ace.patch.txt

How to patch files by replacing 1.15.x

In include folder replace the following two files
https://raw.githubusercontent.com/YurkoWasHere/osTicket/1.15.x_patched/include/class.ticket.php
https://raw.githubusercontent.com/YurkoWasHere/osTicket/1.15.x_patched/include/class.thread.php

@YurkoWasHere
Thank you very much for the patch and the description. I have tried with patches a few years back, but the problem is that once a new osticket is released they kind of stop to work. This makes it unsupportable.

Do you know if there is reason why this can not be a configuration? Not a patch, but a configuration with the code coming from osticket and not from a patch.

but the problem is that once a new osticket is released they kind of stop to work. This makes it unsupportable.

I agree. The good news is that this patch is applied from 1.12 to 1.15 without modifications. So that is a good sign.

Do you know if there is reason why this can not be a configuration? Not a patch, but a configuration with the code coming from osticket and not from a patch.

Since this cannot be done as a plugin, the only way to make this patch not required every time is

• Get this patch implemented in osTicket itself. This typical means:
  
  
  
  • Make sure the patch is not a hack but quality code
  
  
  • Add a configuration toggle to enable/disable the feature
  
  
  • Create a PR against osTicket
  
  
  • Convince osTicket that this is a feature they want to continue to support
  
  
  • Get the PR Merged into new version
  
  
• Have some one maintain a public fork of osTicket with an updated patch

I think the second option is more feasible in the short term. I also think that by making this patch more accessible (instead of trying to spend time reading the whole thread to find the zip file and apply it) so that it could be used would encourage the successful merge with the first option.

PS: my 2 cents on the situation

I was thinking about the first option. I am not sure if there are arguments and reasons why this is not an option. I guess there are but I cant find them. What I am trying to understand is - if there is a PR would the osTicket accept it.

I cant speak for this particular situation

I know in the other projects PRs where not accepted because of a project's internal core dev's decision that they would not maintain a feature moving forward.

Also code quality could be a big factor

@thebravoman @YurkoWasHere

Please read:

• https://github.com/osTicket/osTicket/issues/2242#issuecomment-353081378

Cheers.

@JediKev thanks, I read it. The comment was 3 years ago. Has anything changed since then? It also mentions that you've added this to a future roadmap. Is there a case where you will not accept a PR about this?

@thebravoman

Has anything changed since then? It also mentions that you've added this to a future roadmap.

Not at this time. It's still on our roadmap for possible future development.

Is there a case where you will not accept a PR about this?

There are many reasons a pull request would not be accepted such as if it's not written properly, if it doesn't cover all bases, if it's buggy, etc. In this particular case the feature goes much deeper than just simply allowing Agent Responses via email to be added to a Thread as a Response.

Cheers.

Personally,
I've patched our older version to include the agent's reply and didn't
upgrade/update since then as all features that we are interested are
working.

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milan (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Il giorno lun 4 gen 2021 alle ore 17:11 JediKev notifications@github.com
ha scritto:

@thebravoman https://github.com/thebravoman

Has anything changed since then? It also mentions that you've added this
to a future roadmap.

Not at this time. It's still on our roadmap for possible future
development.

Is there a case where you will not accept a PR about this?

There are many reasons a pull request would not be accepted such as if
it's not written properly, if it doesn't cover all bases, if it's buggy,
etc. In this particular case the feature goes much deeper than just simply
allowing Agent Responses via email to be added to a Thread as a Response.

Cheers.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-754065645,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA7RCXWFSS3MNPZ2RIGEXDSYHSD5ANCNFSM4BKXEBBQ
.

Thanks @JediKev. I failed to ask my question clearly. I will try again.
Context:
The osTicket community has asked about this feature in a number of occasions for the last at least 5 years.
The osTicket team has added this to the roadmap
The osTicket community has tried providing input and discussions and patches from versions since at least 10 (I think)
The osTicket team is trying to keep a well working product with good quality.

Situation:
There is no such feature.

My question:
Are there underlying reasons and believes, that the osTicket team holds, that such feature should not exist at all? Is this aligned with the vision and direction of osTicket or this is in a conflict with the understanding of what osTicket should be?

Given that a PR is not buggy, is working for all cases, follows proper conventions, is there a reason that I am missing and not seeing for such a PR to be rejected. Are there other reasons, except for lack of resources, for this feature not to exist. Something that should be taken into account?

My point is that it is not worth spending any amount of time preparing a PR, if there are reason it will not be accepted even if it fulfills all the requirements.

Confirmed working on 1.15.2

Found a bug,

When agent responds via email variables aren't working. They either don't come through, or are written out. see attached

Actually, it's weird. the variables highlighted yellow do work, the the red doesn't.