Hi
Thank you for your quick response. I've tried the code changes and unfortunately, this didn't resolve the issue.
The problem only exists for Azure authentication. Also have open LDAP authentication enabled as an alternative method and it works fine. After authenticating using a direct link to a ticket, the agent is directed to that ticket. Using Azure authentication, the user is directed to the tickets listing /scp/index.php instead of that ticket.
I have osTicket 1.17.2 installed and Azure is working for authentication & email fetching. When an agent clicks on a link to a ticket in an email generated by osTicket, if they are not logged in, they are prompted to authenticate. After successfully logging in using Azure (oauth), they are redirected to the tickets listing page (/scp/index.php) and not directly to the ticket. If the agent was already successfully logged in prior to clicking on the ticket link in the email, the link works just fine.
Is there a way after the user authenticates in Azure, to be redirected to the URL they initially accessed? This way when clicking on a direct link to a ticket in an email, after authenticating in Azure (if not logged in), the agent is taken to the direct link to the ticket.
I've fixed the issue.
Upgraded this morning to version 1.17.1. Clicking on the Access, Permission, or Teams tabs in an agent's manage account fails to open tab. Browser's console reports Uncaught TypeError: Cannot read properties of undefined (reading 'length') in scp.js.
If the person who created the ticket responds to the email they receive, the message is then appended to the original ticket as expected. The problem seems to only happen if an agent belonging to a team replies to the email they receive for a ticket created by someone else.
As a test, I also created a new ticket for a category that is auto assigned to a team that I am also a part of. If I reply to either email I receive (new ticket & ticket assigned to your team) appending to the original ticket works properly.
KevinTheJedi
No, the status is not set to Closed. The status is set to Open.
Steps to reproduce this
1. Agent creates New Ticket
2. Email alert is sent to team assigned to that Help Topic
3. An agent belonging to that team replies to email using their email client
4. when osTicket fetches the email, instead of appending (merging) the message to the existing open ticket, a new ticket is created
Good afternoon,
I recently upgraded osTicket from 1.9.4 to 1.10.5. Since the upgrade, replying to emails creates a new ticket instead of appending the reply to the original message. The email subject does contain the ticket #. An example is [#925863] Ticket Assigned To Your Team. The actual code in the template is [#%{ticket.number}] Ticket Assigned To Your Team: %{ticket.subject}. Replying to emails worked properly before the upgrade.
PHP version is 5.6.37.
Is there anything I can try to resolve this problem?
Thanks.
Problem solved. Our system administrator recently copied the disk image of our production server onto another virtual server which included the cron tasks. The cron job has been deleted from that server and everything is working normally again. Thanks for your help.
When the host changed, I didn't create a new email. Instead, I modified the existing one and changed thehostname from the old host to the new host. I tried temporarily changing the status to disable but I stillgotthe alerts.When I check the logs in osTicket, there are no new fetch errors reported since I changed thehost last week,however administrators are still getting alerts sent to their inbox that it is trying to fetch from the old host.
My organization is using the fetch email feature for one of our email accounts defined in osTicket. Recently, the email hosting server changed. I've modified the email account setting with the new host. However, I am still getting numerous alert emails every 15 minutes stating that >
<!
following mail account:
and it lists the old host. Where is it getting the old host since the email settings have been changed properly to the new host. Where can I stop osTicket from fetching from the old configuration.>
Thanks. I've modified the plugin code and ldap authentication works great. It would be nice to eventually allow the login attribute to be configured within the osTicket ui.
I am using osTicket 1.9.4 and have installed the LDAP plugin - phar file. The open ldap server I am using doesn't use uid for the LDAP login attribute. Where in osTicket, can I configure the LDAP login attribute?
